Appendix A VULNERABILITIES

INTRODUCTION

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 library¹ 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.

THE PROBLEM: VULNERABILITY MEANS DIFFERENT THINGS

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.

THE APPROACH: INTRODUCING A NEW TERM—EXPOSURE

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.

DISTINGUISHING BETWEEN VULNERABILITIES AND EXPOSURES

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.

DEFINITION

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.

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 context 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 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:

• 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) that 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 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

Examples of universal vulnerabilities include:

• A phf (remote command execution as user “nobody”)
• An 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 the Blue Screen of Death
• A 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)

WHAT IS A CVE CANDIDATE?

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:

1. Number (also referred to as a name)
2. Description
3. References

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.

THE TWO WAYS NEW SECURITY ISSUES BECOME CANDIDATES

Candidate numbers get assigned to specific issues in two different ways—as data sources or candidate numbering authorities (CNAs).

Data Sources

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.)

Candidate Numbering Authorities

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.

HOW LONG IT TAKES FOR CANDIDATES TO BECOME OFFICIAL CVE ENTRIES

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.”

HOW CANDIDATES ARE AFFECTED BY CVE CDS

CVE CDs are the criteria and consistency rules that determine:

• What security issues become CVE candidates for eventual inclusion in the CVE list
• How we distinguish between similar or related security issues

Approximately 15 percent of all candidates are affected by one or more CDs. Generally, the CVE approach is to create separate candidates for:

• Vulnerabilities of different types
• Vulnerabilities of the same type that appear in different versions
• Vulnerabilities that appear in different code bases (i.e., by vendor; however, this also includes vendors who share the same code such as Linux/UNIX® vendors)

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.

THE CANDIDATE NUMBERING PROCESS

CVE Candidates

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:

1. Number (also referred to as a name)
2. Description
3. References

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.

Candidate Numbering Authority

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.

CVE Editor

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.

Phases of a CVE Candidate

An overview of the phases of a candidate as it moves toward being accepted or rejected as a CVE entry is included below:

• Discovery—a potential vulnerability or exposure is discovered. Or an analysis of legacy vulnerabilities across various public sources is performed.
• Public announcement—a public announcement is made about the potential vulnerability or exposure through postings to mailing lists, newsgroups, security advisories, etc. After the announcement, the information is submitted to the CVE CNA by an Editorial Board member or by the CNA itself.
• Assignment—the CNA first verifies that the vulnerability or exposure is not already an entry or candidate and if it is not, assigns a candidate number. Only the CNA can assign candidate numbers. Occasionally, the CNA may provide a candidate number to an organization prior to a public announcement so that the candidate number may be included in the announcement. Currently, The MITRE Corporation functions as both CNA and Editor for CVE.
• Proposal—the Editor proposes the potential vulnerability or exposure to the Editorial Board, using the candidate number obtained during Assignment. It then becomes a candidate for CVE acceptance. Members discuss the candidate and vote on it. They may Accept, Reject, Recast (signifying the need for a major change), Modify (signifying the need for a minor change), Have No Opinion, or say that they are actively Reviewing the candidate. Note: Editorial Board members’ votes and comments are recorded on the CVE Web site.
• Modification—when a candidate receives a vote to Modify or Recast, it means that it may need to be altered in order to be accepted. The Editor decides on what alterations need to be made (if any), then resubmits the altered candidate to the Board for additional voting. When only minor changes are necessary, additional voting will not be required and the Editor will simply move the candidate to the Interim Decision phase after making the change. Note: Modification history is recorded on the CVE Web site.
• Interim Decision—the Editor decides when it is appropriate to determine whether debate about the candidate is complete or has come to a standstill. The Editor casts a single Accept or Reject vote, then gives the Board the opportunity to post any final comments or objections. Votes with extensive comments or objections may result in a requirement for additional voting, which may return the candidate to the Modification phase. If no change is needed, the candidate may advance to the Final Decision phase.
• Final Decision—if the Editor determines that no sufficient grounds exist for changing the vote made in the Interim Decision, the decision becomes final. If the candidate is Accepted, the Editor announces to all Board members that the candidate will be placed into CVE and identifies the CVE name (or names) that will be assigned to the new entry. If the candidate is Rejected, the Editor notes the reason for rejection.
• Publication—once a candidate is Accepted, the CVE name (or names) is assigned and the candidate is added to CVE. It then becomes a CVE entry and a new version of CVE is published via the CVE Web site.
• Reassessment—occasionally, a CVE entry may need to be reassessed and possibly modified (for example, when there is increased understanding of the vulnerability or exposure). Reassessment of a CVE entry involves the same phases as a new candidate, from modification through voting to final decision.
• Deprecation—in some rare cases, the Editorial Board may decide that a CVE entry should no longer remain active in CVE. For example, the Board may decide to modify the level of abstraction by splitting the entry into lower-level entries or merging it with others. In such cases, the vulnerability will be annotated with a status of Deprecated.

FROM CANDIDATE TO CVE ENTRY

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.

TO LEARN MORE

CVE is freely available for review or download from the Internet at http://www.cve.mitre.org/.

MITRE

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.

REFERENCE

1. Mitre Corporation, Common Vulnerabilities and Exposures, http://www.cve.mitre.org./ [accessed October 2003].