airgap / negligent homicide charge

Mon Nov 14 15:25:12 UTC 2011

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