Re: CVE ID Syntax Vote - results and next steps

[Adam Shostack <adam@homeport.org>]

On Thu, Apr 18, 2013 at 02:41:14PM -0500, security curmudgeon wrote:
| On Thu, 18 Apr 2013, Art Manion wrote:
| 
| : Another future scale issue:  Automated ways to find vulnerabilities 
| : could overwhelm the current 10K/year human-scale size of the problem.
| 
| That is the primary example Carsten Eiram and I offer. A system where an 
| automated code analysis tool can essentially auto-assign a CVE for each 
| one found. We know the current state of this would mean an incredible 
| number of false positives, so I can't see anyone arguing that CVE should 
| ever move away from some level of manual review for assignment.
| 
| Unless a company demonstrates a scanner that is > 90% accuracy, that 
| absolutely should not happen. Even then, if we're seeing a CVE assigned to 
| every valid vulnerability, no matter what the exploitation criteria are, 
| then we're also ignoring the current policy of grouping similar 
| vulnerabilities in similar versions. That also works against the argument 
| we're putting forth saying "maybe 1MIL can be reached".

Let's assume for a moment that we actually have such a scanner.  For
example, a fuzzer plus toolchains that assess exploitability.  (Of
course, such a fuzzer may generate the same cases repeatedly.)

Here I think we need to think about the CVE use cases.  CVE is at its
most useful at the boundaries between disciplines.  To my mind The
tool output you're describing here is more akin to a bug identifier
than a CVE.  If you're tracking software changes through an open
source project, and managing backporting of security fixes, I can see
that bug ID being useful to you as a tool for communication between
package maintainers, and I can even see where someone outside would
use it.  For example, if Alice is checking that a list of CVEs
associated with Bob's DNS server as part of Charlie Linux have been
patched, she might get a list of CVEs and use them to check.

In this case, I think it might be more useful to assign a CVE to a set
of bugs which get updated at the same time.  (This may be analagous to
practices by my employer, but I am, per your implied request, not
representing them here, but considering the question of what's best
for the communities served by CVE.)

This does not perfectly address Alice, Bob or Charlie's needs.  But
perfectly addressing those needs means that Bob's typical customers
get an incredibly long list of CVEs with each update, and all they
care about is "am I up to date."

So if we want to support such a thing, we'd need to argue that ease of
use for the community that's backporting fixes outwieghs ease of use
for the broader sysadmin & vuln management communities.

Adam
Speaking for myself