CVE's Charter, Scope and the Role of CNAs

["Mann, Dave" <damann@mitre.org>]

Art has raised some critically important points and questions that are worth addressing in order to keep the conversation moving forward.

Dave wrote:
>> The yard-stick by which to consider these is, does CVE need to capture
>vulnerabilities from this source in order to full-fill its charter?


Art wrote:
>IMO, the bigger discussion is the future of CVE, and therefore the
>future (or revised, reviewed, refreshed) charter.

Art, we're in total agreement.

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.

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.

>1. Assign ID to vul report (More CNAs?  More active CNAs?)
>2. Manage duplicates, mistakes, etc.
>3. Refine assignments (further duplicate resolution, merge/splits, final
>arbitration)
>4. Accurate analysis
>
>Don't wait for #4 to issue a CVE ID.  Users need to be able to talk
>about "the thing" (a vul report), even (unfortunately) if "the thing"
>turns out to be a duplicate or false alarm.


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

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?

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?

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?




-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================


>-----Original Message-----
>From: Art Manion [mailto:amanion@cert.org]
>Sent: Tuesday, October 04, 2011 1:54 PM
>To: Mann, Dave
>Cc: cve-editorial-board-list
>Subject: Re: CVE Information Sources & Scope
>
>On 2011-10-04 10:39, Mann, Dave wrote:
>
>> The yard-stick by which to consider these is, does CVE need to capture
>vulnerabilities from this source in order to full-fill its charter?
>
>IMO, the bigger discussion is the future of CVE, and therefore the
>future (or revised, reviewed, refreshed) charter.
>
>Is CVE looking for original sources of vul information?  Or broad
>coverage?  Or efficient coverage of the "biggest" news in vuls?
>
>The list below is adequate if a bit dated, and duplicative (CIAC changed
>their name, CIAC and AusCERT only republish vul information IIRC).
>
>We (CERT/CC) have a similarly adequate, but dated list.  We're also
>possibly more interested in the first hints of a new vul report instead
>of something more authoritative that is ready for a CVE ID.
>
>More new vul information comes out via twitter and blogs these days.
>Seems most of it probably reaches the sources below at some point.
>Exploit lists (metasploit, exploitdb) are other sources of new vul
>information, depending on what CVE is looking for.
>
>Back to the bigger picture, I'm on the side of issuing more CVE IDs
>faster for more vul reports, having reasonable ways to distribute
>assignment and manage duplicates and false alarms.  Accurate analysis is
>great, but can come a few days after the ID is issued.  So my opinion is
>that CVE should refocus on being *the* leading, fairly comprehensive
>source of IDs (enumeration) for vul reports.  Some other capability can
>do analysis or add further value later.
>
>Goals, in time order (and as more information about a vul report becomes
>available):
>
>1. Assign ID to vul report (More CNAs?  More active CNAs?)
>2. Manage duplicates, mistakes, etc.
>3. Refine assignments (further duplicate resolution, merge/splits, final
>arbitration)
>4. Accurate analysis
>
>Don't wait for #4 to issue a CVE ID.  Users need to be able to talk
>about "the thing" (a vul report), even (unfortunately) if "the thing"
>turns out to be a duplicate or false alarm.
>
>> Government Information Sources
>>   US-CERT Advisories (aka CERT-CC Advisories)
>>   US-CERT Vulnerability Notes (CERT-CC)
>>   US-CERT Bulletins (aka Cyber-Notes)
>>   DoD IAVAs
>>   NISCC
>>   AUS-CERT
>>   CIAC
>>
>>
>> CNA Published Information
>>   CMU/CERT-CC
>>   Microsoft
>>   RedHat
>>   Debian
>>   Apache
>>   Apple OSX
>>   Oracle
>>
>>
>> Non-CNA Vendor Advisories
>>   Solaris
>>   Suse
>>   Mandriva
>>   HP-UX
>>   SCO
>>   AIX
>>   Cisco IOS
>>   Free BSD
>>   Open BSD
>>   Net BSD
>>   Gentoo (Linux)
>>   Ubuntu (Linux)
>>
>>
>>
>> Mailing Lists & VDBs
>>   Bugtraq
>>   Vuln-Watch
>>   VulnDev
>>   Full Disclosure
>>   Security Focus
>>   Security Tracker
>>   OSVDB
>>   ISS X-Force
>>   FRSIRT
>>   Secunia
>>   Packet Storm
>>   SecuriTeam
>>   SANS Mailing List (Qualys)
>>   Neohapsis (Security Threat Watch)
>
>
>
> - Art