CPE Introduction: Common Platform Enumeration

Good day, colleagues!
One of the problems faced by the creators of compliance-management products is the process of comparing the results of system inventory and vulnerabilities. It is based on the fact that when formally documenting a vulnerability in a database (for example, in NVD ), the applicability of the vulnerability is described by the formal language CPE . It is a way of describing all possible products, operating systems, and hardware devices.

Designed as a universal format, it remained the utopia of MITER .
It lies in the “foundation” of formalized information storage in information security, the way in which CVE vulnerability information is presented .
The basis of the language is the dictionary , which is essentially a reference book that allows you to find out the correspondence between abbreviations of the standard form and their additional information. Let's see how the CPE abbreviations work:



As can be seen from the diagram, the CPE code string is divided into logical sections through the ":" symbol. The number of fields is determined by the desired degree of approximation, replacing unnecessary fields with an empty string if necessary. Thus, for maximum detail, the values ​​of all fields should be specified, and to summarize the sample, gaps should be made in the desired places. The rules for the preparation of these structures can be found in detail in the specification .
')
Having such a link, you can refer to the dictionary and get the XML data block about the product. Consider it on the example of cpe: / o: sun: sunos: 5.9 :

<cpe-item name = "cpe: / o: sun: sunos: 5.9" >
<title xml: lang = "en-US" > Sun SunOS (formerly Solaris 9) 5.9 </ title >
<check href = " oval.mitre.org/repository/data/DownloadDefinition?id=oval : org.mitre.oval: def: 2174" system = " oval.mitre.org/XMLSchema/oval-definitions-5" > oval : org.mitre.oval: def: 2174 </ check >
<meta: item-metadata modification-date = "2011-01-19T19: 36: 00.913Z" status = "DRAFT" nvd-id = "122557" />
</ cpe-item >

As you can see, information about the product itself, its unique identifier nvd-id, and the “check” block are provided. The most interesting is the verification block, since it contains a link to a formalized OVAL check about which I already wrote earlier . This link allows you to uniquely identify the system using the specified criteria in the definition. Unfortunately, these links to the product inventory method in the system are currently uncommon for CPE.

Of course, this system could not do without logical elements , allowing to set bundles of products. This solution is also necessary to determine the applicability of the vulnerability:

<cpe-lang: logical-test negate = "false" operator = "OR" >
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2: 9.0" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 6.0" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 7.0 :: linux" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 7.1 :: linux" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 7.2 :: linux" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 8.0 :: linux" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 8.1 :: aix" />
<cpe-lang: fact-ref name = "cpe: / a: ibm: db2_universal_database: 8.2 :: windows" />
</ cpe-lang: logical-test >

As can be seen from the context, these strings describe the “OR” condition for a group of products.
Thus, the condition will be positive in the presence of any of these products.
In the complex, these tools allow you to determine the "applicability" guaranteed accurate way.

On this I would like to finish the description of the language CPE. This MITRE solution was designed to standardize all existing platforms and create methods for their determination. But, unfortunately, vendors ignored the call and such a promising tool as CPE still remains rare.
Therefore, when creating tools for processing and searching for vulnerabilities, you must resolve these dependencies most often manually. Such a sad fact will remain so until the creators of the software start systematized to get information about their products.

Thank you for your time.
Until new meetings.