|
|||||
 |
 |
||||
| CPE Website is in "Archive" status — read the announcement | |||||
CPE Specifications — ArchiveNaming | Matching | Dictionary | Applicability Language | Download Specifications & Reference Implementation
CPE Version 2.3 was released by the U.S. National Institute of Standards and Technology (NIST) in August 2011. CPE v2.3 is also included in Version 1.2 of NIST’s Security Content Automation Protocol (SCAP) standard. CPE v2.3 supersedes CPE v2.2, which was released in March 2009. (NOTE: NIST continues to provide support for a CPE v2.2-conformant Dictionary.) CPE Version 2.3 departs significantly from past CPE practice by breaking the CPE standard into a suite of separate specifications organized in a stack: Naming, Name Matching, Dictionary, and Language. Naming is the foundation of the stack, with each specification building on those that precede it. CPE Version 2.3Brief overviews of the four CPE v2.3 specifications are included below, or go the Downloads section to download the individual specification documents and a CPE v2.3 reference implementation. NamingThe CPE 2.3 Naming Specification defines standardized methods for assigning names to IT product classes. An example is the following name representing Microsoft Internet Explorer 8.0.6001 Beta: wfn:[part="a",vendor="microsoft",product="internet_explorer", This method of naming is known as a well-formed CPE name (WFN). It is an abstract logical construction. The CPE Naming Specification defines procedures for binding WFNs to machine-readable encodings, as well as unbinding those encodings back to WFNs. One of the bindings, called a Uniform Resource Identifier (URI) binding, is included in CPE 2.3 for backward compatibility with CPE 2.2 (see the CPE Archive). The URI binding representation of the WFN above is: cpe:/a:microsoft:internet_explorer:8.0.6001:beta The Official CPE Dictionary published and maintained by NIST contains an authoritative enumeration of CPE names in the URI binding representation. The second binding defined in CPE 2.3 is called a formatted string binding. It has a somewhat different syntax than the URI binding, and it also supports additional product attributes. With the formatted string binding, the WFN above can be represented by the following: cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:* The WFN concept and the bindings defined by the CPE Naming specification are the fundamental building blocks at the core of all CPE functionality. CPE 2.3 Naming Specification Document and CPE Reference ImplementationGo to the Downloads section below to download the entire CPE 2.3 Naming Specification document, NIST IR 7695. Also available is zip file of MITRE’s CPE Reference Implementation of the procedures specified in NIST IR-7695 for binding and unbinding WFNs. MatchingThe CPE 2.3 Name Matching Specification defines a method for conducting a one-to-one comparison of a source CPE name to a target CPE name. By logically comparing CPE names as sets of values, CPE Name Matching methods can determine if common set relations hold. For example, CPE Name Matching can determine if the source and target names are equal, if one of the names is a subset of the other, or if the names are disjoint. One example of the value of CPE Name Matching is in determining if a particular product is installed on a system. Suppose that an organization is identifying which of its systems have any variation of Microsoft Internet Explorer 8 installed. This could be represented with the following well-formed CPE name (WFN): wfn:[part="a",vendor="microsoft",product="internet_explorer", An asset management tool could collect information on the software installed on a system and compare its Internet Explorer installation characteristics to the WFN above. Suppose that the WFN for a particular installed instance of Internet Explorer was reported as: wfn:[part="a",vendor="microsoft",product="internet_explorer", Using these two example WFNs, CPE Name Matching methods perform a pairwise comparison of attribute values in the first (source) WFN to those in the second (target) WFN, yielding a list of the set relations between each pair of attributes (e.g., equal, superset). This list of comparison results is then assessed, leading to a determination that the first WFN represents a superset of the second WFN. This can be interpreted to mean that the system being examined does indeed have a variation of Microsoft Internet Explorer 8 installed. Although this may seem like a trivial example, CPE Name Matching is a powerful and flexible way of performing product comparisons in a standardized, automated manner. CPE Name Matching is also used by other CPE specifications to conduct more complex tasks, such as searching for product names in CPE dictionaries and performing complex comparisons of sets of product versions-for example, determining if a system is running a particular operating system version, running two particular applications, and not running a third particular application. CPE 2.3 Name Matching SpecificationGo to the Downloads section below to download the entire CPE 2.3 Naming Matching Specification document, NIST IR-7696. DictionaryThe CPE 2.3 Dictionary Specification defines a standardized method for creating and managing CPE dictionaries. A dictionary is a repository of CPE names and metadata associated with the names. Each CPE name in the dictionary identifies a single class of IT product in the world. The word "class" here signifies that the object identified is not a physical instantiation of a product on a system, but rather the abstract model of that product. Although organizations may use a CPE name to represent either a single product class or a set of multiple product classes, a CPE dictionary stores only bound forms of well-formed CPE names (WFNs) that identify a single product class, not a set of product classes. These single product-class WFNs in bound form are referred to as identifier names. An example of a WFN and its bound forms is shown below.
Official CPE DictionaryNIST hosts the Official CPE Dictionary, which is the authoritative repository of identifier names. The authoritative nature of the Official CPE Dictionary allows organizations to search for and find identifier names in one centralized place without worrying about dealing with conflicts between federated dictionaries. Other CPE DictionariesOrganizations may create their own extended CPE dictionaries, which are used to store identifier names not present in the Official CPE Dictionary. There are several reasons why extended dictionaries are needed. For example, an organization may have to create identifier names for proprietary products that are only useful within that organization, such as internally developed software not found outside the organization. Another possible reason is that an IT company may want to use identifiers for their unreleased products that do not yet have official identifier names; once the identifier names have stabilized, the company would submit them to the Official CPE Dictionary. Adding New CPE Identifiers to the DictionaryAn organization may discover new products in use that do not yet have official identifiers; the organization could create identifiers, add them to its own extended dictionary, submit them for inclusion in the Official CPE Dictionary, and use them internally while waiting for their addition to the Official CPE Dictionary. See the CPE Dictionary page on this website for an overview of the submission process. CPE 2.3 Dictionary SpecificationGo to the Downloads section below to download the entire CPE 2.3 Dictionary Specification document, NIST IR-7698. Applicability LanguageThe CPE 2.3 Applicability Language Specification defines a standardized way to describe IT platforms by forming complex logical expressions out of individual CPE names and references to checks. For example, one could use the CPE 2.3 Applicability Language to combine the CPE name for an operating system (such as Microsoft Windows XP), the CPE name for an application running on that operating system (such as Microsoft Office 2007), and a reference to a check for a particular value of a certain configuration setting (such as the wireless network card being enabled in the operating system). These logical expressions are called applicability statements, because they are used to designate which platforms particular guidance, policies, etc. apply to. Applicability statements can be used by tools to determine whether a target system is an instance of a particular platform. The CPE names used by the CPE 2.3 Applicability Language specification are bound forms of well-formed CPE names (WFNs), which are the abstract logical constructions for CPE names. The basic building block of the CPE 2.3 Applicability Language Specification is referred to as the logical test. This is a logical conjunction (AND) or disjunction (OR) of one or more CPE names and/or references to checks. Individual logical tests can also be negated (inverted). Nested logical tests allow the user to express a platform as any logical combination of individual CPE names and/or references to checks. Note that previous versions of CPE referred to the Applicability Language Specification as simply the Language specification. CPE 2.3 Applicability Language SpecificationGo to the Downloads section below to download the entire CPE 2.3 Applicability Language Specification document, NIST IR-7697. DownloadsSpecifications — Version 2.3The following CPE 2.3 Specifications are available to view or download from NIST’s Computer Security Resource Center:
Reference Implementation — Version 2.3MITRE has created a reference implementation of the CPE Naming and Matching algorithms, as described in NIST IRs 7695 and 7696. Note that the ZIP file below contains a readme.txt file that explains how to build and run the application.
|
||||
