Vulnerabilities and security exposures are at the heart of the science of information security. They are not employed directly in the McCumber Cube methodology, because they are technology-based artifacts that are ultimately juxtaposed against various safeguards to ensure appropriate risk mitigation in the risk assessment process. However, the definitions and complete library of vulnerabilities have been admirably defined and addressed in the CVE library such that any detailed analysis outside this effort would be futile at best and conflicting at worst. With this in mind, I have included here several sections of the CVE library1 that define the issue of vulnerabilities and exposures.
These sections have been inserted directly from the CVE Web site that is available at http://www.cve.mitre.org/. I felt it important to include this information in this section to show how it can be employed in conjunction with the McCumber Cube methodology to build, tailor, and maintain a comprehensive and cost-effective information systems security program.
CVE aspires to describe and name all publicly known facts about computer systems that could allow somebody to violate a reasonable security policy for that system. Often, these things are referred to as vulnerabilities. However, Editorial Board discussions have revealed that there are at least two common uses of the term vulnerability.
The broad use of vulnerability refers to any fact about a computer system that is a legitimate security concern, but only within some contexts. For example, because the finger service reveals user information, there are reasonable security policies that disallow finger from being run on some systems. Thus, finger may be regarded as a vulnerability according to this usage of the word.
A narrower view holds that some security-related facts fall short of being true vulnerabilities. With respect to the presence of the finger service, it may be argued that because finger behaves as it was designed to behave, it should not be considered to be a vulnerability in this narrower view.
Because the term vulnerability has several different uses, there needs to be a way of making the distinction when it is appropriate. For this reason, we have introduced the term exposure to allow us to refer to security-related facts that may not be considered to be vulnerabilities by everyone. Relative to this narrower view of vulnerability, we would say that finger is an exposure.
At present, CVE provides no mechanism to distinguish between vulnerabilities and exposures, although the Editorial Board accepted a content decision that may provide a basis for later discussion. The primary focus of the Editorial Board is to add new entries to CVE. Users of CVE are encouraged to distinguish between CVE entries in any manner that best supports their own particular objectives.
Until the security community develops a better language to describe such things, you are encouraged to infer from the context whether vulnerability is being used in the broad sense, the narrow sense, or even in some other manner. For example, we might see this broad usage of the word when we see references to vulnerability databases and vulnerability assessment tools. A reference to a vulnerability database should not automatically imply that all entries in that database will meet the standard of the narrow use of vulnerability.
In August 1999, the Editorial Board voted to accept the following content decision (CD), which describes terminology to be used in CVE. Note that these definitions are imprecise. It is expected that the language will evolve with usage.
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 context 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 that 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, although imprecise, provide the basis of a universal vulnerability definition. A universal vulnerability is a state in a computing system (or set of systems) that either:
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) that is not a universal vulnerability, but either:
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 that deals primarily with specific flaws that directly allow some compromise of the system (a universal definition). A broader definition includes problems that do not 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 CVE, the CVE list should remain independent of multiple perspectives. Because the definition of vulnerability varies so widely depending on context and policy, 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 that are considered vulnerabilities under any security policy (and thus by any perspective), and exposure is to be applied to the remaining CVE entries that include violations of some reasonable security policy.
Examples of universal vulnerabilities include:
Examples of exposures include:
CVE candidates are those vulnerabilities or exposures under consideration for acceptance into CVE. Candidates are assigned special numbers to distinguish them from CVE entries. Each candidate has three primary items associated with it:
The number (or name) is an encoding of the year that the candidate number was assigned and a unique number N for the Nth candidate assigned that year, e.g., CAN-1999–0067.
If the Editorial Board accepts the candidate, an official CVE entry is created that includes the description and reference and the candidate number is converted into a CVE name by replacing the “CAN“ with ”CVE.” For example, when the Editorial Board accepted the candidate CAN-1999–0067, the candidate number was converted to CVE- 1999–0067 and the resulting new entry was added to CVE. Note that the assignment of a candidate number is not a guarantee that it will become an official CVE entry.
Candidate numbers get assigned to specific issues in two different ways—as data sources or candidate numbering authorities (CNAs).
In most cases, we on the Editorial Board assign candidate numbers to issues that have already been publicized (e.g., on Bugtraq or in a security advisory). We rely on other data sources to feed us with vulnerability information that they regularly collect and summarize.
We collect and integrate the information from these multiple sources and create candidates from them. As a result of this process, it takes a minimum of two weeks after the initial public announcement of the problem before the candidates become available to the public. (Our data sources publish their summaries once a week, then it takes us at least a week to process their summaries.)
Organizations or individuals reserve candidate numbers from MITRE for issues that have not yet been publicized. These entities, called CNAs, then include the candidate number in their initial public announcement. As such, the candidate number is immediately available. The CVE Initiative is working to do this more regularly across the industry. One effort involves providing blocks of candidates to key parties (like CERT/CC or major operating system vendors like Microsoft). These CNAs can then assign the candidates to incoming issues, independently of MITRE. This addresses some other concerns besides timing, but it requires that the CNAs know how to assign the proper number of candidates and it also requires close coordination across all parties.
Once a candidate has been created and assigned to a specific issue, it is proposed to the CVE Editorial Board. Board members review and vote on the candidates. In general, at least three Board members must accept the candidate before it can be promoted to an official CVE entry.
In general it takes one day to one month to assign a candidate number and one to six months for the typical candidate to become an official CVE entry. The review process by the Editorial Board allows a minimum of two weeks from proposal to final acceptance and conversion to an official CVE entry. However, this only happens in certain relatively rare circumstances when the candidate identifies a well-known issue that has been publicly acknowledged by the vendor.
If the candidate is for an obscure issue, or Board members do not have a minimum level of confidence that the reported issue is real, then it can take months or even years before enough Board members cast the required number of Accept votes. Some candidates may never obtain enough Accept votes, but they may not be inaccurate either; these situations are currently handled by the CVE Editor.
During the review process for candidates, an Editorial Board member may find a possible inconsistency or ask a question that requires more detailed research. This can delay a candidate further while the questions are dealt with because some questions are, technically speaking, difficult to answer. Some candidates may also be further delayed by certain CVE CDs.
We currently release new CVE versions about once per quarter. This simplifies maintenance for people who maintain CVE-compatible databases, products, and services.
These new versions are announced on the News and Events page and in our free enewsletters, “CVE-Announce” and “CVE-Data-Update.”
CVE CDs are the criteria and consistency rules that determine:
Approximately 15 percent of all candidates are affected by one or more CDs. Generally, the CVE approach is to create separate candidates for:
CDs are difficult to document and formalize, partly because of the variety and complexity of vulnerabilities, and partly because of the variety and quality of available information. In effect, CDs also represent areas in which security experts may differ on the proper way of distinguishing between security issues. As a result of these factors, CDs also can change over time. Because CDs directly affect which issues go into CVE and how they are counted, it is important that CDs be stable before an issue can be promoted to an official CVE entry. As such, if a candidate is affected by an incomplete or unverified CD, it will not be accepted as an official entry until the CD is stable—even if it has enough Accept votes.
Although we have stabilized some CDs, others have not received sufficient discussion and verification. This is especially the case with respect to configuration problems, which are not well-studied in the community in general, and are often areas of sharp disagreement between CVE Editorial Board members (for example, some reported configuration errors fall in the area of best practices, which some members do not think belong in CVE; also, there is wide variety in how people count configuration errors). The instability of content decisions is one of the biggest factors in the delays of certain candidates. But as we further stabilize CDs, that will allow a number of candidates to be promoted to official entries.
CVE candidates are those vulnerabilities or exposures under consideration for acceptance into CVE. Candidates are assigned special numbers to distinguish them from CVE entries. Each candidate has three primary items associated with it:
The number, also referred to as a name, is an encoding of the year that the candidate number was assigned and a unique number N for the Nth candidate assigned that year, e.g., CAN-1999–0067.
Established practices are followed when a candidate is created. If the Editorial Board accepts the candidate, an official CVE entry is created that includes the description and references. The candidate number is converted into a CVE name by replacing the “CAN” with “CVE.” For example, when the Editorial Board accepted the candidate CAN-1999– 0067, the candidate number was converted to CVE-1999–0067 and the resulting new entry was added to CVE.
The assignment of a candidate number is not a guarantee that it will become an official CVE entry.
Once a potential security vulnerability or exposure is discovered, it is assigned a CVE candidate number by the CVE CNA. Only the CNA can assign candidate numbers. As part of its role of managing CVE, MITRE functions as the CNA.
After the candidate number is assigned, the CVE Editor proposes the candidate to the Editorial Board. Members discuss the candidate, modify it, and vote on whether to accept or reject the candidate for inclusion in CVE. If accepted, the candidate becomes an official CVE entry and is added to the CVE list on the Web site. In addition to its role as CNA, MITRE also functions as the CVE Editor.
An overview of the phases of a candidate as it moves toward being accepted or rejected as a CVE entry is included below:
Once the Editorial Board accepts a candidate, it is now part of CVE and is published on the CVE Web site. CVE entries include the name (also referred to as the CVE number), a brief description of the security vulnerability or exposure, and any pertinent references. The CVE name, for example CVE-1999–0067, is an encoding of the year that the candidate number was assigned and a unique number N for the Nth candidate assigned that year.
CVE names make it possible for your databases and tools to speak to each other and share data across separate databases and tools. For example, if a report from a security tool incorporates CVE names, you may then quickly and accurately access fix information in one or more separate CVE-compatible databases to remediate the problem. Also, you will know exactly what each tool covers because CVE provides you with a baseline for evaluating the coverage of your tools. This means you can determine which tools are most effective and appropriate for your organization’s needs. These benefits make CVE the key to information sharing.
CVE is freely available for review or download from the Internet at http://www.cve.mitre.org/.
The MITRE Corporation maintains CVE and provides neutral guidance to the Editorial Board on all matters related to the ongoing development of CVE. In partnership with government, MITRE is an independent, not-for-profit corporation working in the public interest. It addresses issues of critical national importance, combining systems engineering and IT to develop innovative solutions that make a difference.
1. Mitre Corporation, Common Vulnerabilities and Exposures, http://www.cve.mitre.org./ [accessed October 2003].
18.221.241.116