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-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
>> *************************************
>>
>
--Steve Bellovin, https://www.cs.columbia.edu/~smb
