Source of CPE Numbers

There was an interesting Twitversation yesterday about CPE numbers. It started with Ron Brash complaining about the Rockwell advisory that I talked about Tuesday. I contributed a less than helpful comment because I ‘read’ his comment as being about CVE numbers not CPE’s. That misunderstanding caused me to do some research into Ron’s complaint.

What’s a CPE?

First, let’s look at the better known ‘CVE’, Common Vulnerabilities and Exposures. The CVE is actually a list of vulnerabilities maintained by MITRE. In common use ‘a CVE’ is the unique, numbered record for a specific vulnerability. The National Institute of Standards and Technology (NIST) maintains a database of the CVE list called the National Vulnerability Database (NVD).

To make it easy for organizations to determine what CVE’s apply to a particular piece of software, NIST developed the Common Platform Enumeration (CPE) Dictionary. This allows for the creation of a unique standard identifier (CPE number) for any specific version of any piece of listed software. This allows for searching of the NVD for vulnerabilities related to that specific version without having to worry about how to type in the name and version number of the software of concern with all of the I’s dotted and T’s crossed, a common problem in database searches.

NIST maintains a CPE dictionary to aid users in finding the proper CPE number for their searches.

CPE and CVE Relationship

To see how the CVE’s and CPE’s work in practice let’s look at one of the vulnerabilities Rob was complaining about. The NCCIC-ICS advisory for the Rockwell Automation Stratix Switches lists eight vulnerabilities in five separate Stratix products affecting a number of different versions of each product. The first of the eight is an insufficiently protected credentials vulnerability - CVE-2021-1392. If we look a the NVD record for that vulnerability.

Today we see that the vulnerability is in certain products from CISCO with no mention of Rockwell Automation. In the coming days we should (hopefully) see the addition of a reference to the Rockwell advisory from NCCIC-ICS under the ‘References to Advisories, Solutions, and Tools’ heading on the page.

Down towards the bottom of the page we see the ‘Known Affected Software Configurations’ section, a listing of CPE’s of individual versions of affected software. For this particular CVE there are 214 CPE’s listed. And as Rob noted in his initial TWEET yesterday, not a single Rockwell product is listed.

The Problem

The CVE Numbering Authority (CNA) reporting the vulnerability to MITRE/NVD is responsible for submitting all of the requisite information for the CVE. Presumably, this includes the affected CPE’s. In this case the CNA for CVE-2021-1392 is CISCO. While CISCO notified Rockwell of the vulnerability, they have no idea about which versions of which Rockwell products would be affected by that particular CVE, so they cannot provide the CPE’s of those affected Rockwell products. CISA’s NCCIC-ICS, the agency issuing the new advisory should be providing the Rockwell unique information including CPE’s.

Ooops. The MITRE CNA rules for CVE Entry Requirements do not say anything about CPE’s. Of course, this is because CPE’s are an NVD artifact, not technically part of the CVE process. So, somebody should be communicating with NIST/NVD and it still could not and should not be CISCO in this case. The reporting body should still be CISA’s NCCIC-ICS that published the Rockwell advisory.

I cannot tell from the outside if this is a failure of NCCIC-ICS to report information to NIST/NVD (if there even is a requirement/mechanism for such a report), or if this is a data processing backlog at NIST/NVD. Remember COVID-19 has messed up a lot of admin stuff and it will take a while to recover.

Easy Solution – New CVEs

The easy way to fix this going forward is that instead of re-using the CVE’s for the CISCO vulnerabilities, NCCIC-ICS should have just issued new CVE’s for the Rockwell vulnerabilities. The system for assigning CPE’s for new vulnerabilities appears to be working fine; simple. After all, CISCO fixing their vulnerability does not directly fix the Rockwell problem, Rockwell is going to have to make some sort of change to implement the CISCO fix.

There is a minor drawback to that solution. To understand it we need to look at my blog post from March 18^th, 2020 where I discussed another set of third-party vulnerabilities in the eSOMS product from Hitachi ABB Power Grids. Again, the NCCIC-ICS advisory used the original CVE numbers for the seven vulnerabilities in the Hitachi ABB product. Using those CVE’s, I was able to determine that there were publicly available exploits for three of the vulnerabilities, raising their potential risk. Without the link to the original CVE, I would have had a much harder time tracking down those exploits.

As Ron pointed out in a subsequent TWEET®, software bills of material will provide a longer term solution to the problem. A software vendor could provide CPE’s for each of the components that are included in their software and an owner/operator could search for both the component and end product CPE’s to remain aware of potential vulnerabilities in their software. But, again, this relies on CNA’s, MITRE and NIST/NVD all ensuring that the appropriate CPE’s get into the databases.

WARNING: My twisted mind has come up with other potential problems with CPE’s. More on that later.

NOTE: Corrected Ron's name (sigh) 4-22-21 2032 EDT