INTERNET-DRAFT K. Landfield Intended Status: Informational McAfee Expires: April 18, 2011 October 15, 2010 Naming Conventions for Vulnerabilities and Configurations Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Landfield Expires April 18, 2011 [Page 1] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 Abstract This document provides an overview of the naming conventions currently in use for vulnerabilities and configurations. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . 3 1.3 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4 Document Structure . . . . . . . . . . . . . . . . . . . . . 3 2 Overview of Vulnerability Naming Schemes . . . . . . . . . . . . 3 2.1 Common Vulnerabilities and Exposures (CVE) . . . . . . . . . 4 2.2 Common Configuration Enumeration (CCE) 5 . . . . . . . . . . 5 3 Identifier Syntax . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 CVE Identifier Syntax . . . . . . . . . . . . . . . . . . . 6 3.2 CCE Identifier Syntax . . . . . . . . . . . . . . . . . . . 6 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4.1 Security Considerations for End User Organizations . . . . . 6 4.1.1 Product and Service Selection and Design . . . . . . . 7 4.1.2 Vulnerability Communications and Reporting . . . . . . 7 4.2 Security Considerations for Software Developer and Service Providers . . . . . . . . . . . . . . . . . . . . . 8 4.2.1 Name Creation . . . . . . . . . . . . . . . . . . . . . 8 4.2.2 Name Use . . . . . . . . . . . . . . . . . . . . . . . 9 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1 Normative References . . . . . . . . . . . . . . . . . . 10 9.2 Informative References . . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Landfield Expires April 18, 2011 [Page 2] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 1 Introduction This document provides an overview of the naming conventions currently in use for vulnerabilities and security configuration information. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2 Purpose and Scope The purpose of this document is to provide recommendations for using vulnerability naming schemes. The document covers two schemes: CVE and CCE. The document gives an introduction to both schemes and makes recommendations for end-user organizations on using the names produced by these schemes. The document also presents recommendations for software and service vendors on how they should use vulnerability names and naming schemes in their product and service offerings. 1.3 Audience The intended audience for this document is individuals who have responsibilities related to vulnerability management. 1.4 Document Structure The remainder of this document is organized into the following major sections and appendices: * Section 2 provides an overview of CVE and CCE. * Section 3 describes the syntax of CVE and CCE identifiers. * Section 4 gives recommendations to end-user organizations on using CVE and CCE, and makes recommendations for how IT product and service vendors should adopt CVE and CCE within their product and service offerings. * Appendix A defines acronyms and abbreviations for the document. * Appendix B lists related resources. 2 Overview of Vulnerability Naming Schemes A vulnerability naming scheme is a systematic method for creating and maintaining a standardized dictionary of common names for a set of vulnerabilities in IT systems, such as software flaws in an operating system or security configuration issues in an application. The naming scheme ensures that each vulnerability entered into the dictionary Landfield Expires April 18, 2011 [Page 3] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 has a unique name. Using standardized vulnerability naming schemes supports interoperability. Organizations typically have many tools for system security management that reference vulnerabilities?for example, vulnerability and patch management software, vulnerability assessment tools, antivirus software, and intrusion detection systems. If these tools do not use standardized names for vulnerabilities, it may not be clear that multiple tools are referencing the same vulnerabilities in their reports, and it may take extra time and resources to resolve these discrepancies and correlate the information. This lack of interoperability can cause delays and inconsistencies in security assessment, reporting, decision-making, and vulnerability remediation, as well as hampering communications both within organizations and between organizations. Use of standardized names also helps minimize confusion regarding which problem is being addressed, such as which vulnerabilities a new patch mitigates. This helps organizations to quickly identify the information they need, such as remediation information, when a new problem arises. This publication provides information and recommendations related to the two most widely used vulnerability naming schemes: Common Vulnerabilities and Exposures (CVE), and Common Configuration Enumeration (CCE). Both are described in detail below. 2.1 Common Vulnerabilities and Exposures (CVE) The CVE vulnerability naming scheme is for a dictionary of unique, common names for publicly known software flaws. CVE provides the following: * A comprehensive list of publicly known software flaws * A globally unique name to identify each vulnerability * A basis for discussing priorities and risks of vulnerabilities * A way for a user of disparate products and services to integrate vulnerability information A CVE vulnerability entry consists of a unique identifier number, a short description of the vulnerability, and references to public advisories on the vulnerability. Figure 1 shows an example. CVE ID: CVE-2000-0001 Description: RealMedia server allows remote attackers to cause a denial of service via a long ramgen request. References: BUGTRAQ: 19991222 RealMedia Server 5.0 Crasher (rmscrash.c) BID:888 URL:http://www.securityfocus.com/bid/888 Landfield Expires April 18, 2011 [Page 4] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 XF:realserver-ramgen-dos Figure 1. Example CVE Entry Working with researchers, The MITRE Corporation assigns CVE IDs to publicly known vulnerabilities in commercial and open source software. General information on CVE is available at http://cve.mitre.org/. The National Vulnerability Database (NVD), which is maintained by NIST, provides several ways of accessing CVE entries. NVD offers CVE search capabilities, as well as a variety of XML and RSS data feeds with CVE entries and supplemental information to support security automation technologies. NVD is publicly available at http://nvd.nist.gov/. The MITRE Corporation maintains information on the use of CVE. Vendors that include CVE identifiers in their security advisories are listed at http://cve.mitre.org/compatible/alerts_announcements.html. Products and services that have been reviewed and evaluated by the MITRE Corporation and determined to be ?CVE-compatible?, which means that they meet a set of CVE requirements, are listed at http://cve.mitre.org/compatible/compatible.html. 2.2 Common Configuration Enumeration (CCE) 5 The CCE 5 vulnerability naming scheme is for a dictionary of names for software security configuration settings. Each type of security-related configuration issue is assigned a unique identifier to facilitate fast and accurate correlation of configuration data across multiple information sources and products. There are five attributes in a CCE entry: a unique identifier number, a description of the configuration issue, logical parameters of the CCE, the associated technical mechanisms related to the CCE, and references to additional sources of information. Figure 2 provides an example of these attributes for a CCE 5 entry for Windows XP. CCE ID: CCE-3108-8 Description: The correct service permissions for the Telnet service should be assigned. Parameters: (1) set of accounts (2) list of permissions Technical Mechanisms: (1) set via Security Templates (2) defined by Group Policy References: Listed at http://cce.mitre.org/lists/cce_list.html Figure 2. Example CCE Entry The MITRE Corporation maintains and publishes the lists of CCE names. The lists, and additional information on CCE, are available at http://cce.mitre.org/. Landfield Expires April 18, 2011 [Page 5] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 3 Identifier Syntax 3.1 CVE Identifier Syntax The CVE identifier is a string and is composed of three components spearated by hyphens: the CVE prefix, the year, and the vulnerability number. The CVE prefix is the string "CVE". The year is the year that the vulnerability was identified. The vulnerability number is a four digit ASCII string and is assigned pseudo-randomly. This prevents guessing the next CVE identifier; people would attempt to guess the identifier and this would result in name collisions when they guessed incorrectly. 3.2 CCE Identifier Syntax The CCE identifier is a string and is composed of three components separated by hyphens: the CCE prefix, a configuration identifier number, and a check digit. The CCE prefix is the string "CCE". The configuration identifier number is a variable length ASCII numeric string and is assigned pseudo-randomly. This prevents guessing the next CCE identifier; people would attempt to guess the identifier and this would result in name collisions when they guessed incorrectly. The check value is a single numeric character. The Luhn check digit algorithm is used to generate the check value. [LUHN] The check digit addresses user entry problems, since administrators would routinely fat finger the identifier. 4 Security Considerations 4.1 Security Considerations for End User Organizations This section provides recommendations for end-user organizations on how they should take advantage of the CVE and CCE specifications to improve their system security management. For all recommendations in this section involving an organization using CVE and CCE names, the organization should use the authoritative names; locations for downloading these are listed in Section 2. Some of the Landfield Expires April 18, 2011 [Page 6] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 recommendations in this section involve the Common Platform Enumeration (CPE) version 2.2 specification. CPE provides standardized, consistent names for referring to operating systems, hardware, and applications. CPE names are often used in conjunction with CVE and CCE names. Each CVE name and CCE name is related to one or more IT components, which can be expressed using CPE names. For example, a particular software flaw (identified by a CVE name) may affect seven products (identified by their CPE names). Using CPE names with CVE and CCE names further supports interoperability and standardization across products and services. The official CPE dictionary is available at http://nvd.nist.gov/cpe.cfm. 4.1.1 Product and Service Selection and Design 1. When evaluating IT products and services that use vulnerability names, such as for possible acquisition, organizations should take into consideration the products and services? support for CVE and/or CCE (as appropriate). Most organizations use a variety of products and services to detect, track, and mitigate vulnerabilities. Using standardized vulnerability names across products and services makes it much easier and faster to correlate information and to aggregate data from many disparate sources into a unified interface, such as a security dashboard. 2. Organizations developing their own custom security software that will use vulnerability names should ensure that the software uses authoritative CVE and/or CCE names, as appropriate, and uses CPE names with them when indicating which IT products the CVE and CCE names apply to. Using CVE, CCE, and CPE names supports interoperability with other software and services. 4.1.2 Vulnerability Communications and Reporting 1. Organizations should use authoritative CVE and CCE names in their internal vulnerability assessment and reporting, including assessment reports, notifications to system owners of detected vulnerabilities, and alerts identifying the vulnerabilities being targeted by active exploits. Use of CVE and CCE names will help to minimize confusion regarding which vulnerability is being referenced and whether a particular vulnerability has been mitigated. Organizations should also use CPE names when indicating which IT products the vulnerabilities apply to. 2. Organizations should use authoritative CVE and CCE names in their external vulnerability communications, as well as the CPE names for the IT products that the vulnerabilities apply to. For example, communications to incident response teams should reference, when known, the CVE or CCE names of the vulnerabilities that are being Landfield Expires April 18, 2011 [Page 7] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 exploited and the CPE names of the products that are being exploited. This ensures that incident communications precisely identify relevant vulnerabilities and affected products, enable correlation and integration of reports, and enable correlation with supplemental information residing in other data repositories. Another example is that organizations should use CVE and CCE names when communicating with vendors that support CVE and CCE names. Suppose that a vendor- supplied patch that purports to fix a vulnerability is defective; a statement to the vendor that a given CVE vulnerability remains after applying the patch conveys important information clearly and succinctly. Communications with vendors of scanning tools regarding false positives or false negatives will be clearer if the offending vulnerability is labeled by CVE or CCE name. 3. Organizations should encourage security software vendors to incorporate support for CVE and CCE into their products, as well as encourage all software vendors to include authoritative CVE and CCE names in their product security advisories and other security-related documentation and communications, as well as to reference the CPE names for their products. 4.2 Security Considerations for Software Developer and Service Providers This section makes recommendations for how software developers and service providers should take advantage of CVE and CCE?s capabilities. This improves interoperability, thus increasing the efficiency of security management and improving the security of systems. Also, as described in the introduction to Section 3, using CPE names when indicating which products CVE and CCE names apply to further supports interoperability and standardization. 4.2.1 Name Creation 1. Software developers should participate in the CVE issuance processes to help ensure that CVEs provide the necessary information and are created in a timely manner, such as while planning a public vulnerability announcement or immediately after a vulnerability has been publicly announced. For more information on the CVE issuance process, see http://cve.mitre.org/cve/identifiers/index.html or contact cve@mitre.org. 2. Authors of CVE names should reference applicable vendor patch identification whenever possible. 3. Software developers are encouraged to work with the MITRE Corporation to establish unique CCE identifiers for their products? security configuration settings. Basic information on this is available at http://cce.mitre.org/lists/creation_process.html. Landfield Expires April 18, 2011 [Page 8] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 Software developers should contact the CCE Content Team at cce@mitre.org for more information on the process. 4.2.2 Name Use 1. Software developers and service providers should incorporate support for CVE and CCE into their products and services that reference publicly known software vulnerabilities. Also, CPE names should be used when indicating which products the CVE and CCE names apply to. 2. Software developers and service providers should incorporate the appropriate authoritative CVE and/or CCE names in their security advisories and other vulnerability-related documentation and communications, as well as the CPE names that indicate which products the CVE and/or CCE names apply to. Using CVE, CCE, and CPE names supports the use of standardized security automation technologies, which rely on common vulnerability and product names, and ensures clarity when referencing a given vulnerability. 5 IANA Considerations This document has no actions for IANA. 6 Security Considerations This document describes naming conventions and current processes for uniquely identify common security vulnerabilities and configuration information. These processes do not directly create new security vulnerabilities, and establishing a common language for discussing vulnerabilities and configuration information permits a more robust dialogue regarding security problems. In some circumstances, disclosing configuration information may identify security vulnerabilities that could aid an attacker. When sharing information regarding specific systems, administrators may wish to employ encryption. However, administrators should recognize that an attacker may have other opportunities to identify the vulnerability, so encrypting this information is not a substitute for closing vulnerabilities! 7 IANA Considerations This document has no actions for IANA. Future standardization work may create registries for IANA to Landfield Expires April 18, 2011 [Page 9] INTERNET DRAFT SCAP Naming Conventions October 15, 2010 maintain. 8. Acknowledgements Much of the text in this document was taken from an ongoing revision of NIST Special Publication 800-51 by Dave Waltermire and Karen Scarfone. Tim Polk and Dave Waltermire helped get the document into Internet-Draft format. This document was formatted using NroffEdit v 1.34 which is freely available from aaa-sec.com. 9 References 9.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LUHN] U.S. Patent 2,950,048, Computer for Verifying Numbers, Hans P. Luhn, August 23, 1960. 9.2 Informative References [CCE] http://cce.mitre.org [CVE] http://cve.mitre.org Author's Addresses Kent Landfield McAfee EMail: kent_landfield@mcafee.com Landfield Expires April 18, 2011 [Page 10]