RE: The CVE-10K Problem

[<Kent_Landfield@mcafee.com>]

We are not going to be able to avoid having developers change the CVE
format handling with whatever we do.  Some may have checks for only
digits while some may have checks for a specific number and type of
characters. Some products treat the ID as a textual reference string
with a format validation routine that may examine specifics to assure
good data is being injected.  Some examine using regex, some by
examining each individual element of the format.  Whatever is decided,
changes will need to be made.  

Changes were made when CAN- was removed and the CVE entry status became
an internal element.  Tool vendors did not have a real problem with it.
That change affected different processing because code needed to be
removed for the graduation processing, search mechanisms, and the
existing CANs had to be converted to CVEs in the tool databases.

What we should be looking at is what we feel is the best solution for
the long term of CVE. Personally, 1 or 4 works for me.  Hercules has it
stored in a text field 50 characters in length so extending it is not an
issue for us. One minor change to the validation routine and we are
ready to go. 

The key is communication so we alert people this is coming and they
should be looking for and making changes as necessary to support the
decision.  We still have a little time. Set a date when the decided
change will be made and give people enough time to deal with it. 

We should just pick what is best for CVE without creating any additional
limits we may see come around again.

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
kent_landfield@mcafee.com
www.mcafee.com
 

-----Original Message-----
From: owner-cve-editorial-board-list@LISTS.MITRE.ORG
[mailto:owner-cve-editorial-board-list@LISTS.MITRE.ORG] On Behalf Of
Adam Shostack
Sent: Friday, January 12, 2007 4:53 PM
To: Steven M. Christey
Cc: cve-editorial-board-list@LISTS.MITRE.ORG
Subject: Re: The CVE-10K Problem

On Fri, Jan 12, 2007 at 05:20:28PM -0500, Steven M. Christey wrote:
| 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
| 
| 2) Completely randomize the year portion.  We've considered this for a
|
| 3) Adding 1000 to the year.  Benefit: introduces predictability, and
| 
| 4) Keeping the year, and extending the numeric portion to 5 digits.
| 
| 
| 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.

(Speaking for myself)

I don't think we should be tying a CVE shift to the possible need to
address huge changes in the vulnerability management space.  What
those changes will look like is hard to predict, and it may be that
having a large CVE namespace will make it easier.

I think 1 is the right direction, and would like to advocate for 1',
which is that the last 4 characters of the CVE be 0-9 and the
alphabet, perhaps case sensitive.  (I would urge that the first two to
be issued would be 2007-000a and 2007-000A to drive home the point,
and then work to avoid use of capitals, I, O, and S for readabbility
reasons.)  This gives us a large namespace without needing to redefine
data tables.

I think (3), adding to the year simply shifts the problem out 1000
years, and is thus shortsighted.

Adam