Vulnerabilities:CVE (Common Vulnerabilities and Exposures) Overview

The Identification of Vulnerabilities Using a Common Identifier Scheme

 >> JAPANESE

CVE (Common Vulnerabilities and Exposures)(*1), is a specification system in which a unique, common identification number, called a “CVE identifier (CVE-ID)”, is allotted to a vulnerability existent within the program itself. Many vulnerability assessment tools and vulnerability information providers utilize CVE identifiers.  
By designating a unique, common identifier to each vulnerability, it is possible to discern whether the same vulnerability is concerned regarding a vulnerability information provided by organization A and that by organization X. It is also possible to develop an association and cross-reference between vulnerability countermeasure information using CVE identifiers.

Under the intention to share information concerning vulnerabilities, CVE was proposed by MITRE Corporation (MITRE)(*2), a non-profit organization supported by the United States government, at the 2nd Workshop on Research with Security Vulnerability Databases held at Purdue University from January 20th through the 22nd in the year 1999.

Currently, CVE is one of the elements that constitute SCAP (Security Content Automation Protocol)(*3), which is involved in the automation and standardization of technical approaches in the field of information security and promoted by the United States government.

The designation and management of CVE identifiers is conducted by MITRE, and in order to improve the collaboration between vulnerability countermeasure information, a list of CVE identifiers is provided from the CVE website after the unification of new vulnerability information obtained on a daily basis.

Over 80 organizations, including CERT/CC, HP, IBM, OSVDB, Red HAT, and Symantec, are registered as CVE data sources for this list and collaborate together on dissemination of vulnerability information.

JVN(*4) and JVN iPedia(*5) also began cooperation in October of 2008, and has become officially registered as a CVE data source. For more detailed information, refer to following “CVE Reference Key/Maps”, offered by MITRE.

• http://cve.mitre.org/data/refs/index.html#sources

This reference material has been constructed based on publications from MITRE: “Requirements and Recommendations for CVE Compatibility” version 1.1, published on December 6th, 2007, and “CVE Compatibility Process”, published on May 21st, 2007. For more detailed information, refer to material offered by MITRE.

1. CVE Identifiers (CVE-ID)

CVE identifiers are used to uniformly identify vulnerabilities by assigning a common, unique identifier for each vulnerability.

The CVE identifier is formulated in the form [CVE-Year-Consecutive Number], and is designated by CVE Editorial Board, which consists of researchers specializing in security as their field of expertise and members of security and product vendors, after the report concerning a vulnerability has been evaluated.

Many vulnerability countermeasure information made public in JVN and JVN iPedia also have CVE identifiers. For example, vulnerabilities reported through the Information Security Early Warning Partnership are allotted CVE identifier numbers as in Table 1 below:

Table 1: CVE Identifier and JVN, JVN iPedia equivalent ID

• CVE
• JVN
• JVN iPedia

2. CVE Official Website

 The assignment of CVE identifiers began in 1999 and as of the end of December, 2008; over 34,000 vulnerability cases have been allotted CVE identifiers.  
MITRE provides a list of already designated CVE identifiers complemented with “Description”, “References” and “Status” at the CVE Official Website ( http://cve.mitre.org ) (Figure 1).

(1) Description

Description provides an overview of the vulnerability designated with a CVE identifier and describes what kind of security risk it presents.

(2) References

References are a list of vulnerability information related to the CVE identifier and consist of URLs for CVE data sources and relevant product vendors. In the case of Figure 1, JVN: JVN#30732239 is registered as a CVE data source under the “References” section.

(3) Status

Status shows the status of the allotted CVE identifier and can be either “Candidate” or “Entry”. The “Candidate” status indicates that whether the security problem allotted with a CVE identifier is indeed a vulnerability or not is still under review. The “Entry” status indicates that the CVE identifier has been approved, and that the reported security problem has been determined to be a vulnerability.

For reference, when the allotment of identifiers had first started, identifiers with the “Candidate” status were numbered [CAN-Year-Consecutive Number], while “Entry” status identifiers were given [CVE-Year-Consecutive Number]. However, as of October 19th, 2005, the usage of the prefix “CAN” has been discontinued, with all identifiers unified with the format [CVE-Year-Consecutive Number].

3. CVE Compatibility

In proceeding to counter vulnerabilities utilizing CVE, it is important that association and cross-reference between vulnerability countermeasure information is properly managed.

For this reason, an authorization system called CVE Compatibility exists in order to guarantee that intrusion detection tools, vulnerability assessment tools, and vulnerability countermeasure information services employing CVE are properly functioning.

In the approval of CVE compatibility, not only intrusion detection and vulnerability assessment tools, but also vulnerability countermeasure services such as intrusion detection management and remote scanning are subject for approval.

The following requirements must be met by tools and services in order for CVE compatibility to be authorized. Also, under agreement, one cannot declare CVE compatibility unless the requirements are fully met.

• CVE Searchability: The capability MUST allow users to locate security elements using CVE names.
• CVE Output: When the capability presents security elements to the user, it MUST allow the user to obtain the associated CVE names.
• Mapping Accuracy: For a capability with a Repository, the capability's mapping MUST accurately link security elements to the appropriate CVE names.
• CVE Documentation: The capability's documentation MUST adequately describe CVE, CVE compatibility, and how the CVE-related functionality in the capability is used.
• Date Usage: The capability MUST state the date of its currency with respect to CVE.

As of the end of December, 2008, a total of 137 organizations, 243 products/services have commenced the application process for CVE compatibility approval. Of the numbers above, 40 organizations and 75 products/services have received CVE compatibility approval.

3.1 CVE Compatibility Process

The CVE compatibility process consists of two phases: “Declaration” and “Evaluation”.

(1) Phase 1: Declaration

This phase addresses the declaration of intent of the organization requesting CVE compatibility approval, indicating that the necessary adjustments will be made to the tools and services to fulfill all of the requirements.

The process requires the following steps to be taken:

• The requirements and recommendations for the approval of CVE compatibility process must be researched by looking into tools and services that have already received the CVE compatible status.
• After obtaining the “CVE Compatibility Declaration Form” from MITRE, the required items must be filled out and sent back for submission.
• The “CVE Compatibility Declaration Form” and “Compatible Product Service Organization Welcome Kit” will be sent from MITRE.
• In the event that the responses to the declared fulfillment of three mandatory requirements – “CVE Searchability”, “CVE Output” and “CVE Documentation” – have been all acknowledged, the “CVE Compatibility Requirements Evaluation Form” may be obtained, and the organization can advance to phase 2, or “Evaluation” phase, of the CVE Compatibility process.

(2) Phase 2: Evaluation

This is the evaluation phase of the CVE Compatibility process. Review is conducted by MITRE based on the “CVE Compatibility Requirements Evaluation Form”, in which how the requirements are satisfied is explained in detail, submitted by organizations that wish to receive CVE compatibility approval.

• After the completion of phase 1, the required items in the “CVE Compatibility Requirements Evaluation Form” received from MITRE must be filled out.
• The documentation is then to be printed out, signed, and sent back to MITRE, as well as an electronic version attached and sent via e-mail. The evaluation will be based on the submitted documentation, and the information necessary for approval registration will be published on the CVE Official Website. Also, based on instructions from MITRE, revisions regarding the registration information will be conducted.
• Upon full completion of these processes, a publication will be made concerning the organization as a recipient of CVE Compatibility approval on the CVE Official Website. Also at this point, the tools and services will receive permission to employ a CVE-Compatible Product/Service logo to indicate compatibility.

3.2 Requirement Correspondence Status of JVN, JVN iPedia and MyJVN

JCPERT/CC and IPA are proceeding with improvement and development of the various functions and documentations necessary for CVE Compatibility intended for JVN, JVN iPedia and MyJVN(*6).  
The procedure for compatibility approval has been started by proceeding to phase 1, “Declaration”, in December 18th, 2008. For more detailed information, refer to following “Organizations Participating”, offered by MITRE.

• Japan Computer Emergency Response Team Coordination Center (JPCERT/CC) and Information-technology Promotion Agency, Japan (IPA)
• Information-technology Promotion Agency, Japan (IPA)

The three mandatory requirements – “CVE Searchability”, “CVE Output”, and “CVE Documentation” – for phase 1, and the association of vulnerability information with the proper CVE identifier, “Mapping Accuracy”, are fulfilled by the functions illustrated in Table 2.

Table 2. Requirement Correspondence Status of JVN, JVN iPedia and MyJVN

Henceforth, to make JVN, JVN iPedia and MyJVN a global service, as well as infrastructural and functional improvement, while cooperating to provide vulnerability countermeasure information as CVE data source.

Footnotes

1. (*1)
   CVE: Common Vulnerabilities and Exposures. A unique, common identifier used to distinguish vulnerabilities.

   • http://cve.mitre.org
2. (*2)
   MITRE Corporation: A not-for-profit organization that provides information technology support and research and development to the U.S. government.

   • http://www.mitre.org/
3. (*3)
   SCAP: Security Content Automation Protocol. A set of technical specifications supported by the U.S. government to promote standardization and automation of information security implementation.

   • http://nvd.nist.gov/scap.cfm
4. (*4)
   JVN: Japan Vulnerability Notes. A portal for vulnerability countermeasure information providing information on vendor response to the found vulnerabilities and security support.

   • http://jvn.jp/en/
5. (*5)
   JVN iPedia: Vulnerability countermeasure information database mainly for those concerning products popularly used in Japan.

   • http://jvndb.jvn.jp/en/
6. (*6)
   MyJVN: Vulnerability countermeasure information filtering tool that enables users to utilize the information in JVN iPedia more efficiently.

   • http://jvndb.jvn.jp/en/apis/myjvn/

Reference

• CPE (Common Platform Enumeration) Overview
• OVAL (Open Vulnerability and Assessment Language) Overview
• CWE (Common Weakness Enumeration) Overview