CISA Announces New CVE Partner – OMICRON Electronics

 Yesterday, CISA announced a new CVE Partner, OMICRON Electronics. This now makes OMICRON a CVE Numbering Authority under the CISA-ICS Root authority. That means that OMICRON can now assign CVE numbers and publish CVE records for vulnerabilities in its products, either those it detects itself or those reported to it. This also means that OMICRON has established a vulnerability disclosure process and point of contact for vulnerability reporting. 

As a practical matter going forward, when OMICRON publishes an advisory (see here for example) their products, the vulnerabilities reported in the advisory that are not 3rd party vulnerability would be expected to have CVE numbers assigned and included in the advisory. 

Information Sharing – CNA Responsibilities

I have recently reported  (here and here, subscription required) two separate instances where the CVE’s for vulnerabilities originally reported by Claroty still had no details available in the NIST NVD for the CVE numbers months after the associated advisories were published; they were still listed as “reserved”. I initially reported that I thought Claroty may be the CVE numbering authority (CNA) for those CVEs, but I was reminded that security research organizations could not be CAN’s, that role is essentially limited to national cybersecurity organizations and vendors.

I cannot tell for sure who the CNA for these vulnerabilities is; the MITRE CVE page for each vulnerability does not list the assigning CNA for ‘reserved’ CVEs. I now suspect, however, that it is probably NCCIC-ICS, they have published advisories for the two groups of vulnerabilities.

In any case, the CVE numbers for these vulnerabilities are currently worthless as information sharing devices, the role for which the CVE program was established. If CNA’s do not provide NIST and MITRE the timely follow-up information about reserved CVE’s, they are failing in their duty. Further, MITRE should have procedures in place to remind CNA’s about CVE’s that they have reserved, but for which they have not yet provided vulnerability data.

The CVE program has many well-known problems, but this goes to the base responsibilities of the program. Any new program that is stood up to replace it, is going to have to ensure that processes are in place to conduct the kind of follow-up that I described above.

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