CVE's Scope

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

All,

A while back we asked for your initial input on a list of must-have and nice-to-have sources for vulnerability information that CVE should cover.  We wanted to give you an update on where we are with things and to prepare you for some upcoming discussions.

The first thing that bears mentioning is that we recognize that this is a very significant and potentially difficult discussion for the CVE community.  We are explicitly discussing a reduction in scope for what CVE will aspire to cover - stepping away from our long-standing goal of providing IDs for "all publicly known vulnerabilities".

Because of the importance of these decisions we would ask that you all prepare to engage with one another in email discussions on this list, in some teleconferences and, hopefully, a face-to-face meeting later this summer.   In a separate email, we'll put out a request for guidance on times for telecons and possible dates for a meeting.

The second thing to note is that this email will not cover all of the topics we need to discuss.   We have a whole series of things we need get your input on and we're going to try to parcel them out in a way that will help make the discussion more productive.  

Topics in this email:  sources as "jurisdictions", full coverage vs partial coverage sources

Topics in upcoming emails:  some partially covered nice-to-haves, Linux issues, things we should cover but currently can't


SOURCES AS "JURISDICTIONS"
---------------------------
As a community, we must accept that the MITRE CVE effort cannot, on its own, assign identifiers for all vulnerabilities in all software as publicly disclosed in all sources.  Instead, we must look for ways to effectively cooperate with other efforts that either currently exist or that might emerge in the future.  For this to work, we believe that a necessary first step of cooperation will be the need to agree on who is issuing IDs for what.

We would like to suggest an analogy; that of cooperating police forces.  Police forces tend to exist along-side of each other and a part of their cooperation is the definition of their respective jurisdictions.

Arguably the most radical proposal we are making is to define CVE's jurisdiction in terms of "information sources", and not in terms of products.  By information source we mean any form of print or electronic media that: a) is published by some legal entity and b) is published in a recognized form and location.  Examples would include web sites (e.g. Microsoft), databases (e.g. OSVDB) and mailing lists (e.g. Bugtraq).

As a team, this way of talking about what we'll do and not do feels foreign to us.  We feel like law men who are used to riding across the open range of the territory and are now confronted with a new state line that we are supposed to stay inside of.  In choosing to focus our energies on some sources and not on others, we are forced to acknowledge that there will be some-high priority issues that we don't cover because they appear in sources that we don't track.

We do not expect that you will be able to adequately judge the merits of defining our scope/jurisdiction in terms of sources until we've had time to explore its implications together as a community in more detail.  For this reason, at this point in time we would ask that you reserve judgment on this approach until we've had time to explore its ramifications and possibilities.  



FULL COVERAGE VS PARTIAL COVERAGE
----------------------------------
We would like to propose 2 primary classes of sources: sources that we intend to fully cover and those that we will monitor but only partially cover (like a highway being patrolled for speeders). In defining these groups, we emphasize that these are only our first attempt in defining meaningful boundaries for scope. We seek to balance the need for clarity of scope with the need for appropriate flexibility.  We recognize 3 groups:

FULL COVERAGE SOURCES - There are some information sources for which (practically) all vulnerabilities disclosed in that source need to be associated with a CVE ID.  We will refer to these sources as "full coverage" sources.  Examples include but are definitely not limited to: Google, Mozilla, Adobe, Apache Software Foundation, Microsoft and Apple.

LISTED PARTIAL COVERAGE SOURCES - There are some information sources that we can identify and list that we should actively monitor but, for a variety of reasons, it doesn't make sense for us to attempt to associate a CVE for every issue disclosed in that source.  We will refer to these sources as "listed partial coverage sources".  Examples might include some vulnerability information web sites and databases that include large numbers of vulnerabilities that might be considered "low priority".  The set of specific sources in this category will be one of the things we need to discuss as a community.

UNLISTED PARTIAL COVERAGE SOURCES - There are some information sources that we are aware of and monitor as situations merit but that don't warrant us listing them nor attempting to assign CVE ids for all issues discussed in them.  Examples might include things like blogs published by leading vulnerability researchers, conference proceedings,  press outlets such as magazines and e-zines and some individual researcher web sites.  One reason we may choose to recognize this as a class of sources is that history tells us that there are high-priority issues that get disclosed in these sources but the value in tracking these sources on an on-going tends to ebb and flow.  


Your comments and initial reactions are actively sought. More will be posted soon.

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