RE: CD PROPOSAL: HIGHCARD (Interim Decision 8/24)

[Craig Ozancin <cozancin@axent.com>]

ACCEPT

> -----Original Message-----
> From: Steven M. Christey [mailto:coley@LINUS.MITRE.ORG]
> Sent: Tuesday, August 17, 1999 4:52 PM
> To: cve-editorial-board-list@lists.mitre.org
> Subject: CD PROPOSAL: HIGHCARD (Interim Decision 8/24)
>
>
> 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.
>