Re: CD PROPOSAL: DEFINITION - Interim Decision 8/23

[Bill Hill <bill@mitre.org>]

ACCEPT

"Steven M. Christey" wrote:

> 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)
begin:vcard 
n:Hill;William
tel;work:703-883-6416
x-mozilla-html:TRUE
org:The MITRE Corporation
adr:;;1820 Dolley Madison Blvd;McLean;VA;22102;
version:2.1
email;internet:bill@mitre.org
title:INFOSEC Engineer
fn:Bill Hill
end:vcard

S/MIME Cryptographic Signature