Re: The CVE-10K Problem (fwd)

[pmeunier <pmeunier@cerias.net>]

Steven M. Christey wrote:
> 
> ---------- Forwarded message ----------
> Date: Fri, 12 Jan 2007 17:20:28 -0500 (EST)
> From: Steven M. Christey <coley@mitre.org>
> To: cve-editorial-board-list@LISTS.MITRE.ORG
> Subject: The CVE-10K Problem
> 
> All,
> 
> Well, it's that time.  For 2006 so far, we've nearly assigned 7000 CVE
> identifiers.  We don't have 100% completeness, but I'd say that for
> the usual sources (major vuln DBs, vendor advisories, Bugtraq etc.)
> there might be another 100 to 1000 CVE's for 2006.
> 
> Given the continued vulnerability growth trends, it's a real
> possibility that in 2007, we run the risk of assigning 9,999 CVE's for
> issues.  What to do with the 10,000'th entry is the CVE-10K Problem.
> 
> Here are some possible solutions.  Feedback appreciated.  We can cover
> this topic in an upcoming telecon, too.
> 
> 1) Keeping the year and moving to hex-based... CVE-2007-9999 would go
>    to CVE-2007-A000, etc.  Problem: would probably break many apps
>    that assume digits only.  Benefit: we could handle 65,000 ID's in a
>    single year.
> 
> 2) Completely randomize the year portion.  We've considered this for a
>    number of reasons, because too many people make assumptions based
>    on the year portion of the ID already - sometimes it's date of
>    disclosure, sometimes it's date of assignment, sometimes it's
>    because of a typo from an authoritative source.  Randomization
>    would help in some other ways, too.  This is the most radical
>    approach but has some strengths.  Problem: any crude usability is
>    lost.  Benefit: the possible space of 100 million identifiers
>    allows us to pass the problem onto the next generation :) but also
>    might allow for less tightly controlled allocation of CVE's
>    (although reduced control has serious negative consequences on
>    CVE-based quantitative analyses and maintenance costs, so this is
>    only a possibility).
> 
> 3) Adding 1000 to the year.  Benefit: introduces predictability, and
>    it's one of the least radical approaches.  It buys us some time.
>    Problem: only increases to 20,000 identifiers in a year.  Bigger
>    problem: the identifier is likely to be thought of as a typo by
>    many readers, and automatically "corrected" to the current year,
>    which would be an identifier for the wrong issue.
> 
> 4) Keeping the year, and extending the numeric portion to 5 digits.
>    Benefit: this preserves the CRUDE utility of the year portion and
>    doesn't introduce any alphabetic characters.  Problem: some
>    tools/products/databases might assume only 8 total digits instead
>    of 9, so one digit could get lopped off.  Maintenance costs would
>    be greater than #2 and #3.  It also might affect sorting, but in
>    the grand scheme of things, I'm less concerned than I used to be.

I'd much prefer #4 because it doesn't introduce new semantics, and it is 
simple.  The fact that the year portion is crude is a separate 
quality/budget issue (see below).  I would also use 6 digits instead of 
5, so this doesn't happen ever again (I hope), and because I see the 
scope of the CVE as international, there could be a lot more entries as 
more countries start developing more software (e.g., India;  see below 
again).

> 
> 
> Handling over, say, 20K issues in a year would likely require a
> paradigm shift within the entire vulnerability information management
> industry.  As Dave Mann has pointed out to me numerous times, the
> growth in the number of vulns is outpacing the growth in CVE funding,
> which has been mostly flat with respect to content generation itself,
> with increasing risks of our funding actually being reduced (I don't
> think most people understand why good vulnerability information isn't
> cheap.)  Anyway, I suspect that this growth problem is hurting other
> vuln databases/products, too.  We're already seeing some of that
> paradigm shift; the Board gave up voting a while ago due to the amount
> of effort, you're seeing more generic vulnerability database entries
> with more mistakes (probably being made by less experienced analysts
> with less editorial oversight), the percentage of verified issues is
> probably smaller, etc.

Funding for the CVE should be a requirement for the DHS, at whatever 
level is needed for it to function correctly and without undue stress on 
team members.  The CVE is a necessary foundation for vulnerability 
handling and research (or as I said before, "the key"), and many aspects 
of security.   From what I surmise the strain is at a critical level and 
if funding isn't increased the CVE will cease to be useful and worth 
doing -- this is close to an all or none operation.  The more 
vulnerabilities are "missed" the more useless it is, and I'd venture 
that it would have close to zero usefulness if any more than 50% of the 
vulnerabilities were missed, not to mention correctness issues.  It 
would be just as useless as a dictionary missing common words, or having 
words with the wrong definition.

If the CVE team can't be funded at a sufficient level, I regretfully 
suggest that the time and effort of its talented members would be better 
spent elsewhere, at a more rewarding activity.  We would suffer greatly 
from that, but if we as a society are not willing to pay for it, we 
don't deserve it.

In actuality, the CVE should be a global, international project because 
all of IT in the world benefits from it and depends on it.  Also, 
vulnerabilities are more and more being generated worldwide (e.g., 
through branches or offshoring).  Perhaps a European CVE effort could be 
started, funded by the EU (or an Indian effort, etc...). Ultimately (and 
I don't know what mechanisms and hassle that implies) it should be 
funded at a global level, and the numbering done by a global 
organization like WHO or IMF.  Just by curiosity, what is the make-up of 
the editorial board?  Is there any international presence?

Regards,
Pascal Meunier
Purdue University CERIAS