airgap / negligent homicide charge

Tue Nov 15 01:15:22 UTC 2011

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 at nanog.org> wrote:
> 
>> Send NANOG mailing list submissions to
>>       nanog at 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 at nanog.org
>> 
>> You can reach the person managing the list at
>>       nanog-owner at 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 at 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 at vt.edu
>> To: Brett Frankenberger <rbf+nanog at panix.com>
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <81357.1321238612 at 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 at bogus.com>
>> To: Joe Greco <jgreco at ns.sol.net>
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <4EC08421.80708 at 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 at gmail.com>
>> To: David Walker <davidianwalker at gmail.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Arguing against using public IP space
>> Message-ID:
>>       <CAAAwwbUSUzHO0q3vkBh3-sQHxnXc5=UE5w2R+MZ=Hmpa08wDhg at mail.gmail.com
>>> 
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwalker at gmail.com>
>> wrote:
>>> On 14/11/2011, Jimmy Hess <mysidia at 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 at delong.com>
>> To: Jason Lewis <jlewis at packetnexus.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <2DE5DF4F-059C-4F39-81D4-363E49966282 at 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 at arbor.net>
>> To: NANOG Operators' Group <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <EF60C45B-4227-4EF9-BFAF-FB96473F8670 at 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 at 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 at MANSFIELDCT.ORG>
>> To: "nanog at nanog.org" <nanog at nanog.org>
>> Subject: Cable standards question
>> Message-ID:
>>       <64BA4A04F13A7A43B289BAE7F07961F50AC92AE2 at 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 at humancapitaldev.com>
>> To: nanog at nanog.org
>> Subject: Re: Cable standards question
>> Message-ID: <9A40A794-56FE-4773-B6A8-7BAD9EDF77FE at 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 at ns.sol.net>
>> To: joelja at bogus.com (Joel jaeggli)
>> Cc: NANOG <nanog at nanog.org>
>> Subject: Re: Arguing against using public IP space
>> Message-ID: <201111141458.pAEEwcS6072727 at 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 at maine.edu>
>> To: Jason Lewis <jlewis at packetnexus.com>
>> Cc: nanog at nanog.org
>> Subject: Re: Arguing against using public IP space
>> Message-ID:
>>       <CALFTrnMGODeixe2g0eg_gTmZvkL_89LSFtdgW4E5SZ-Qq1Xjbw at 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 at 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