Re: CD PROPOSAL: DOT (Interim Decision 8/24)
"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)
> (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.
> 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.:
> 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
> 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.
> 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
(707) 822-4588 (707) 826-7571 (FAX)