CD PROPOSAL: DOT (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.

Dot Notation effectively allows us to have two separate levels of
abstraction in the CVE, at least in cases where the two LOA's serve
different audiences.  The only catch is that it adds a (small)
requirement for a CVE search utility should understand dot notation
and handle it properly.

- Steve



Content Decision: DOT (Use of Dot Notation)
-------------------------------------------

VOTE:

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



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

In some cases where a CVE vulnerability may occur at a higher level of
abstraction than might be expected, the Editorial Board may decide to
specify the "instances" of that vulnerability using Dot Notation.  Any
database which links to the CVE name must be able to handle searches
that are specified using Dot Notation; but that database is not
required to use Dot Notation itself.  Each "instance" is recorded
within the vulnerability's description and annotated with a number.


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

Dot Notation is an enhancement to the CVE name whose presence
explicitly indicates that a lower level of abstraction is being used.
A number is appended to the CVE name and separated by a dot, e.g.:

   CVE-1999-NNNN.1
   CVE-1999-NNNN.2
   CVE-1999-NNNN.3

When a CVE vulnerability has Dot Notation associated with it, the
notation is recorded in the description, e.g.:

>    Buffer overflow in the strcpy() call in function(), as used by the
>    following applications:
>
>    1. VendorA ProductA
>
>    2. VendorB ProductB
>
>    3. VendorC ProductC



Rationale
---------

In some cases, vulnerabilities may be recorded in the CVE at a higher
level than expected, e.g. due to the HIGHCARD content decision.  In
other cases, a content decision may be adopted which is theoretically
consistent but difficult to accurately determine in practice,
e.g. SF-CODEBASE.

However, for Enumerable vulnerabilities, it may benefit a significant
portion of the users of the CVE to have "access" to a naming
convention at the lower level of abstraction.  Dot Notation could be
useful in this fashion, and the Editorial Board may elect to use Dot
Notation to identify specific "instances" of such a vulnerability.

As a general rule, if a vulnerability can be sub-divided into
approximately 20 "instances" or less, then Dot Notation could be used.



Examples
--------

The Same Codebase (SF-CODEBASE) content decision recommends that two
vulnerabilities that are subject to the same attack (e.g. a buffer
overflow using a particular protocol command) should be distinguished
if they come from different codebases, i.e. different authors.
However, in many cases, it is is difficult or impossible to determine
whether two programs have the same codebase.  This is especially
problematic with Unix, since there are different "families" and
origins, with numerous modifications.  Such vulnerabilities are prime
beneficiaries of dot notation, since the higher level vulnerability
preserves the accuracy of the CVE, while the dot notation facilitates
an attempt to provide more precision.

A well-defined list of privileges, access rights, or operations that
all appear on the same dialog box could also benefit from a dot
notation, e.g.:

>Inappropriate use of a Windows NT user privilege:
>
>1. Act as System
>2. Add Workstation
>3. Backup
>4. Change System Time
>...