RE: Counting on CVEs

[Tim Keanini <tkeanini@ncircle.com>]

In my understanding to this thread, Kent raises three main points: 
- The count of members who are of the set CVE (by the people who count
CVE)
- Technical Limitation of the CVE name (namespace boundary)
- The operational quality and quantity of resources within the CVE
counting process (how a CVE comes in to being)

The crux of the problem as a I see it goes something like this: if the
desire is for CVE to be canonical and primary for every vulnerability
reference on a global scale, it certainly is not resourced that way and
the operational resources to really success at this goal is unknown at
this time.    

Unless someone can argue otherwise, the growth limits with CVE counts
over the years has more to do with the process capacity to do the
counting and not the expansion of things to be counted.  If this
assertion is true, we have at least two choices: 

Option A- address the operational resources required to get to the
resolution required by the market to count these items.  There will
always be some tolerance because this can never be perfect.  Once
identified, some business model must be put in place to sustain growth
and quality.
Or 
Option B- create a more ontological model that considers CVE not the
primary or root but just another piece of metadata use to reify some
other assertion.  As a vendor, I can only control what I can control and
that is my own internal ID which are organizationally closed for my own
data integrity. 
nCircle-ID-667 -has-CVE-ID-> CVE-xxxx-xxxx
nCircle-ID-667 -has-CVE-v2-ID->
CVE-xxxx-xxxx-withextension-yyyy-for-future-format
nCircle-ID-667 -has-Secunia-ID-> Unique-Secunia-ID
nCircle-ID-667 -has-OSVDB-ID-> Unique-OSVDB-ID
(for those of you who know me, I would rather be working on a standard
ontological model that any vendor interoperate no matter what the
resolution or primary identifier.  The goal of interoperability should
be to compute syntactic or semantic equivalence )
Call me pragmatic but this is an example of what I have done, not asking
for anyone else to follow.  Just needed an example where CVE was not
primary but one of the inverse-functional-properties that can be used
for saying that this is the same as that (compute equivalence) 

Call me old and jaded but I just don't see how the CVE operational team
gets the resources they need to succeed when no one is really paying for
the quality or quantity of their efforts.  I mean this with the utmost
respect for that team since I know most of the members personally and
know the tireless hours they put in.  "NOW GET OFF MY LAWN!" :-)

--tk



-----Original Message-----
From: owner-cve-editorial-board-list@LISTS.MITRE.ORG
[mailto:owner-cve-editorial-board-list@LISTS.MITRE.ORG] On Behalf Of Art
Manion
Sent: Thursday, March 08, 2012 2:56 PM
To: Boyle, Stephen V.
Cc: cve-editorial-board-list
Subject: Re: Counting on CVEs

On 2012-03-08 11:52 , Boyle, Stephen V. wrote:

> This might sound like splitting hairs, but how "vulnerabilities" are 
> counted may well enter into this. I'm not claiming that CVE is keeping

> up - both Kent and others have correctly stated reasons and history 
> that apply, and yeah, somebody who's only looking at somebody's raw 
> numbers (be they CVE or anything else) is going to ask hard questions,

> especially when money is hard to come by.
> 
> Having said that, it bears mentioning that by design, there are always

> going to be fewer CVEs than there are "vulnerabilities" - it's kinda 
> one of the key features. JThere are also more players in the space 
> than there were a few years ago, each of which has multiple incentives

> to publish more vulnerabilities than others.
> 
> Again, I am not saying there's not a problem - we have to be able to 
> answer honest questions such as the one Kent relayed. But we also have

> to be mindful of what are real, what counting problems exist in all 
> vulnerability reporting sources, and what that means for CVE.

The questions remain IMO:

1. What level of abstraction is appropriate for CVE?

2. What level of completeness is appropriate for CVE?

How narrowly do we define "vulnerability," the thing to name/count?

Is there desire/need for an accurate count of vulnerabilities?  OSVDB
either abstracts a little more narrowly than CVE and/or collects more
vulnerabilities, so OSVDB has higher numbers.

If CVE or any other database were to try to name and count all publicly
disclosed vulnerabilities, it would be important to be able to
distinguish between a vulnerability that is one of a dozen XSS bugs in a
PHP web app and a vulnerability that is a straight up stack buffer
overflow in httpd.  Sure, count them all, but be able to say that out of
20K vulnerabilities named this year, 61% were XSS or SQLi in web apps
with low distribution.

I'm guessing at some numbers in the above example, but this is a big
reason IMO that CVE numbers have declined.  Vulnerabilities "worth
tracking with a CVE" have declined, not the total number of
vulnerabilities.  Another way to look at it might be that thee criteria
for "worth tracking with a CVE" has changed.

And we're not even talking about threat or asset values (both of which
have changed over time, and are different depending on your
site/assets), which influence risk.  So a decrease in CVE IDs has little
directly to do with internet risk overall.


 - Art