Arguing against using public IP space

Jay Ashworth jra at baylink.com
Mon Nov 14 01:31:15 UTC 2011


----- Original Message -----
> From: "Brett Frankenberger" <rbf+nanog at panix.com>

> 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?

I should think it would be your responsibility, as the chief engineer, to
make sure *you have filled all such possible holes in your operations plan*.

> 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?

If it costs more to run, then it *costs more to run*.

> 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.

*I* define "air gap" as "no way to move packets from the outside world
into the network.  I didn't say "100% dedicated facilities", though your
implication that that still leaves an attacker a way to reconfigure things
such that they could get in is absolutely correct.

> 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
> compromise.

The line is pretty bright, I think, but you're correct in asserting that the
price difference goes up as the square of the number of nines.  But that's not
important now; we're talking about cases that aren't even *99%*, much less 4 or
5 nines of unlikelihood that an outsider can find a way to break in.
 
> 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.)

Yes, but that's enablement for loss of locally staffed control, all by itself.

Even power utilities have a pretty good real rate of return these days; I have
no problem with them spending a little more of their revenue on safety, instead 
of profit.  If that takes regulators pointing guns at them, I'm fine with that.

> 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.)

And I just read the Cracked piece talking about the 77 NYC blackout, which is
sort of weird, actually.  :-)  But the general case point *I* was making was
not that I expected a conviction.

It was that I expected a charge, and a trial.

If a bridge collapses, are we going to charge the Professional Engineer who 
signed off on it?
 
> 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?

No, and yes my knee was jerking.  But based on the industry stuff I have seen
from out here, security isn't anywhere in the same *county* with where it needs
to be, and -- just as with RMS and the GPL -- maybe if some extremists knees jerk, 
the end result, while more moderate, will be more salutary.

If you were that chief, and you knew the result of you screwing up might be
the loss of your liberty, not just your job... you don't think you'd fight 
budget battles with your utility harder?  (That's often the reason for such 
regulations: to give middle to upper management more bullets to fire at the
(greedy) owners.)

Thanks for doing some of my math for me, though, Brett.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274




More information about the NANOG mailing list