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 comContent-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_connectivityEnd 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.htmlI 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 otherthreats 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 netContent-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-asciiOn 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 comContent-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.htmlI 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)
- Re: airgap / negligent homicide charge Steven Bellovin (Nov 14)