CVE compatibility and future Editorial Board activities

["Steven M. Christey" <coley@linus.mitre.org>]

All:

With everything happening so quickly, there are many issues on the
table sooner than we expected.  With a number of Board members already
becoming CVE-compatible, various issues have come up that will need
resolution.  However, with the upcoming activities at SANS and NISSC,
there won't be much time to discuss them adequately until late
October.

Please note that the Board will be consulted on all of these points,
but things are happening so quickly I thought it was important to give
people a notion of where we think we're headed.

*** CVE Compatibility ***

0) From a relational database perspective, the relationship between
vulnerability database records and CVE entries should be regarded as
many-to-many.  There will be cases where one CVE entry subsumes
multiple database entries, and other cases where one database entry
subsumes multiple CVE entries.  Same Codebase/Same Attack isn't the
only difference in levels of abstraction that I've seen, even with
respect to software flaws.  Consider 1998's BIND problems, all
documented in a single CERT advisory.  They have 3 separate CVE
entries (CVE-1999-0009, 10, 11) but some databases only have a single
database item which encompasses all three.  There aren't many
differences in level of abstraction across databases, but as you've
seen from the SANS Interoperability Demo web pages I sent last week,
it happens often enough.

1) You can link to a specific CVE entry on the CVE web site with the
following template:

   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-XXXX-YYYY

2) On a web site, "CVE-searchable" implies that someone can use a CVE
name and get your database's entry/entries back.  You should have a
URL which allows a similar capability, e.g.:

  http://www.example.com/cve/my-db-cve-name.cgi?name=CVE-XXXX-YYYY
  http://www.example.com/cve/CVE-XXXX-YYYY.html

If you use a simple URL template, then multiple CVE-searchable web
sites can link to each other directly.  Also, having a single link
"template" should simplify the task of link maintenance, something
which many of you will appreciate ;-)

3) If you *plan* on being CVE compatible, you can make a "declaration"
that you will become CVE compatible.  We haven't formalized this yet,
but if you make a declaration and put it on your web site, we will
link to it and post the announcement on the CVE web site.

4) Similarly, if your database/tool becomes CVE compatible, we will
link to your web site.

5) As discussed during the CVE Review meetings this summer, a number
of Board members believe that it is important for MITRE to trademark
CVE in order to prevent it from being coopted or abused.  MITRE has
taken steps to do that.  To those who were not privy to that
conversation, MITRE's trademarking of CVE is *only* to protect abuse
and preserve its use for the community, and nothing more.  MITRE is
trademarking CVE in the public interest.

6) The trademark will allow MITRE to protect the use of the term
"CVE-compatible" as well, and any associated logos.  Thus
"CVE-compatible" will have some validity that other CVE-related terms
will not have.  Obviously this concept needs some refinement.
(Informally, you're CVE compatible if you've mapped most of your
database either (a) to specific CVE entries, or (b) to generics which
indicate why there's no CVE entry.  You don't have to be complete in
terms of covering all CVE entries; you need to be complete in saying
what part of your database is associated with CVE entries.)

7) As you conduct your mappings, you will have database entries that
will not map to a CVE entry.  This could be because CVE doesn't have
that database entry yet; or maybe the entry wouldn't satisfy the
requirement for inclusion in CVE (e.g. doesn't satisfy the
vulnerability or exposure definition).  When this happens, you can
label that entry with GENERIC-MAP-NOMATCH.  Note that
GENERIC-MAP-NOMATCH is the *only* generic entry that you should use at
this time.  The whole concept of generics and mapping "keywords" needs
to be revisited, and I hadn't scheduled that discussion yet.
GENERIC-MAP-NOMATCH will be a useful catch-all for the moment.


*** Future Activities ***

8) Proposal and discussion of new candidates will need to take place
soon after SANS.  Also, we will need to consider bringing on other
CNA's besides me.  It will be a challenge to handle the influx of
candidates as mappings become more complete, so the process needs to
be handled carefully.  At this moment, I am considering the following
phased approach, which will likely go on for several months:
  - I remain the only CNA at the moment, while exploring CNA issues
    with the rest of the Board
  - identify existing candidates that only need validation, and are
    not associated with outstanding content decisions
  - require mappers to validate these candidates before submitting new
    candidates
  - Mappers look at their databases and identify
    - high-risk vulnerabilities discovered since April 1999 (the date
      the draft CVE was completed)
    - high-risk vulnerabilities in the past 3 years
  - I obtain all high-risk entries from mappers and propose
    more candidate clusters
  - We begin slowly introducing the "live" candidate process,
    initially focusing on high-risk candidates
  - We identify how to make CVE candidates available (and to whom)
    while avoiding accidental adoption of the CAN name as the
    "standard"
  - We identify other CNA requirements, issues, and guidance
  - We bring in new CNA's
  - We "back-fill" other CVE entries once we are caught up on all the
    high-risk problems


9) Board membership and voting.  There have been a number of requests
to join the Editorial Board.  While current Board members have been
satisfied with keeping Board membership rules informal, there needs to
be a more established process for membership.  Some membership voting
mechanisms were discussed at the CVE Review meetings, but those have
yet to be put in place, and they need full consideration by the Board
as a whole.  Until then, MITRE will only appoint new Board members on
a very limited basis.  There are several gaps in the current Board
composition that should be addressed.  In addition, it has become
clear that there are not enough validators of specific CVE candidates;
while many Board members vote, other responsibilities prevent them
from validating every candidate, and I believe that the "ebb and flow"
of voting patterns will prevent CVE from being updated quickly enough,
unless we get more voters.

10) We need to consider when the next face-to-face Board meeting can
take place.  Early December may be the best time, as it's two months
away and leaves time between two major U.S. holidays.  Are there any
Board members who want to host it?  In addition, the teleconference
during the CVE Review meeting was fairly successful.  We could
schedule a teleconference in mid-October or late October.



- Steve