WH Cyberspace Security Review (PDF)

[David Farber <dave () farber net>]

Begin forwarded message:

From: "David P. Reed" <dpreed () reed com>
Date: May 31, 2009 2:43:29 PM EDT
To: dave () farber net
Cc: ip <ip () v2 listbox com>
Subject: Re: [IP] WH Cyberspace Security Review (PDF)

Karl makes a series of very important points here.  Perhaps the single  
biggest point is that "security" has become an incredibly narrow word  
- focused on flaws (coding bugs and exploits), impenetrability, and  
"rulesets".

To me, the ordinary English meaning of security  is "safety".   Safety  
cannot be assured by reducing security to a proof (proof of a  
negative, even worse).  Safety includes resiliency, robustness,  
predictability, and transparency.

I blame the lack of security in our systems directly on the community  
who directs "computer security" research.  It's a broad community, but  
a very inbred one.

Unfortunately, the people being put in charge of improving things in  
the "cyber" world are the same community who got us into this mess by  
defining the wrong problem as the crucial problem.  And worse, they  
are pursuing most of the work in highly classified programs, where  
their bad definition of the problem cannot be questioned.

And as we see today in the NYTimes, it's becoming a feeding frenzy for  
the well-connected defense contractors, who will be conducting more of  
this misguided thinking behind closed doors on projects that (rightly  
or wrongly) cannot engage the broad capabilities of the systems  
engineering community.

No critics are allowed to examine what will be done.






David Farber wrote:
> Begin forwarded message:
>
> From: Karl Auerbach <karl () cavebear com>
> Date: May 29, 2009 6:54:06 PM EDT
> To: dave () farber net
> Cc: ip <ip () v2 listbox com>
> Subject: Re: [IP] WH Cyberspace Security Review (PDF)
>
> David Farber wrote:
>
> WH Cyberspace Security Review:
> > Assuring a Trusted and Resilient Information and Communications  
> > Infrastructure
> > http://www.whitehouse.gov/asset.aspx?AssetId=1732
>
> In a word - unimaginative.  In another word - inadequate.
>
> It is a plan that follows a deeply rutted road, largely carved by  
> wagons heavily loaded with "reactive thinking" mentalities.
>
> What is missing is new thinking.
>
> How about making authors and vendors of software liable for software  
> flaws?  (It ought to be liability subject to a negligence standard  
> that can evolve and become more strict as the standard of care  
> improves in response to the threat of liability.)
>
> How about borrowing some ideas from the hard engineering  
> disciplines: What if we were to require that critical infrastructure  
> software and protocol elements be designed and implemented using  
> design rules and proven techniques that can be bypassed only upon a  
> concrete justification?
>
> How about changing the way we educate software and network  
> engineers?  I would submit that many of today's software and network  
> designers have tunnel vision and do not comprehend the totality of  
> how their work fits into the totality of a computer or network.
>
> Today we build software and network protocols in a way that, were  
> they biological entities, they would probably fail in the  
> evolutionary competition because they are too brittle.  Perhaps we  
> ought to start to consider how to build one of the hallmarks of  
> biological success, overlapping but different redundant mechanisms,  
> onto software and especially network protocols?  In practical terms  
> this means doing things in multiple ways and only moving forward if  
> all the ways are in concurrence (differences are a reason to issue  
> an alarm.)  We are starting to see this in things like DNSSEC.   
> Routing protocols, in particular, might take a cue from the  
> naturally suspicious nature of those ISPs who do not blindly accept  
> any and all routing announcements.  The key here is corroborative  
> networking in which a decision is based on a multiple and,  
> hopefully, independent algorithms and data sources.
>
> My company (InterWorking Labs) is in the business of protocol  
> susceptibility testing.  One of the things we grumble about is the  
> absence of good test points through which we can examine the health  
> of a network device when it is being tested or used.  Network device  
> and protocol reliability could be greatly improved if some of the  
> design rules that I mentioned above designated test points through  
> which internal behavior of devices could be observed and actuated.   
> It does not seem too much to ask for network devices to have at  
> least the same level of test/diagnostic interfaces as the typical  
> automobile.
>
> And there is a critical issue that is being ignored - the issue of  
> recovery after bad things happen.  The government's plan is largely  
> protective and does not seem to consider that bad things will happen  
> - Mr. Murphy and his law are not going away.
>
> In an era in which software and the internet are increasingly being  
> cross-linked with other critical infrastructures (electrical power,  
> telephone, air traffic control, etc, etc) the issues of quick  
> recovery not being addressed.
>
> Hard and thick security makes recovery more difficult.
>
> For example, as we harden DNS we make it harder for local  
> communities that have been hit with a natural or human disaster to  
> build a local, temporary lash-up internet communications system to  
> facilitate local communications while the rest of the world is  
> trying to rebuild its way into the disaster area.
>
> We also need to begin a science of network pathology - so that we  
> can begin to reason backwards from symptoms to causes.  We in the  
> networking world have a lot to learn from the medical community.
>
> The thinking that I saw in my skimming of the report was a mentality  
> that suggests a brittle outer shell for our computer and network  
> systems rather than a thick, redundant, resilient barrier that not  
> only protects against damage, but also limits damage and promotes  
> recovery.
>
>        --karl--
>
>
>
>
>
>
> -------------------------------------------
> Archives: https://www.listbox.com/member/archive/247/=now
> RSS Feed: https://www.listbox.com/member/archive/rss/247/
> Powered by Listbox: http://www.listbox.com




-------------------------------------------
Archives: https://www.listbox.com/member/archive/247/=now
RSS Feed: https://www.listbox.com/member/archive/rss/247/
Powered by Listbox: http://www.listbox.com