CD PROPOSAL: HIGHCARD (Interim Decision 8/24)

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

Please vote on this pervasive content decision using the space
provided below.  This content decision is scheduled for Interim
Decision on August 24.

While High Cardinality has been the subject of some debate, I believe
that adding the concept of "innumerability" limits the scope of high
cardinality decisions to poorly understood or impossible-to-list
vulnerabilities; this decision also provides the Board with the option
to make exceptions.  The use of Dot Notation (DOT) further mitigates
the concern for using a higher level of abstraction based solely on
concerns with respect to high cardinality.

- Steve



Content Decision: HIGHCARD (High Cardinality, Innumerable Vulnerabilities)
--------------------------------------------------------------------------

VOTE:

(Member may vote ACCEPT, MODIFY, REJECT, or NOOP.)


Short Description
-----------------

In some cases, a particular "class" may have so many vulnerabilities
that it will cause a significant increase in the number of entries in
the CVE (High Cardinality).  If those vulnerabilities cannot be
enumerated (Innumerable), then they are combined into a single
higher-level vulnerability.


Definitions
-----------

For general guidance, any "class" of more than 100 vulnerabilities may
be considered High Cardinality, unless that class is well-understood
and accepted by the community (e.g. "buffer overflow.")  The
vulnerabilities in a "class" may be considered Innumerable if there
are no well-defined ways to distinguish between the vulnerabilities,
or if they are of a theoretically infinite cardinality.


Rationale
---------

High cardinality vulnerabilities can dominate the CVE, reducing the
usefulness to the sysadmin.  They can skew quantitative comparisons
between databases and inherently bias the comparisons towards
vulnerability databases that use high cardinality vulnerabilities
extensively.  In addition, they can increase the overhead for the
maintenance of the CVE, as well as maintenance of mappings from
databases to the CVE.

High cardinality vulnerabilities are especially risky for
vulnerabilities that do not have a well-understood language for
describing them, e.g. configuration problems.  Often, these types of
vulnerabilities are also Innumerable.

In some cases, the Editorial Board may agree that it makes conceptual
sense to specify individual vulnerabilities, even if they are high
cardinality.  The Board should make these considerations on an ad hoc
basis.


Examples
--------

The set of all "system-critical" files in Unix is Innumerable.
Certain files can be identified, e.g. password files, login scripts,
or batch files, but often the specific configuration of a machine
includes a large number of files that are unique to that machine.

The set of all default passwords may be High Cardinality, but it is
Enumerable, as the password itself (a) is known, and (b) can serve as
the discriminator from other passwords.  Thus it will be up to the
Board to determine whether it makes conceptual sense to have a single,
high-level vulnerability, or divide them into specific entries.