Economics of Software Vulnerabilities

[gem at cigital.com (Gary McGraw)]

In my opinion, though fuzz testing is certainly a useful technique (we've used it in hardware verification for years), 
any certification based solely on fuzz testing for security would be ludicrous.  Fuzz testing is not a silver bullet.

The biggest stumbling block for software certification is variability in final environment.

gem

company www.cigital.com
podcast www.cigital.com/silverbullet
blog www.cigital.com/justiceleague
book www.swsec.com

 -----Original Message-----
From:   Gadi Evron [mailto:ge at linuxbox.org]
Sent:   Mon Mar 12 21:48:25 2007
To:     Crispin Cowan
Cc:     fuzzing at whitestar.linuxbox.org; Ed Reed; sc-l at securecoding.org
Subject:        Re: [SC-L] Economics of Software Vulnerabilities

On Mon, 12 Mar 2007, Crispin Cowan wrote:
> Ed Reed wrote:
> > 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.
> >   
> I'm not sure about the size of the pool. I think it is more about the
> amount of leverage that can be put on software:
>
>     * It is trivial for some guy in a basement to produce a popular
>       piece of open source software, which ends up being used as a
>       controlling piece of a nuclear reactor, jet airplane, or
>       automobile, and when it fails, $millions or $billions of damages
>       result. The software author has no where near the resources to pay
>       the damage, or even the insurance premiums on the potential damage.
>     * In contrast, with physical stuff it is usually the case that the
>       ability to cause huge damage requires huge capital in the first
>       place, such as building nuclear reactors, jet planes, and cars.
>
> With this kind of leverage, the software producers don't have the
> resources to take responsibility, and so strict liability applied to
> authors reduces to "don't produce software" unless, possibly, you work
> for a very large corporation with deep pockets. Even then, corporate
> bean counters would likely prevent you from writing any software because
> the potential liability is so large.
>
> > 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. 
> >   
> Much like the gun industry. Powerful, deadly tools that, if used
> inappropriately, can cause huge damage.

Indeed, and I found your posts enlightening.

Still, today an alternative presentsitself in the now more likely realm of
software security certification and testing. It has become more easier and
potentially regulated now that fuzzers have become:

1. Good enough.
2. Measurable.
3. Widely accessible.

        Gadi.

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at 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.
_______________________________________________




----------------------------------------------------------------------------
This electronic message transmission contains information that may be
confidential or privileged.  The information contained herein is intended
solely for the recipient and use by any other party is not authorized.  If
you are not the intended recipient (or otherwise authorized to receive this
message by the intended recipient), any disclosure, copying, distribution or
use of the contents of the information is prohibited.  If you have received
this electronic message transmission in error, please contact the sender by
reply email and delete all copies of this message.  Cigital, Inc. accepts no
responsibility for any loss or damage resulting directly or indirectly from
the use of this email or its contents.
Thank You.
----------------------------------------------------------------------------