Formalization of IT systems description with CPE

Date : November 06, 2008

A structured naming scheme to describe information technology systems

An IT system is often heterogeneous, with many machines, operating systems and software from various providers/editors and with multiple versions.
This makes the handling of security advisories and the patch management rather tedious and complicated. Therefore, the idea to automate this process by developing tools that automatically determine which IT entity is affected by a given security advisory is gaining ground.

However, the development of such tools is hampered by the fact that the description of an IT system is usually made in natural language (a language which is by definition not formal).
For example, the Microsoft Internet Explorer browser in version 7 may be designated by the following literal expressions:

  • Microsoft Internet Explorer 7
  • Internet Explorer 7
  • IE 7
  • Microsoft Internet Explorer version 7
  • .........

If we consider together the difficulty to name formally IT elements and the difficulty to handle a very large number of combinations of software and platforms, it appears that automatic management of security advisories becomes impossible.

It might be interesting to use a formal language to clearly distinguish a piece of software or hardware, and create links between different elements to describe a whole platform (such as IE 7 on Windows XP SP3).

The CPE initiative

The CPE (Common Platform Enumeration) initiative meets this need by defining a dictionary containing the names of the basic elements of IT systems, a syntax for combining these names to describe complex platforms and a method for checking (or matching) a name against a platform.

Beyond the technical side, this initiative is based on the definition of roles and responsibilities:

  • Moderator: This is an impartial entity, which ensures and coordinates the development of the CPE standard for the entire community through public discussions (meetings or mailing lists). It is also responsible for the website of the CPE initiative.
  • Developers: They are responsible for the implementation of the standard improvements (maintenance of the dictionary, changing specifications) in accordance with the guidelines provided by the moderator entity.
  • Contributors: They contribute to the development of the standard by proposing new names, new tools or various modifications.
  • Users: They are the IT platforms managers, editors of patch management solutions, editors of security advisories... people who use the dictionary and the CPE syntax to describe CPE platforms and to assess the links between different IT entities.

CPE names

They are used to identify and specify basic IT elements (application, operating system, hardware).

They are represented by a URI with the following syntax:

cpe:/(part): (vendor): (product): (version): (update): (edition): (language)

where

  • part = "h" (hardware), "o" (operating system) or "a" (application).
  • vendor = highest organization-specific label of the organization's DNS name
For example Cisco (cisco.com), Mozilla (mozilla.org), Oxford (oxford.ac.uk).
  • The 5 remaining components represent the product, version, update, edition and language. They are optional.
A list of allowed abbreviations (IE, jre pro ...) is published on the CPE initiative website.

 Examples of CPE names:

  • cpe:/a:zonelabs:zonealarm_internet_security_suite:7.0
  • cpe:/o:microsoft:windows_2000::sp4:pro
  • cpe:/a:mozilla:firefox:2.0.0.6::osx:zh-tw
  • cpe:/h:cisco:router:3825

 These names are listed in a dictionary defined with the XML meta-language. Besides the definitions of product names, this dictionary can also be used to establish a link between a product and an OVAL request (see the "Matching" section).

The CPE language

It is used to link basic elements together in such a way to describe whole complex IT platforms (a given application runs on a given OS and on a specific architecture).

It mainly consists of Boolean expressions allowing to evaluate if an element or a set of elements belongs to a platform.

This language consists of elements/tags defined with the XML meta-language. These tags are the following ones:

  • <cpe:platform-specification> is the root element of a CPE document, which can contain one or more platforms descriptions.
  • <cpe:platform> is the element which describes a platform or a type of platform.
  • <cpe:title> and <cpe:remark> are optional elements used to describe a platform. They can provide information in natural language on the described platform.
  • <cpe:logical-test> contains a list of items (described with <cpe:fact-ref> tags or with other <cpe:logical-test> tags) and an indication of the logical operator (OR or AND) which links these elements.
  • <cpe:fact-ref> the basic tag that references a CPE name.

For example, the description of Microsoft Office 2003 or 2007 on Microsoft Windows XP should be written as follows:

<? xml version = "1.0" encoding = "UTF-8"? "
<cpe:platform-specification xmlns:cpe="http://cpe.mitre.org/language/2.0">
     <cpe:platform id="789">
         <cpe:title> Microsoft Windows XP with Office 2003 or 2007 </ CPE: title>
         <cpe:logical-test operator="AND" negate="FALSE">
             <cpe:fact-ref name="cpe:/o:microsoft:windows_xp" />
             <cpe:logical-test operator="OR" negate="FALSE">
                 <cpe:fact-ref name="cpe:/a:microsoft:office:2003" />
                 <cpe:fact-ref name="cpe:/a:microsoft:office:2007" />
             </ CPE: logical-test>
         </ CPE: logical-test>
     </ CPE: platform>
</ CPE: platform-specification>

Matching

The formal description of IT elements and platforms should enable to establish or assess correlations between one (or several) element(s) and one (or several) platform(s), typically in the patch management context, in order to check if an IT system is affected by a vulnerability for which a list of potentially impacted products/platforms has been provided by the advisory editor.

The CPE initiative allows matching a platform against a list of potentially affected systems:

  • Either through links between CPE names and OVAL requests (Open Vulnerability Assessment Language),
  • Or, when a CPE name has no associated OVAL request, via algorithms provided in the CPE specifications.

Conclusion

Thanks to its vocabulary, its syntax and its methods, the CPE initiative seems to have a very promising future in particular for automating tasks related to the processing of security advisories ant the patch management.

For more information:

Previous Previous Next Next Print Print