RE: Sources: Full and Partial Coverage

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

Kent Landfield wrote:
>Yes I fully understand what you are asking is necessary but I think we need
>to look at the root cause for these questions.  Am I correct in asserting
>that this is a our funding issue?  If you had twice the funding, would we
>be having this conversation ?


Kent, we would definitely be having the conversation.  Simply doubling CVE funding won't address the core issues we face. 

The feeling by everybody on the CVE team is that CVE is not keeping up with the need (whatever "the need" is) and we know that staffing, resources and process changes will all need to be considered as a part of any solution.  In fact, we've been publicly discussing the issue of CVE staffing levels on this list.  Last September, in response to questions about CVE's staffing levels, I wrote:

"There is no rational way to say that CVE's resourcing level is too low or too high unless we can compare CVE's performance to an agreed upon set of "must have" goals in terms of information sources and products covered."

We stand by this statement.  While we need to discuss staffing, we must address the core issue, which is the fact that the vulnerability disclosure landscape has evolved and the CVE project needs to evolve in light of this.  Here are three of the changes we see, all of which lead us back to the core question of CVE's scope:

THE RISE OF INTERNATIONAL SOFTWARE MARKETS - International software markets such as those in Brazil & South America, Europe, China and Japan are growing and maturing. Vulnerability disclosure happens in very different ways in these markets due (in part) to differences in liability and regulatory structures.  Our coordination with other international vulnerability disclosure capabilities has taught us that CVE will need to be one of several ID systems. For CVE to effectively coordinate with other ID issuers, we need to be able to state what CVE covers and what it does not.

THE "APP" EXPLOSION - It used to be that software vendors were the primary source of software. Now, pretty much anybody can publish an "app".  The canonical example on the CVE team is phpgolf (see: http://www.phpgolf.org/). Even if php.golf has a bug that is remotely exploitable, we're pretty sure that enterprise customers aren't demanding CVE coverage for it.  In fact, we're pretty sure that CVEs for things like phpgolf or the entire CNET download app archive introduces unwanted noise.  Since its inception, the CVE project has made implicit priority decisions on what to cover and what not to cover.  In the face of a growing software and application landscape, we need to make our prioritization more explicit.

THE RISE OF COMPLEXITY - Operating systems are more complex.  Web applications and their interactions with browsers are more complex. Data and its interaction with "readers" and "players" has become more complex. Exploits are becoming more complex. Even as the sheer number of vulnerabilities is increasing, so is their complexity.  Triage and prioritization has become a necessity, but for this to happen in a reasonable way we need to discuss scope and prioritization of information sources.



>The Board could be useful for other than just talking about sources and
>vulnerability priorities but we need to understand the full situation and
>not beat around the edges.

We agree.

Another change that has taken place in the past 10 years is the growth of other related cyber-security standards and coordination activities with formal standards bodies.  It is important for the CVE Editorial Board be aware of and engaged with the full situation in which CVE exists. This is why we put out a summary of recent activity at the IETF in posting to this list in March. In it, we gave our initial guidance on the subject and included a request for other board members to provide more information.

However, as important and demanding of our attention as these other issues are, there is a risk of the community assuming that "good ol' CVE" is just humming along and working fine when, in fact, it is not. 

The vulnerability disclosure landscape has shifted and CVE needs to recalibrate.    

For the first time in our history, we need to more explicitly define the scope of CVE.   We must  and will talk about staffing levels, quality, process changes and the implications these all have on standardization efforts.  But we believe that if CVE is to survive in a new landscape, we first need to agree on its scope.



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