From: coley at linus.mitre.org (Steven M. Christey)
Subject: Re: it\'s all about timing

choose.a.username@...hmail.com said:

>>Based on an informal study I've done of about 350 researcher reports
>>from early 2002, approximately 50% of the vulnerabilities were
>>released without notifying the vendor, and about 20% of those reports
>>included full exploit code
>
>Your informal study of 50% of 350 researcher reports. What exactly
>does that mean?
>
>How many of those released were one-offs?  1 person never to be seen
>from again.  How many of them were "repeat offenders" 10 of the same
>people releasing the bulk of them?

Unfortunately, I don't have that information, as the discloser's
identity was not collected (I was mostly interested in the disclosure
"timelines".)  But that's a good question...

>Your number 6 below:
>
>"The Vendor MUST provide a facility for individuals or
>   organizations who are not Customers to report vulnerabilities"
>
>This to me sounds like it is acceptable that there are going to be
>vulnerabilities. Continue cranking out shodware because we have a set
>of guidelines that people who stumble across them are expected to
>adhere to.

Vulnerabilities will happen, even in the best of circumstances, as
long as new types of vulnerabilities are discovered.  If there are 20
individuals who decide to audit a package for a new type of
vulnerability, but the vendor only has 5 developers, then it seems
like there's a good chance that someone other than the vendor will
discover the issue.  Then you've got "interaction" vulnerabilities,
which I loosely define as when a vulnerability occurs in the way that
two products interact with each other.  Developers can't always
predict how their product will be used, or how it will interact with
other products, so interaction-based vulnerabilities may be around in
one form or another.

Given the likelihood of vulnerabilities in a "perfect" world, it seems
reasonable that the vendor should be prepared to respond to incoming
reports.

>Why not draft a guideline for release of software onto
>internet. Security guideline (defaults of configs. etc.) and Quality
>Guidelines (vendor (a) is a known creator of crudware etc.).  if you
>want to connect to the interne or peddle your internet connect warest,
>you the vendor must follow these guidlines. Penalise them them if they
>fail. Fine them real money if the repeat.

This is a very interesting proposal if I understand what you're
saying, but it's outside the scope of a disclosure process document.

I can't think of any document that specific says "use
secure-by-default" (and defines what that means), "avoid buffer
overflows," "conduct third-party evaluation of product design," "make
security-based patching and configuration easy" (and try to define
*that* :-), etc.  Such a document might be useful for less-technical
customers to ask their vendors to make more secure products.  I
suspect that many customers want security, but they don't know how to
ask for it.

- Steve

Powered by blists - more mailing lists