Re: What is the future of CVE - Scope, Volume & Quality?

[Art Manion <amanion@cert.org>]

Reading mail backwards today...

On 2011-09-19 14:46, Mann, Dave wrote:

> Let me emphasize that we agree with both questions.  Resource discussions and analytical process are critical things for us to discuss as we consider CVE's future.
> 
> But until we can agree on the must haves, we can't make progress on those fronts.
> 



> We strongly suggest these are the 2 most important first questions:
> 
> 1. Sources
>   a. Which sources of vulnerability disclosures should be considered 
>     "must haves" for which we provide "reference complete" coverage?  
>   b. Which sources should be considered "nice-to-haves"?
>   c. Which sources should be considered "can be safely ignored" 
>     (e.g. they just cause noise)?
> 
> 2. Coverage
>   a. Which vendors and software products should we consider "must haves" 
>      in that we will provide coverage for all reliable vulnerability 
>      reports for them?  
>   b. Which products or vendors should be considered "nice-to-haves"?
>   c. Which ones should be considered "can be safely ignored" (e.g. php.golf)?

These are the same question, or 1. depends on 2.  IOW, if we know what
vendors/products we want to cover, then we can figure out which sources
to monitor.

golf.php gets posted in bugtraq, as does a remote code execution bug in IIS.

US-CERT Alerts, as of the last several years, are mostly republication
of Microsoft, Oracle, Apple, and Adobe vulnerabilities.

"Reference complete" would be great, but perhaps not worth the
investment.  OSVDB seems to be aiming for this.

What about:

1. big/core vendors/apps
2. anything a CNA assigns an ID for
3. everything else

Make 1 and 2 priorities (IOW, resource to meet 1 and 2).  CNAs should be
expected to pony up some resources to assign and de-duplicate IDs.

Need to define 1, which is at least started in the list you sent out.

Leave 3 for a slow week, or really just ignore it, unless somebody
cares, in which case it should rise to the level of 2 when a CNA assigns
and ID for it.

And make it clear to CVE users that CVE is *not* reference complete, and
not trying to be.  Make it clear that the count of CVE IDs per year is
at best a lower bound on the number of public vul reports that year.

Maybe another way to look at this is to decouple most of the analysis
from the assignment work.  Yes, correct assignment requires at least
enough analysis to distinguish separate or related vul reports.  Make
further analysis an add-on service, "CVE+analysis" or something.


 - Art