[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: The CVE-10K Problem (fwd)
- To: "Steven M. Christey" <coley@rcf-smtp.mitre.org>, cve-editorial-board-list@LISTS.MITRE.ORG
- Subject: Re: The CVE-10K Problem (fwd)
- From: pmeunier <pmeunier@cerias.net>
- Date: Tue, 16 Jan 2007 13:57:01 -0500
- Delivery-Date: Tue Jan 16 13:57:08 2007
- In-Reply-To: <Pine.GSO.4.51.0701122255560.3932@faron.mitre.org>
- References: <Pine.GSO.4.51.0701122255560.3932@faron.mitre.org>
- User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
My first attempt to post to the list was rejected due to an email
address change. Here it is again; please scroll down, my answer has 2
parts:
Steven M. Christey wrote:
> 4) Keeping the year, and extending the numeric portion to 5 digits.
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