Economics of Software Vulnerabilities

[ge at linuxbox.org (Gadi Evron)]

On Tue, 13 Mar 2007, Gary McGraw wrote:
> 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.

Fuzzing is indeed, most definitely, not a or the silver bullet, nor should
testing be based on itsolely. What it does provide us with is a measurable
fashion by which we can reliably test the:
1. Stability
2. Programming quality
3. Robustness

Of software, to a level which is much higher than employing several
reverse engineers and test engineers (not to say just examining
vulnerability history on the bugtraq archive).

Further, if not by certification, fuzzing has already shown it can
pressure companies to use software development lifecycle methodologies and
that way enforcing (encouraging?) better security with "partners" (read
Microsoft).

Fuzzing has also shown that it can be used to force vendors who sell to
you to indeed be "tested" by certain products (read large
Telcos). Although I am unsure if this approach holds water.

The re-emergence of this field beyond rubber stamp certifications or very
costly certifications, is something I see as very positive.

That, of course, if not a or the sulver bullet in any way, either, but
maybe we will see less input validation bugs around and will start facing
logical flaws that will boggle our minds.

Personal opinion: enough with buffer overflows already, no? :)

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

That makes sense, but I figure if we can eliminate some more by a factor
in our testing environment(s), all the better.

> gem

        Gadi.

--
"beepbeep it, i leave work, stop reading sec lists and im still hearing
gadi"
- HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March 2007.