|
[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. > > > >VOTE: ACCEPT > >(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). > > >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 > >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 > > >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. 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 >-------- > >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)
|
||||