Introduction to CPE: 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 the system inventory and these 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.

Conceived as a universal format, it remained the utopia of MITER .
It is laid in the "foundation" of the formalized storage of information in information security - in the way of submitting information about CVE vulnerabilities .
The base of the language is a dictionary , which is essentially a reference that allows you to find out the correspondence between standard abbreviations and their additional information. Let's see how CPE abbreviations work:



As can be seen from the diagram, the CPE code line is divided into logical sections through the ":" symbol. The number of fields is determined by the desired degree of approximation, if necessary, replacing unnecessary fields with an empty string. Thus, for maximum granularity, it is necessary to indicate the values ​​of all fields, and to generalize the selection, gaps must be made in the desired places. The rules for compiling these structures can be found in detail in the specification .

Having such a link, you can refer to the dictionaryand get the XML block of product data. Consider it using cpe: / o: sun: sunos: 5.9 as an example :

    Sun SunOS (formerly Solaris 9) 5.9
    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
    

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

Of course, this system could not do without logical elements that allow you to specify a bunch of products. This solution is also necessary for determining the applicability of the vulnerability:

        
        
        
        
        
        
        
        

As the context shows, these lines describe the “OR” condition for a product group.
Thus, the condition will be positive in the presence of any of these products.
In combination, these tools allow you to determine the "applicability" guaranteed accurate way.

On this I would like to finish the description of the CPE language. 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 like CPE is still not widespread.
Therefore, when creating tools for processing and searching for vulnerabilities, you have to resolve these dependencies most often manually. Such a sad fact will remain so until the creators of the software systematically begin to get information about their products.

Thank you for your time.
See you again.