nanog mailing list archives

Re: airgap / negligent homicide charge

From: Steven Bellovin <smb () cs columbia edu>
Date: Mon, 14 Nov 2011 20:15:22 -0500

Here's a quote from a famous court case (T.J. Hooper) on liability and industry
standards:

    Indeed in most cases reasonable prudence is in face common prudence; but
    strictly it is never its measure; a whole calling may have unduly lagged
    in the adoption of new and available devices.  It may never set its own
    tests, however persuasive be its usages.  Courts must in the end say what
    is required; there are precautions so imperative that even their universal
    disregard will not excuse their omission. 

And here's a quote from a legal textbook:

    The standard of conduct imposed by the law is an external
    one, based upon what society demands generally of its
    members, rather than upon the actors personal morality or
    individual sense of right and wrong.  A failure to conform
    to the standard is negligence, therefore, even if it is due
    to clumsiness, stupidity, forgetfulness, an excitable
    temperament, or even sheer ignorance.  An honest blunder,
    or a mistaken belief that no damage will result, may absolve
    the actor from moral blame, but the harm to others is still
    as great, and the actors individual standards must give way
    in this area of the law to those of the public.  In other
    words, society may require of a person not to be awkward
    or a fool.

In other words, get real legal advice on the standard of care you should
observe.


On Nov 14, 2011, at 10:25 AM, Mickey Fox wrote:

The determination of whether a failure rises to the level of negligent
homicide will require a review of industry standards, company standards and
sometimes straight common-sence.

If the industry standard is airgap re security you are probably okay so
long as you review and address the very concerns and questions you are
raising in a responsible fashion that does not rely solely on expediency,
cost, etc., but looks to real-world scenarios and emergency / backup
procedures, equipment, testing and training.

Mickey Fox
CMK Consulting Services
On Nov 14, 2011 9:00 AM, <nanog-request () nanog org> wrote:

Send NANOG mailing list submissions to
      nanog () nanog org

To subscribe or unsubscribe via the World Wide Web, visit
      https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
      nanog-request () nanog org

You can reach the person managing the list at
      nanog-owner () nanog org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

 1. Re: Arguing against using public IP space
    (Valdis.Kletnieks () vt edu)
 2. Re: Arguing against using public IP space (Joel jaeggli)
 3. Re: Arguing against using public IP space (Jimmy Hess)
 4. Re: Arguing against using public IP space (Owen DeLong)
 5. Re: Arguing against using public IP space (Dobbins, Roland)
 6. Cable standards question (Sam (Walter) Gailey)
 7. Re: Cable standards question (Daniel Seagraves)
 8. Re: Arguing against using public IP space (Joe Greco)
 9. Re: Arguing against using public IP space (Ray Soucy)


----------------------------------------------------------------------

Message: 1
Date: Sun, 13 Nov 2011 21:43:32 -0500
From: Valdis.Kletnieks () vt edu
To: Brett Frankenberger <rbf+nanog () panix com>
Cc: NANOG <nanog () nanog org>
Subject: Re: Arguing against using public IP space
Message-ID: <81357.1321238612 () turing-police cc vt edu>
Content-Type: text/plain; charset="us-ascii"

On Sun, 13 Nov 2011 19:14:59 CST, Brett Frankenberger said:

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?


If you designed a life-critical airgapped network that didn't have a
trained
warm body at the NOC 24/7 with an airgapped management console, and hot
(or at
least warm) spares for both console and console monkey, yes, you *do*
deserve
that negligent homicide charge.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <
http://mailman.nanog.org/pipermail/nanog/attachments/20111113/247b47fe/attachment-0001.bin


------------------------------

Message: 2
Date: Mon, 14 Nov 2011 10:59:45 +0800
From: Joel jaeggli <joelja () bogus com>
To: Joe Greco <jgreco () ns sol net>
Cc: NANOG <nanog () nanog org>
Subject: Re: Arguing against using public IP space
Message-ID: <4EC08421.80708 () bogus com>
Content-Type: text/plain; charset=ISO-8859-1

On 11/14/11 10:24 , Joe Greco wrote:

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.


Not to mention that it's not the only way for these things to get
infected.  Getting fixated on air-gapping is unrealistically ignoring
the other threats out there.

There needs to be a whole lot more security work done on SCADA nets.


Stuxnet should provide a fairly illustrative example.

It doesn't really matter how well isolated from direct access it is if
it has a soft gooey center and a willing attacker.

... JG





------------------------------

Message: 3
Date: Sun, 13 Nov 2011 21:48:01 -0600
From: Jimmy Hess <mysidia () gmail com>
To: David Walker <davidianwalker () gmail com>
Cc: nanog () nanog org
Subject: Re: Arguing against using public IP space
Message-ID:
      <CAAAwwbUSUzHO0q3vkBh3-sQHxnXc5=UE5w2R+MZ=Hmpa08wDhg () mail gmail com

Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker () gmail com>
wrote:

On 14/11/2011, Jimmy Hess <mysidia () gmail com> wrote:
A packet addressed to an endpoint that doesn't serve anything or have
a client listening will be ignered (whatever) as a matter of course.
Firewall or no firewall.

It will not go to a listening application,  neither will it be
completely ignored --
the receiving machine's  TCP stack will have a look at the packet.
On common operating systems there  are frequently unsafe applications
listening on ports;  on certain OSes, there will be no way to turn off
system applications,  or human error will leave them in place.

That's fundamental to TCP/IP and secure.

It's fundamental to TCP/IP,  but not fundamentally secure.  TCP/IP
implementations have flaws.
If a host is meant solely as an endpoint, then it is exposed to undue
risk, if arbitrary packets can be addressed to its TCP/IP stack that
might have remotely exploitable bugs.

The only reason we firewall (packet filter) is to provide access
control (for whatever reason).

No, we also firewall to block access entirely to applications
attempting to establish a service on unapproved ports.    We also use
firewalls in certain forms to ensure that communications over a TCP/IP
socket comply with a protocol,  for example,  that a session
terminated on port 25 is actually a SMTP session.

The firewall might restrict the set of allowed SMTP commands, validate
the syntax of certain commands,  hide server version information,
prevent use of ESMTP pipelining from outside, etc.

I apologize in advance if this is too pedestrian (you might know this
but not agree with it) but I want to make a point:
http://en.wikipedia.org/wiki/End-to-end_connectivity


End to end connectivity principal's purpose is not to provide
security.    It is to facilitate communications with other hosts and
networks.     When a private system _really_ has to be secure,  end to
end connectivity is inherently incompatible  with security objectives.

There is always a tradeoff involving sacrificing a level of security
against remote attack
when connecting a computer to a network,  and then again,  when
connecting the network to the internet.

A computer that is not connected to a network is perfectly secure
against network-based attacks.
A computer that is connected to LAN is at risk of potential
network-based attack from that LAN.

If that LAN is then connected through a firewall  through many to 1
NAT,  there is another layer of risk added.

If the NAT'ing firewall is then replaced with a simple many to 1 NAT
router,  there is another layer of risk added; there are new attacks
possible that still succeed in a NAT environment,  that the firewall
would have stopped.

Finally, if that that same computer is then given end to end
connectivity with no firewall,  there is a much   less encumbered
communications path available to that computer for launching
network-based attack;  the attack surface is greatly increased in such
a design.

If we are talking about nodes that interface with a SCADA network;
the concept of unfirewalled end-to-end connectivity approaches the
level of insanity.

Those are not systems where end-to-end public connectivity should be a
priority over security.

--
-JH



------------------------------

Message: 4
Date: Sun, 13 Nov 2011 19:51:24 -0800
From: Owen DeLong <owen () delong com>
To: Jason Lewis <jlewis () packetnexus com>
Cc: nanog () nanog org
Subject: Re: Arguing against using public IP space
Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282 () delong com>
Content-Type: text/plain; charset=us-ascii


On Nov 13, 2011, at 7:36 AM, Jason Lewis wrote:

I don't want to start a flame war, but this article seems flawed to
me.  It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html


I think I could announce private IP space, so doesn't that make this
argument invalid?  I've always looked at private IP space as more of a
resource and management choice and not a security feature.


Yes, the author of this article is sadly mistaken and woefully void
of clue on the issues he attempts to address.

You are completely correct.

Owen




------------------------------

Message: 5
Date: Mon, 14 Nov 2011 06:21:47 +0000
From: "Dobbins, Roland" <rdobbins () arbor net>
To: NANOG Operators' Group <nanog () nanog org>
Subject: Re: Arguing against using public IP space
Message-ID: <EF60C45B-4227-4EF9-BFAF-FB96473F8670 () arbor net>
Content-Type: text/plain; charset="us-ascii"

On Nov 14, 2011, at 9:24 AM, Joe Greco wrote:

Getting fixated on air-gapping is unrealistically ignoring the other

threats out there.

I don't think anyone in this thread is 'fixated' on the idea of
airgapping; but it's generally a good idea whenever possible, and as
restrictive a communications policy as is possible is definitely called
for, amongst all the other things one ought to be doing.

It's also important to note that it's often impossible to *completely*
airgap things, these days, due to various interdependencies, admin
requirements (mentioned before), and so forth; perhaps bastioning is a more
apt term.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins () arbor net> // <http://www.arbornetworks.com>

              The basis of optimism is sheer terror.

                        -- Oscar Wilde




------------------------------

Message: 6
Date: Mon, 14 Nov 2011 14:42:32 +0000
From: "Sam (Walter) Gailey" <gaileywg () MANSFIELDCT ORG>
To: "nanog () nanog org" <nanog () nanog org>
Subject: Cable standards question
Message-ID:
      <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2 () TN-Mail-1 mansfieldct net

Content-Type: text/plain; charset="us-ascii"

Hello, newbie question of the morning time, but hopefully not too
off-topic...

I run a small town network. A new building is being built that the town
wants fiber access to. I have to specify for vendors what it is that the
town expects in the cabling. I am (obviously) not a fiber expert, and I'm
having trouble phrasing the language of the RFP so that we are assured a
quality installation.

My question is this; Is there an appropriate standard to specify for
fiber-optic cabling that if it is followed the fiber will be installed
correctly? Would specifying TIA/EIA 568-C.3, for example, be correct?

I'm envisioning something like;

"The vendor will provide fiber connectivity between (building A) and
(building B). Vendor will be responsible for all building penetrations and
terminations. When  installing the fiber-optic cable the vendor will follow
the appropriate TIA/EIA 568 standards for fiber-optic cabling."

Any suggestions or examples of language would be very appreciated. Offlist
contact is probably best.

Many thanks,

---Sam


------------------------------

Message: 7
Date: Mon, 14 Nov 2011 08:57:31 -0600
From: Daniel Seagraves <dseagrav () humancapitaldev com>
To: nanog () nanog org
Subject: Re: Cable standards question
Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE () humancapitaldev com>
Content-Type: text/plain; charset=us-ascii


On Nov 14, 2011, at 8:42 AM, Sam (Walter) Gailey wrote:

"The vendor will provide fiber connectivity between (building A) and

(building B). Vendor will be responsible for all building penetrations and
terminations. When  installing the fiber-optic cable the vendor will follow
the appropriate TIA/EIA 568 standards for fiber-optic cabling."


Any suggestions or examples of language would be very appreciated.

Offlist contact is probably best.

Is it appropriate to just say "When installing fiber-optic cable the
vendor will ensure the resulting installation does not suck."?
That would seem to me to be the most direct solution to the problem. I
mean, standards are all well and good, but what if the standard sucks?
Then you'd be up a creek.

Maybe there should be a legal definition of the concept of suck, so that
suckage could be contractually minimized.




------------------------------

Message: 8
Date: Mon, 14 Nov 2011 08:58:37 -0600 (CST)
From: Joe Greco <jgreco () ns sol net>
To: joelja () bogus com (Joel jaeggli)
Cc: NANOG <nanog () nanog org>
Subject: Re: Arguing against using public IP space
Message-ID: <201111141458.pAEEwcS6072727 () aurora sol net>
Content-Type: text/plain; charset=us-ascii

On 11/14/11 10:24 , Joe Greco wrote:

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.


Not to mention that it's not the only way for these things to get
infected.  Getting fixated on air-gapping is unrealistically ignoring
the other threats out there.

There needs to be a whole lot more security work done on SCADA nets.


Stuxnet should provide a fairly illustrative example.

It doesn't really matter how well isolated from direct access it is if
it has a soft gooey center and a willing attacker.


That's basically the case for so many things.

I was reading, recently, two articles on Ars Technica ("Die, VPN" and
"Live, VPN") which made it exceedingly clear that these sorts of designs
are still the rule for most companies.  I mean, I already knew that, but
it was *depressing* to read.

We've been very successful for many years designing things as though they
were going to be deployed on the public Internet, even if we do still put
them behind a firewall.  That's just belt-and-suspenders common sense.

We do run a VPN service, which I use heavily, but it really has little
to do with granting magical access to resources - the VPN endpoint is
actually outside any firewall.  I've so frequently found, over the years,
that some "free" Internet connection offering is crippled in some stupid
manner (transparent proxying with ad injection!), that the value added
is mostly just that of getting an Internet connection with no interference
by third parties.  The fact that third parties cannot do any meaningful
snooping is nice too.

I also recall a fairly surreal discussion with a NANOG'er who was
absolutely convinced that SSH key based access to other servers was
more secure than password based access along with some ACL's and
something like sshguard; my point was that compromise of the magic
host with the magic key would tend to be worse (because you've suddenly
got access to all the other servers) while having different secure
passwords for each host, along with some ACL's and sshguard, allow you
to retain some isolation within the network from an infected node.  It's
dependent on design and forethought, of course...

Basically, getting access to some point in the network shouldn't really
allow you to go on a rampage through the rest of the network.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and]
then I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.



------------------------------

Message: 9
Date: Mon, 14 Nov 2011 10:00:36 -0500
From: Ray Soucy <rps () maine edu>
To: Jason Lewis <jlewis () packetnexus com>
Cc: nanog () nanog org
Subject: Re: Arguing against using public IP space
Message-ID:
      <CALFTrnMGODeixe2g0eg_gTmZvkL_89LSFtdgW4E5SZ-Qq1Xjbw () mail gmail com

Content-Type: text/plain; charset=ISO-8859-1

As far as I can see Red Tiger Security is Jonathan Pollet; and even
though they list Houston, Dubai, Milan, and Sydney as offices it looks
like Houston is the only one.? Is that right?? Seems a little
misleading.

It actually reminds me of a 16 year old kid I know who runs a web
hosting "company" that you'd think was a Fortune 500 by the way the
website reads, and he's more than happy to take your credit card
information and store it without being PCI compliant.

Credibility of the company aside,

At first I wanted to cut Jonathan some slack.? If he was going to
point to the use of public IPs as evidence that a firewall may not be
in use and then went on to discuss the potential risks of not having
any security, then that would have been appropriate.? But instead he
goes on about explaining what a public vs. private address is (poorly)
and proceeds to associate the security of the system with the use of
private IPs.

I just don't see him as credible in the security field after reading it.

Then again, he does have that interview on Fox News posted on his
website where he talks about terrorist plots to compromise the
integrity of nuclear power plants...

Honestly, people post stuff like this time and time again.  It's been
debunked so many times that a quick Google will probably give you what
you need to figure it out on your own.

On Sun, Nov 13, 2011 at 10:36 AM, Jason Lewis <jlewis () packetnexus com>
wrote:

I don't want to start a flame war, but this article seems flawed to
me. ?It seems an IP is an IP.

http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html


I think I could announce private IP space, so doesn't that make this
argument invalid? ?I've always looked at private IP space as more of a
resource and management choice and not a security feature.




--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/



End of NANOG Digest, Vol 46, Issue 43
*************************************



                --Steve Bellovin, https://www.cs.columbia.edu/~smb

Current thread:

Re: airgap / negligent homicide charge Mickey Fox (Nov 14)
- Re: airgap / negligent homicide charge Steven Bellovin (Nov 14)
  - Re: airgap / negligent homicide charge James Downs (Nov 14)