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
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
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
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
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 18th, 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