CD PROPOSAL: DEFINITION - Interim Decision 8/23

["Steven M. Christey" <coley@linus.mitre.org>]

Board members who advocate a universal vulnerability definition may be
surprised at this proposal, since most of the discussion on the
mailing list was in support of the universal definition.  However, it
was clear from the CVE Review meeting (and by voting patterns on
specific candidates by less vocal participants) that a number of Board
members advocate using an "inclusive" vulnerability definition
(a.k.a. "risk," or "environmental vulnerability," etc.)  It is this
discovery that provides one of the strongest arguments AGAINST using
"Silence Implies Assent."

Please register your vote to the list or just to me.

- Steve



Content Decision: DEFINITION (Use "Inclusive" Vunerability Definition)
----------------------------------------------------------------------

VOTE:

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


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

The CVE uses an Inclusive vulnerability definition, but CMEX indicates
whether each entry is also a Universal vulnerability.  Editorial Board
members must therefore vote on candidates in accordance with the
Inclusive vulnerability definition.


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

A "universal" vulnerability is one that is considered a vulnerability
under any commonly used security policy which includes at least some
requirements for minimizing the threat from an attacker.  (This
excludes entirely "open" security policies in which all users are
trusted, or where there is no consideration of risk to the system.)

The following guidelines, while imprecise, provide the basis of a
"Universal vulnerability definition."  A Universal vulnerability is a
state in a computing system (or set of systems) which either:
  - allows an attacker to execute commands as another user
  - allows an attacker to access data that is contrary to the
    specified access restrictions for that data
  - allows an attacker to pose as another entity
  - allows an attacker to conduct a denial of service

An "inclusive" vulnerability is not a universal vulnerability, but it
may be considered a vulnerability under at least some commonly used
security policies.


Rationale
---------

Discussions on the Editorial Board mailing list, and during the CVE
Review meetings indicate that there is no definition for a
"vulnerability" that is acceptable to the entire community.  However,
there appears to be a "minimal" definition of vulnerability which is
common to all definitions.  In general, the "minimal definition" is
strongly advocated by those with an academic perspective, while many
of those who represent operational constituencies (e.g. tool vendors
or response teams) advocate an approach that has a less stringent
definition, since the term is broadly used by the constituencies that
they serve.

In accordance with the original stated requirements for the CVE, the
CVE should remain independent of multiple perspectives.  Since the
definition of "vulnerability" varies so widely depending on context
and policy, the CVE should avoid imposing an overly restrictive
perspective on the vulnerability definition itself.  Therefore, the
CVE should not use a "universal" vulnerability definition that is
acceptable to all, but instead use an inclusive definition.

There is a good use for both definitions, however.  But maintaining
completely separated enumerations is not feasible.

In recognition of the utility of a "universal" vulnerability
definition, CMEX should contain an attribute which indicates whether a
vulnerability is "universal" or not.  Voters for individual candidates
may identify whether they believe a candidate is a "universal"
vulnerability; acceptance of a candidate by all voters implies
universality.

Advocates of a "universal" vulnerability definition can easily extract
the appropriate portion from the CVE, while allowing the CVE to be
used by those who need a more inclusive definition.  Thus the CVE can
adequately serve both "universal" and "inclusive" advocates.  To take
the opposite approach, i.e. to only include universal vulnerabilities,
would only adequately serve "universal" advocates.


Examples
--------

Examples of universal vulnerabilities include:
  - phf (remote command execution as user "nobody")
  - rpc.ttdbserverd (remote command execution as root)
  - world-writeable password file (modification of system-critical
    data)
  - default password (remote command execution or other access)
  - denial of service problems that allow an attacker to cause a Blue
    Screen of Death
  - smurf (denial of service by flooding a network)

Examples of inclusive vulnerabilities include:
  - running services such as finger (useful for information gathering,
    though it works as advertised)
  - inappropriate settings for Windows NT auditing policies (where
    "inappropriate" is enterprise-specific)
  - running services that are common attack points (e.g. HTTP, FTP, or
    SMTP)
  - use of applications or services that can be successfully attacked
    by brute force methods (e.g. use of trivially broken encryption,
    or a small key space)