[TECH] Backmaps and other products of candidate creation

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

All,

Since not all Board members were sources for the legacy candidates, I
thought I'd describe the information that MITRE provides to the data
sources once the candidates have been created.  The same type of
information is provided to the sources of new information.  (For more
details on data sources, see http://cve.mitre.org/cve/datasources.html)

NOTE: Any organization that has products or services that are
CVE-compatible will also effectively become a source, as they will
need to provide their database to MITRE so that MITRE can verify that
the database uses CVE names accurately and ensure that names will be
provided for all items in the CVE-compatible product.  We expect that
the CVE compatibility evaluation process will produce some of the same
data that is identified here.

Each source receives three separate "reports" - a backmap, a
reject-map, and a gapmap.  They are described below.  I'll use real
examples from ISS' X-Force database tags and SecurityFocus Bugtraq
ID's.  I chose them because they are identifiers for publicly
available databases, and they are used as references in CVE candidates
and entries.  As such, the data I'm presenting could have been
inferred easily from the candidate information itself.

1) BACKMAP.  For each submission (i.e. "database record") from the
   source that has been consulted for the creation of a candidate,
   that candidate is listed along with the source's own ID for the
   submission.

   Example (from ISS):

     CAN-2000-1192 3987
     CAN-2000-1200 4015
     CAN-1999-1014 3297
     CAN-1999-1015 898
     CAN-1999-1020 1364

   Separate sections are created when there is a difference in the
   level of abstraction between the candidate and the source's
   submissions.  For example, one CAN might map to multiple
   submissions.  Conversely, one submission might identify multiple
   CAN's.

   For example (from X-Force database ID's):

     The following candidates were mapped to multiple internal IDs.

     CAN-1999-1257 1826, 1825
     CAN-1999-1278 1550, 1549

     The following IDs were mapped to multiple candidates.

     1401 CAN-1999-1464, CAN-1999-1465

   These discrepancies often occur because of differences between
   CVE's content decisions and the source's own editing choices.  The
   examples above are affected by the dreaded CD:SF-LOC and CD:SF-EXEC
   content decisions.  In some cases, the discrepancy allows the
   source to identify duplicates in its own database.

2) REJECT-MAP.  This historically-and-inaccurately-named map presents
   two separate pieces of information:

   a) It links submissions to CVE/CAN items that *already existed*
      when the submission was processed (i.e. refined).

   b) It identifies submissions that should not be assigned a
      candidate number, for some reason.

   If (a) applies, this can prompt us to add more references to
   existing CVE items.

   Examples (from SecurityFocus Bugtraq ID's):

     196 dupe CAN-1999-0354
     197 dupe CAN-1999-0347
     397 subsumes CVE-1999-0373
     650 subsumed-by CAN-2000-0574

   The last two indicate differences in abstraction that were
   explicitly noted by the content team member who processed the
   submission.

   If (b) applies, then the content team member provides a specific
   reason for why the submission will not have a candidate created for
   it.

   Examples (USING FICTIONAL DATA):

   7219 not-a-cve not exploitable; quality-of-service issue
    476 not-a-cve does not satisfy CVE definition
    256 info-missing record was deleted from public site

3) GAPMAP.  This "map," inaccurately named for consistency with the
   other terms (and because it rhymes and sounds kind of catchy), is a
   list of newly-created candidates in which the source did not have
   submissions that were associated with those candidates.  That is,
   this provides the source with a list of candidates that may not be
   in their database.


In some cases, a submission can not be processed immediately.  This
may happen due to one or more of the following reasons:

- The submission does not have enough information to understand which
  vulnerability it is identifying (in which case, the source will be
  asked to provide more information).  Example: some submissions may
  not have any references, or may have extremely vague descriptions
  that could identify more than one different vulnerability.

- The submission is part of a complex group of related vulnerability
  reports that required deeper analysis, or it was outside the
  expertise of the content team member who processed it.  Examples: in
  summer 1999, a large number of problems were discovered in wu-ftp
  and other servers derived from wu-ftp code, and many vendor
  advisories were posted which may have addressed only some of the
  problems.  Or, a content team member who is strong in Windows NT but
  weak in UNIX might not have the expertise to describe UNIX kernel
  bugs (or vice versa).  (As editor of the entire CVE list, I feel
  stupid in some area at least once a day - I imagine that some Board
  members may know this feeling as well ;-)

- The submission was part of a broad, "high-cardinality" class of
  problems that is not well understood, or it is "controversial" in
  that many people might not want it in CVE.  This submission and all
  related submissions are grouped and analyzed by the content team,
  who will create the initial "rules" (which may be embodied in
  content decisions) that will guide how to assign candidates.
  Example: the multitudes of configuration errors that can be
  introduced by a system administrator at the OS or application level
  can't be individually identified with separate CVE names, so we are
  working on creating higher-level candidates that make sense.


These submissions are processed and converted into candidates at later
dates, when the surrounding issues have been addressed by the source
and/or the CVE content team.