CVE Content Decisions Overview
CVE content decisions (CDs) are the guidelines used to ensure that
CVE names
are created in a consistent fashion,
independent of who is doing the creation. There are two major types
of CDs: Inclusion and Abstraction.
-
Inclusion Content Decisions
- specify whether a vulnerability
or exposure should go into CVE.
-
Abstraction Content Decisions
- specify what level of
abstraction (level of detail) a vulnerability should be described
at, e.g., whether a particular security issue should be given
one candidate or five candidates. (See
CVE
Abstraction Content Decisions: Rationale and Application
for
detailed information.)
There are differences between many vulnerability databases or products
in the type of content they include, as well as the level of abstraction.
These differences occur within the same database or product. Because
of this variety and the flat structure of the CVE name, CVE cannot
be flexible enough to account for these differences. It is important
for vulnerability analysts to be aware of these differences. As
such, CVE CDs not only document the guidelines for creating content,
they often indicate areas in which there is inconsistency across
vulnerability information sources. Quantitative analyses of vulnerabilities
that use CVE-normalized data can be more easily replicated, and
the CVE CDs help to ensure that the data is normalized in a predictable
fashion.
Back to top
The Two Most Commonly Used Content Decisions
Two of the most commonly used abstraction facets of CVE CDs are
shown in the example below. They also highlight some of the most
common discrepancies across vulnerability information sources. These
CDs were revised many times over a period of a year and a half,
but they were stabilized in early 2001 when they were modified to
make them less sensitive to the amount of information that is available
for a vulnerability. From an academic perspective this approach
is not optimal, but it is proving to be repeatable and less likely
to cause candidates to become split or merged when new information
becomes available after the initial analysis has been performed.
Back to top
Example - SF-LOC and SF-EXEC Abstraction Facets of CVE Content
Decisions
|
CD:SF-LOC: multiple security flaws in the same executable,
but possibly in different lines of code
|
CD:SF-EXEC: multiple executables exhibiting the same problem
|
-
CD:SF-LOC only applies when there may be multiple bugs
that appear in the same executable (modulo the codebase,
i.e., all "ps" executables in UNIX are treated
as the same).
-
SPLIT (create separate CANs) between problems of different
types (e.g., buffer overflow versus symlink problem).
-
SPLIT between problems of the same type if problem X
appears in some version that problem Y does not.
-
MERGE problems of the same type within the same version.
Explicitly list the different problems in the description.
|
-
CD:SF-EXEC only applies when there are multiple executables
in the same package that demonstrate the same problem.
-
"The same package" basically means "bundled
executables that perform related functions that are not
distributed separately." Microsoft Word and PowerPoint
are not the same package (they can be installed separately).
The set of executable programs that support the lpd capability
in UNIX are the same package.
-
SPLIT when the problems are of different types.
-
SPLIT when the problems are in different versions (for
some definition of "version" that effectively
describes the package).
-
MERGE when the problems are of the same type. Explicitly
identify the separate affected "components" or
executables in the package.
|
Back to top
CD:SF-LOC
is less sensitive to the lack of detailed information
such as source code, exploits, or attack traces. However, it is
still sensitive to changes in version information. Problems that
occur in libraries pose special challenges for this CD, because
they could be exhibited at several points within the same executable,
or in many different executables. Ultimately, while this CD is intended
to minimize the amount of information that is required to produce
results, it is still dependent on critical information sources such
as the vendor of the vulnerable product.
CD:SF-EXEC
is also susceptible to error if the problem occurs
in a library or other common codebase.
Back to top
|
