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-requ...@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-requ...@nanog.org > > You can reach the person managing the list at > nanog-ow...@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.kletni...@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.kletni...@vt.edu > To: Brett Frankenberger <rbf+na...@panix.com> > Cc: NANOG <nanog@nanog.org> > Subject: Re: Arguing against using public IP space > Message-ID: <81357.1321238...@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 <joe...@bogus.com> > To: Joe Greco <jgr...@ns.sol.net> > Cc: NANOG <nanog@nanog.org> > Subject: Re: Arguing against using public IP space > Message-ID: <4ec08421.80...@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 <mysi...@gmail.com> > To: David Walker <davidianwal...@gmail.com> > Cc: nanog@nanog.org > Subject: Re: Arguing against using public IP space > Message-ID: > <CAAAwwbUSUzHO0q3vkBh3-sQHxnXc5=UE5w2R+MZ=hmpa08w...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, Nov 13, 2011 at 3:03 PM, David Walker <davidianwal...@gmail.com> > wrote: > > On 14/11/2011, Jimmy Hess <mysi...@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 <o...@delong.com> > To: Jason Lewis <jle...@packetnexus.com> > Cc: nanog@nanog.org > Subject: Re: Arguing against using public IP space > Message-ID: <2de5df4f-059c-4f39-81d4-363e49966...@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" <rdobb...@arbor.net> > To: NANOG Operators' Group <nanog@nanog.org> > Subject: Re: Arguing against using public IP space > Message-ID: <ef60c45b-4227-4ef9-bfaf-fb96473f8...@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 <rdobb...@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" <gaile...@mansfieldct.org> > To: "nanog@nanog.org" <nanog@nanog.org> > Subject: Cable standards question > Message-ID: > <64ba4a04f13a7a43b289bae7f07961f50ac92...@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 <dseag...@humancapitaldev.com> > To: nanog@nanog.org > Subject: Re: Cable standards question > Message-ID: <9a40a794-56fe-4773-b6a8-7bad9edf7...@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 <jgr...@ns.sol.net> > To: joe...@bogus.com (Joel jaeggli) > Cc: NANOG <nanog@nanog.org> > Subject: Re: Arguing against using public IP space > Message-ID: <201111141458.paeewcs6072...@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 <r...@maine.edu> > To: Jason Lewis <jle...@packetnexus.com> > Cc: nanog@nanog.org > Subject: Re: Arguing against using public IP space > Message-ID: > <calftrnmgodeixe2g0eg_gtmzvkl_89lsftdgw4e5sz-qq1x...@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 <jle...@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 > ************************************* >
