[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CD MODIFICATION: DEFINITION version 2 - Interim Decision 8/30

>Please vote on the following modification to the DEFINITION content
>decision, which uses the new "exposure" terminology.
>Our proposal for the use of the "exposure" term has received very
>little commentary, but since it (a) requires a change to the CVE name
>itself, and (b) attempts to resolve some of the most significant
>debates that have occurred on the Editorial Board list so far, it is
>critical that adoption of this terminology be decided ASAP.


>(Member may vote ACCEPT, MODIFY, REJECT, or NOOP.)
>Short Description
>In an attempt to remain independent of the multiple perspectives of
>what a "vulnerability" is, the CVE identifies both "universal
>vulnerabilities" (i.e. those problems that are normally regarded as
>vulnerabilities within the contect of all reasonable security
>policies) and "exposures" (i.e. problems that are only violations of
>some reasonable security policies).
>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
>The following guidelines provide the basis for a definition of an
>"exposure."  An exposure is a state in a computing system (or set of
>systems) which is not a universal vulnerability, but either:
>  - allows an attacker to conduct information gathering activities
>  - allows an attacker to hide activities
>  - includes a capability that behaves as expected, but can be easily
>    compromised
>  - is a primary point of entry that an attacker may attempt to use
>    to gain access to the system or data
>  - is considered a problem according to some reasonable security
>    policy
>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.  At least
>two different definitions of vulnerability have arisen and been
>discussed.  There appears to be a universally accepted, historically
>grounded, "core" definition which deals primarily with specific flaws
>that directly allow some compromise of the system (a "universal"
>definition).  A broader definition includes problems that don't
>directly allow compromise, but could be an important component of a
>successful attack, and are a violation of some security policies (a
>"contingent" definition).
>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
>term "universal vulnerability" is to be applied to those CVE entries
>which are considered vulnerabilities under any security policy (and
>thus by any perspective), and "exposure" is to be applied to the
>remaining CVE entries which include violations of *some* reasonable
>security policy.
>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 exposures 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)

Page Last Updated or Reviewed: May 22, 2007