|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [TECH] Backmaps and other products of candidate creation
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.
|
||||
