[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CD PROPOSAL: DOT (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. 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 >...