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

[Stuart Staniford-Chen <stuart@silicondefense.com>]

ACCEPT

"Steven M. Christey" wrote:
> 
> 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
> >...

-- 
Stuart Staniford-Chen --- President --- Silicon Defense
                   stuart@silicondefense.com
(707) 822-4588                     (707) 826-7571 (FAX)