CVE Compatibility - High Level Requirements

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

All:

Below are the high level requirements that we see are necessary for
establishing CVE compatibility.  We are working on formalizing this,
but we may not have one ready until after this week's NISSC
conference.  Your feedback is encouraged.

Since "CVE-compatibility" should be a phrase that carries a certain
weight to it, some of these requirements are designed to prevent any
arbitrary organization from claiming CVE compatibility without going
through the process of verification.

1) The organization should be a legal entity (e.g. a corporation or
named individual.)

2) A user should be able to search the repository using a CVE name.
[For tools, a user should be able to provide a list of CVE names and
have the tool "select" or "deselect" the appropriate actions, e.g. a
probe or signature.]

3) The repository should be able to report results that include the
CVE name.

4) The organization must provide a mapping of their repository to
MITRE.  The mapping should include GENERICs where necessary.  (This
allows MITRE to determine accuracy and use the GENERICs to identify
other items that may need to be added to CVE.)

5) MITRE (or a Board-approved authority) will confirm accuracy of the
mapping, by ensuring that a sample of the mapping has a high degree of
accuracy.

6) The organization should sign a "Good Faith" statement on
maintaining the accuracy of their mapping.  [The intention is to
prevent an organization from abusing the concept of "CVE
compatibility" for their own purposes, e.g. to inflate marketing
claims.]

7) CVE compatibility is specific to a particular CVE version.  MITRE
may recommend various "reference versions" (e.g. the last version of
each month) that organizations should use to establish compatibility.
Reference versions will be important for head-to-head comparisons of
tools and databases.

8) Some formal notification (e.g. a memo on MITRE letterhead) will be
required before the organization can use the "CVE-compatible" logo.


"CVE-compatibility" will only be used to verify the accuracy of how
the repository links to CVE names.  There will be no requirements on
the inherent quality of the data itself.  For example, CVE
compatibility for tools will not formally require that each
check/signature itself should produce accurate results.  CVE
compatibility for databases will not formally require that affected
OS/fix information/etc. be correct.  The Good Faith statement will be
worded to help prevent this sort of abuse.  There needs to be a
separate mechanism for verifying the underlying quality of tools and
databases.

- Steve