Arguing against using public IP space

Brett Frankenberger rbf+nanog at
Sun Nov 13 19:14:59 CST 2011

On Sun, Nov 13, 2011 at 06:29:39PM -0500, Jay Ashworth wrote:
> SCADA networks should be hard air-gapped from any other network.
> In case you're in charge of one, and you didn't hear that, let me say
> it again:
> *SCADA networks should he hard air-gapped from any other network.*
> If you're in administrative control of one, and it's attacked because you
> didn't follow this rule, and someone dies because of it, I heartily, and
> perfectly seriously, encourage that you be charged with homicide.
> We do it with Professional Engineers; I see no reason we shouldn't expect
> the same level of responsibility from other types.

What if you air-gap the SCADA network of which you are in
administrative control, and then there's a failure on it, and the people
responsible for troubleshooting it can't do it remotely (because of the
air gap), so the trouble continues for an extra hour while they drive
to the office, and that extra hour of failure causes someone to die. 
Should that result in a homicide charge?

What if you air-gap the SCADA network of which you are in
administrative control, but, having done so, you can't afford the level
of redundancy you could when it wasn't air-gapped, and a transport
failure leaves you without remote control of a system at a time when
it's needed to prevent a cascading failure, and that leads to someone
dieing.  Should that result in a homicide charge?

Air-gap means you have to build your own facilities for the entire
SCADA network.  No MPLS-VPN service from providers.  Can't even use
point-to-point TDM circuits (T1, for example) from providers, since
those are typically mixed in with other circuits in the carrier's DACS,
so it's only logical separation.  And even if you want to redefine
"air-gap" to be "air-gap, or at least no co-mingling in any packet
switching equipment", you've ruled out any use of commercial wireless
service (i.e. cellular) for backup paths.

A good engineer weighs all the tradeoffs and makes a judgement.  In
some systems, there's might be a safety component of availability that
justifies accepting some very small increase in the risk of outside

You can argue that safety is paramount -- that the system needs to be
designed to never get into an unsafe condition because of a
communications failure (which, in fact is a good argument) -- that
there must always be sufficient local control to keep the system in a
safe state.  Then you can implement the air-gap policy, knowing that
while it might make remote control less reliable, there's no chance of,
say, the plant blowing up because of loss of remote control.  (Except,
of course, that that's only true if you have complete faith in the local
control system.  Sometimes remote monitoring can allow a human to see
and correct a developing unsafe condition that the control system was
never programmed to deal with.)

But even if the local control is completely safe in the loss-of-comm
failure case, it's still not as cut and dried as it sounds.  The plant
might not blow up.  But it might trip offline with there being no way
to restart it because of a comm failure.  Ok, fine, you say, it's still
in a safe condition.  Except, of course, that power outages, especially
widespread ones, can kill people.  Remote control of the power grid
might not be necessarily to keep plants from blowing up, but it's
certainly necessary in certain cases to keep it online.  (And in this
paragraph, I'm using the power grid as an example.  But the point I'm
making in this post is more general case.)

Sure, anytime there's an attack or failure on a SCADA network that
wouldn't have occurred had it been air-gapped, it's easy for people to
knee-jerk a "SCADA networks should be airgapped" response.  But that's
not really intelligent commentary unless you carefully consider what
risks are associated with air-gapping the network.

Practically speaking, non-trivial SCADA networks are almost never
completely air-gapped.  Have you talked to people who run them?

     -- Brett

More information about the NANOG mailing list