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.