Re: CD PROPOSAL: DOT (Interim Decision 8/24)

[Pascal Meunier <pmeunier@purdue.edu>]

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

ACCEPT

>
>(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
>>...