Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?

2007-03-06 Thread Kenneth Van Wyk

On Mar 5, 2007, at 9:30 PM, Gary McGraw wrote:
I think some vendors have come around to the economics argument. In  
every case, those vendors with extreme reputation exposure have  
attempted to move past penetrate and patch.  Microsoft, for one, is  
trying hard, but (to use my broken leg analogy) they had a sever  
case of osteoporosis and must take lots of calcium to build up bone  
mass.   The financial vertical, led by the credit card consortiums  
is likewise making good progress.  Other vendors with less brand  
exposure (or outright apathy from users) are slower on the uptake.


Having spent several years on the incident handling side of this  
argument at CMU's CERT/CC, US. Dept. of Defense, etc., I thought I'd  
chime in here as well.  It's encouraging to me to see that many  
vendors now recognize the reputation exposure and economics  
argument.  I know that in my years at CERT (1989-1993), we were more  
than once threatened by uncooperative vendors, saying that they would  
sue us if we published information about their product's  
vulnerabilities.  We spent years developing those vendor  
relationships and building up some level of mutual trust.  It's not  
always an easy path.


In the full disclosure years, it's been my observation that many  
vendors get forced into publishing patches when the vulnerability  
pimps (as Marcus calls them) call them out in public.  Without a  
doubt, that's lead many vendors to respond more quickly and more  
publicly than they otherwise might have.  At the same time, (and to  
try to bring this thread back to *software security*) I'm concerned  
about the software security ramifications of being bullied into  
patching something too quickly.  While a simple strcpy--strncpy (or  
similar) src edit takes just moments, and shouldn't impact the  
functionality and reliability of any software, patches are rarely  
that simple.  When software producers are forced to develop patches  
in unnaturally rushed situations, bigger problems (IMHO) will  
inevitably be introduced.


So, I applaud the public disclosure model from the standpoint of  
consumer advocacy.  But, I'm convinced that we need to find a process  
that better balances the needs of the consumer against the secure  
software engineering needs.  Some patches can't reasonably be  
produced in the amount of time that the vulnerability pimps give  
the vendors.


Cheers,

Ken
-
Kenneth R. van Wyk
SC-L Moderator
KRvW Associates, LLC
http://www.KRvW.com






PGP.sig
Description: This is a digitally signed message part
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] Economics of Software Vulnerabilities

2007-03-06 Thread Ed Reed
For a long time I thought that software product liability would
eventually be forced onto developers in response to their long-term
failure to take responsibility for their shoddy code.  I was mistaken. 
The pool of producers (i.e., the software industry) is probably too
small for such blunt economic policy to work.

Keep in mind that economics does have a tendency to balance out risk and
reward, and to fairly allocate liability.  But it takes time.  We're
only about 50 years into the life of the software industry, and we're
just starting to see regulatory notice that computers even exist.

It appears, now, that producers will not be regulated, but rather users
and consumers.  SOX, HIPAA, BASEL II, etc. are all about regulating
already well-established business practices that just happen to be
incorporating more software into their operations. 

But as with other serious security policy formulations - the
technology is irrelevant.  The policies, whether SOX or Multi-level
Security, are intended to protect information of vital importance to the
organization.  If technical controls are adequate to enforce them -
fine.  If not, that in no way absolves the enterprise of the need to
provide adequate controls.

The computer software industry has lost its way.  It appears to be
satisfied with prodding and encouraging software developers to develop
some modicum of shame for the shoddy quality of their output.  Feed the
beast, and support rampant featurism - its what's made so many people
rich, after all.

In the long run, though, featurism without quality is not sustainable. 
That is certainly true, and I applaud efforts to encourage developers to
rise up from their primordial ooze and embrace the next steps in sane
programming (we HAVE largely stamped out self-modifying code, but
strcpy() is still a problem...)

But that's not security.  It's just reducing irresponsible defects. 

For computer security to have any meaning, someone, some where, has to
say what is supposed to happen and what is not supposed to happen with
regard to access to information and resources of the system.  In other
words, there has to be a security policy.

If there's no way to articulate how the security policy can be enforced
by a system, i.e., no security model, then there's no real way to even
have a discussion about whether a system, much less individual
components of the system, contribute to or get in the way of enforcing
the security policy.

What's most disappointing to me is the near-total lack of discussion
about security policies and models in the whole computer security field,
today.

We're at about the 19th century level of sophistication of the practice
of medicine - we have a germ theory (bugs make you sick), but we're
still trying to get the doctors and nurses to wash their hands between
surgery (Doctor!  It HURTS when I do that! Then stop DOING that!). 
Better languages, better language skills, and better transparency
(disclosure) are all areas of important improvement.

The question I raise is this - will we return to a serious discussion
about whether and how computers can be used to secure the vital
information of enterprises before our industry reaches its first century
(say, by 2055)?  Ought a computer be able to be expected to apply
controls adequate to bet your life on, or not?  If so, when will that
discussion get started again?  It seems like the analytical approaches
that brought us Bell-LaPadula and similar models are considered
off-topic, today, but I haven't seen anything replace them as the basis
for a rational computer security discussion.

If engineering is the practice of applying the logic and proofs provided
by science to real world situations, software engineering and computer
science seem simply to have closed their eyes to the question of system
security and internal controls.

Perhaps economics will reinvigorate the discussion in the coming decades.

Ed Reed
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Disclosure: vulnerability pimps? or super heroes?

2007-03-06 Thread Blue Boar
Kenneth Van Wyk wrote:
 So, I applaud the public disclosure model from the standpoint of
 consumer advocacy.  But, I'm convinced that we need to find a process
 that better balances the needs of the consumer against the secure
 software engineering needs.  Some patches can't reasonably be produced
 in the amount of time that the vulnerability pimps give the vendors.

From the outside, it looks like the vast majority of the patches take as
long as the vendor feels like taking. With a small percentage of
vulnerabilities being released with no vendor warning at all. It's
relatively unusual that I see bulletins where the researcher releases
saying that the vendor took too long, so they are releasing now.

But that's just going from memory, I haven't done a proper survey or
anything.

BB
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___