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

[Mark J Cox <mjc@redhat.com>]

> 1. Can CVE effectively keep up in the face of an increasing volume of 
> English-based disclosures?

It seems to me that the resource issue is a problem at the moment; for 
example we are building up a steady backlog of CNA allocated issues that 
are not yet in CVE (over 300 issues).  Are there ways you can add staff 
to deal with specific tasks without increasing the chance of CVE 
duplications?

> 2. What relationship should CVE have with any international effort (such 
> as IVDA) to identify vulnerabilities disclosed in non-English based 
> markets?

It would be interesting to have a wider discussion with the bigger vendors 
about non-English disclosures.  All the work I've seen on disclosure 
dates, days of risk, and so on have taken a public date from an english 
dislosure, and not counted non-English disclosures.  The problem probably 
isn't non-english disclosures of issues that affect english software, but 
rather non-english disclosures affecting non-english vendors.  Could that 
be solved by having a regional CNA and making CNA's do more work (at the 
moment the work ends after allocating a name, there is no notification 
aspect to Mitre as you mentioned).

> 1. Sources

http://www.awe.com/mark/blog/2009030319.html

So half of the issues we find out about after they are already public are 
from the mailing lists "full disclosure" "bugtraq" and "oss-security" 
only.  Although another quarter are by us tracking other peer vendors and 
upstream projects who monitor different subsets of lists.

I'd like to see something like this from Mitre; where did the majority of 
your issues come from, how many were assigned by a CNA, etc.

> 2. Coverage

Maybe the rule could be that you will cover vendors that fix at least N 
(100?) vulnerabilities a year by monitoring their lists, and for smaller 
vendors you expect them to mail to one of the sources you define that you 
monitor.

> 3. Response Time

I'd be curious in usage stats from the web site (and perhaps NVD) which 
you could compare to your response times to determine if you are choosing 
the right subset of issues to be interested in.  I suspect that 90% of the 
vulnerabilities get little traffic, are those the ones you dealt with 
slower?

Could you make a CNA give you some draft details of an issue prior to it 
being analysed by your own staff?  For example Red Hat would assign a CVE 
to an issue on oss-security, enter a brief description and URL to the 
Mitre site, and it would appear as a 'preliminary' description (either 
automated like we used to do on NVD, or via some quick human analysis).

I could even see it being tied into your log analysis so that some spike 
on a particular CVE would cause it to get bumped up your queue.

> 4. Quality
>  a. What rate of duplicate CVE entries can be tolerated?
>  b. How consistent does CVE "counting" need to be relative to past
>     counting practices and content decisions? ("Counting" here means
>     the relationship between a given vulnerability and the number of
>     CVEs needed to correctly describe it and vice-versa. These may be
>     one-to-one, one-to-many, many-to-one, or many-to many.). We believe

I believe that the duplicates tend to solve themselves over time and don't 
cause particular harm.  Even after nearly 10 years allocating CVE's I 
still have difficulties with some corner cases and end up looking at the 
old content decision pages or trying to get hold of Steve.  Perhaps some 
training for CNA's would help (or some yearly quiz/test/refresher).

Thanks, Mark
--
Mark J Cox / Red Hat Security Response