There was an interesting
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.

360 Mobile Vision - North & South Carolina Security products and Systems Installations for Commercial and Residential - $55 Hourly Rate. ACCESS CONTROL, INTRUSION ALARM, ACCESS CONTROLLED GATES, INTERCOMS AND CCTV INSTALL OR REPAIR 360 Mobile Vision - is committed to excellence in every aspect of our business. We uphold a standard of integrity bound by fairness, honesty and personal responsibility. Our distinction is the quality of service we bring to our customers. Accurate knowledge of our trade combined with ability is what makes us true professionals. Above all, we are watchful of our customers interests, and make their concerns the basis of our business.

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
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

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 18th, 2020 where I discussed another set of
third-party vulnerabilities in the eSOMS product from Hitachi ABB Power Grids.
Again, the NCCIC-ICS
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
, 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

By admin