Re: CVE's Charter, Scope and the Role of CNAs

[Art Manion <amanion@cert.org>]

On 2011-10-04 16:24 , Mann, Dave wrote:

> CVE's original charter was to cover all publicly known vulnerabilities.  We concede this is impossible as a practical matter.  Internally, we've been discussing restricting this to all publicly known English-based vulnerability disclosures.
>
> Please note, I don't mean to prematurely exclude non-English disclosures from consideration.    I think it may eventually be possible to talk about non-English disclosures and, as you've indicated, more involvement of CNAs is going to be a part of the solution.  But I want to ensure we're hitting the must-haves in the English-based sources first.

Despite what probably comes over as criticism of CVE, we at CERT/CC have
faced exactly the same problems.  For years we tried to cover everything
(I personally did this work), distinguish unique reports, duplicates,
"real" vulnerabilities, etc.  Then XSS came along...

> So, by all means, if you feel that there are non-English-based sources that are "must-haves", please call them out.  More broadly, let's not restrict the scope or charter of CVE based on current processes in any way.  Let's please discuss what needs to be covered by CVE first and then we talk about process to achieve that second.

We do lightly monitor a handful of Chinese language blogs.  Not sure I'd
call them must haves but in any automated collection, subscribe,
translate, and match up resulting English words with English words from
other sources (or a watchlist, or a search, or whatever).

> You're going in directions that our thinking is going too.   If it's useful to think about solutions even as we discuss goals, I want to toss out 2 very, very hard problems that I think we should start thinking about now:  
> a) Economic incentives for SME produced content (specifically applied to CNAs)
> b) Level of abstraction issues

I'm prone to jumping to conclusions/solutions :)

> ECONOMIC INCENTIVES - It is worth emphasizing that MITRE continually seeks the involvement of new CNAs.  We are (and y'all should be) extremely grateful for all of the CNAs that participate.  Our experience is that CNA relationships work out when an organization has mature enough vulnerability information practices and, as a result, they incur relatively low marginal costs in terms of issuing CVE IDs.    This level of maturity varies widely, based on what we see.  
> 
> In many other areas of cyber-security information provisioning, we see lots of appeals to various forms of "crowd-sourcing" content creation.   The problem is, good content requires good SMEs and good SMEs are expensive.  The question becomes, what are the economic incentives for organizations to fund SMEs to act as CVE CNAs?

Yes, while crowd-sourcing has it's benefits (mostly leveraging others'
resources), we've all seen bad vul information get picked up and
rebroadcast.  I think (but am not sure about this) that CVE will have to
accept some crowd-sourcing help (to distribute coverage and increase CVE
assignment speed, if those end up being goals).  Perhaps having a
smaller crowd of mature CNAs will help, or having CNAs act more as
distribution centers and arbitrators, with MITRE being the ultimate
arbitrator (but not having to touch content decisions that a CNA handled
well/correctly).

> We've been looking hard at many other identification systems that have successfully federated their content creation. Economically, we see 2 primary models: ISBN and VIN.  ISBN numbers are produced by publishers because they are routine and easy to assign (compared to CVEs) and there is an economic benefit for doing so.  VINs are assigned by manufacturers because (in the US) the DOT mandates it.
> 
> MITRE is already beating the bushes for CNAs and we have the set of CNAs that we have (and are grateful for).  How do we expand that set?

CERT/CC acts as a proxy CNA for a couple other CSIRTs -- most likely
those CSIRTs could become successful CNAs with a little further
training/monitoring.  Maybe the board could come up with a list of new
CNAs?  As for incentives, the driver I'm familiar with is U.S.
Government and enterprise who want (need) to scan/patch/comply/manage
vulnerabilities, and the associated vendor space.  So maybe the
"security vendor" space has a horse in the race?  A handful of CSIRTs
and vulnerability databases might step up as they have inherent desire
to document things well.

Some vulnerability reporters/researchers (now we're getting to the
"crowd" more) often ask for CVE IDs, they also seem to want to document
their work properly, like ISBN.

Vendors whose customers are in the USG/enterprise set also seem to
recognize the value in proper documentation (including CVE ID) -- also
like the ISBN model.  So vendors with mature vulnerability response
capabilities might be CNA candidates.

USG might not mandate CVE IDs (like VINs), but USG use of CVE IDs
encourages others to use them.

> LEVEL OF ABSTRACTION - There are 3 LoA questions to start thinking about.  First, can we deal with significant drift in level of abstraction among CNAs?  Will we be able to fix duplicates from different CNAs if/when they are assigning IDs at different LoAs?    
> 
> Second, is CVE's current LoA (which grew out of vulnerability practices in the late 90s/early 2000s) too low for today's vulnerability management practices?   
> 
> Third, combining these first two questions, can we live with a CNA that is committed to the ideal of "silent patching" and, in their role as a CNA, assigns CVE IDs on a "per patch" basis with no further information?   Those of us who dealt with vulnerability information back in the 90s remember the "silent patch" days.  Would it be acceptable moving forward?

I think CVE will have to deal with different LoA.  Along with
"duplicates" and "false alarm" consider relationships like "extends" or
"is subset of".  This could allow one CNA to assign an ID for a report
(of say multiple XSS vuls).  If someone wants to go lower, a CNA can
assign IDs for specific XSS vuls, the IDs are related with a
well-defined predicate.  As more information becomes available, CNAs or
MITRE (the ultimate CNA) can "fix" LoA without removing existing IDs.

Not sure I know if the current CVE LoA is too high or too low.  I think
it needs to become more flexible.  My suggestion is that a CVE ID names
a "report of one or more vulnerabilities."  Ideally, this would be one
vulnerability, by some best LoA practice, probably similar to the
existing CVE rules.  In practice, it won't always be just one
vulnerability, but the "is subset of" and other relationships might
allow drift, hopefully drift towards "accuracy," and at least tolerance
of multiple LoA for the same "vulnerability."

If a vendor is going to publish a patch with a CVD ID and no information
about the vulnerability -- what's the point?  Is there anything to
identify?  I guess there is, but there'd be little or no hope of ever
relating that ID to anything else useful (like Oracle fixing bugs and
not referencing public discussion of the bugs).  I guess I'd like CVE to
strongly discourage such behavior, so maybe require CVE IDs have some
description/reference?


 - Art