How will the FCC construct their IoT Device Registry/Vulnerability Database?

My most recent post discussed the FCC’s desire to create an IoT Device Registry, in conjunction with the future IoT device cybersecurity labeling program that was originally ordered in Executive Order 14028 in May 2021. A centerpiece of the Registry will be a list of vulnerabilities applicable to the device. I think this is something that’s needed. However, the question is whether something like it is in place now, and if not, how it can be implemented.

The only existing vulnerability database for devices is the National Vulnerability Database (NVD). A vulnerability database is only useful if it’s easy to find vulnerabilities for a product in it, but in fact it isn’t easy to find IoT devices (or software products, for that matter) in the NVD at all. In the previous post, I discussed the many problems with the CPE identifier on which the NVD is based. I also pointed out a different identifier that is already heavily used to track intelligent devices (and a lot of other things) in international trade: GTIN, one of the GS1 standards. Could the NVD adopt GTIN for devices?

The answer is that it could, but it would take many years and probably a large dollop of private sector support – in terms of time, talent and money. These are the main steps that would be required (I know about these, since the OWASP SBOM Forum has proposed adding purl identifiers to the NVD):

1.      The data in the NVD comes from CVE Reports, which are created by CVE Numbering Authorities (CNAs) and submitted to CVE.org. When a software supplier or intelligent device manufacturer wants to report a vulnerability in one of their products, they contact a CNA to create the CVE report for them. The CVE report contains a CVE number assigned by the CNA, as well as the common name(s) of one or more products that are affected by the vulnerability.

2.      The data from the report is entered in the CVE.org database and then “flows down” to the NVD, which is run by a team from NIST. A member of that team creates a CPE name for the product in the report. The information from the report is added to the NVD.

3.      If GTINs were to be added to the NVD, they would need to be included in the CVE report; that is, the CVE report would need to be able to list the common name of an intelligent device as well as its GTIN (which should always be known to the manufacturer). That requires a change to the CVE JSON schema, on which the CVE Report is based.

4.      The most recent version of the CVE JSON schema is 5.0, although the NVD has not yet implemented it (I was told they’re having some problems doing that).

5.      The next version of the spec will be 5.1, which includes a pull request that the SBOM Forum made in 2022, to add purl to the CVE Report. That request was accepted, but given the delays in just getting v5.0 implemented and the need to implement 5.1 next, it will be at least a couple years before the 5.1 spec is implemented in the NVD, and purls can be included in CVE reports. I’m sure it will be 1-2 years after that before the next version of the spec (presumably 5.2) could be implemented, including (hypothetically) support for GTINs.

6.      Moreover, just implementing the 5.2 spec won’t immediately add GTIN to the NVD, since new CVE reports including GTINs would have to be entered to do that. The existing CVEs for IoT devices won’t be linked to GTINs, unless someone is willing to conduct a long (and manual) effort to add GTINs to those reports.

In other words, adding GTIN to the NVD will be a long, expensive process – and that’s the good news. The bad news is that it wouldn’t fix the biggest problem that faces any vulnerability database for intelligent devices: the lack of vulnerabilities. By that, I mean that a huge percentage of intelligent device manufacturers (very likely the great majority of them) never report vulnerabilities at all, and the rest probably seriously underreport them (in case you didn’t know this, almost all CVEs are reported by the supplier of the software or the device).

How do I know that device vulnerabilities are being seriously underreported? Because if a device manufacturer isn’t listed on any CPE names in the NVD, this means they have never reported a vulnerability for any of their devices; a search on the manufacturer’s name will yield “There are 0 matching records.”

Since I didn’t have time to go through the hundreds of thousands of CPE names in the NVD to determine which were IoT devices, I decided just to focus on medical devices. If any device makers are reporting vulnerabilities (and remember, when a vulnerability is reported, there is almost always a patch available for it. Very few software or device suppliers would report an unpatched vulnerability), it should be the medical device makers, right? After all, in the US, medical devices are one of the few device types that are subject to cybersecurity regulations (from the FDA).

I got a list of the top ten medical device makers and checked for every one of them in the NVD (I checked multiple ways of entering each name, since there’s no way to be sure exactly how the manufacturer is listed in CPE names). For the top ten, I found:

·        Four have never reported a vulnerability (one of them had already told me that. The person also said they wouldn’t know how to report a vulnerability if they had to).

·        Four have reported a suspiciously low number of vulnerabilities (in the low hundreds of CPEs, which could in fact mean just 25-50 CVEs. Note that a CVE is always reported by product and version number. If a device has three vulnerabilities in five versions each, there should be 15 CPE names in the NVD, just for that device), meaning they’re undoubtedly not reporting many of the device vulnerabilities they know about.

·        The remaining two companies are huge conglomerates who sell lots of different devices and software. There are a lot of CPEs reported, but there’s no good way to find out which ones are for medical devices, if in fact any are for medical devices.

And remember, these are medical devices, whose proper functioning is often required to keep people alive. If they’re not reporting vulnerabilities, is it likely that manufacturers of other devices are? Of course not (the only other type of device I checked was baby monitors. I couldn’t find any of those manufacturers who had reported vulnerabilities).

In the first paragraph of this post, I asked two questions. One is whether there’s an existing IoT vulnerability database that the FCC could piggyback on (or imitate) to implement their desired Device Registry. The NVD is the only existing IoT vulnerability database, but it is based on an identifier, CPE, that poses big problems. Plus, fixing the CPE problem – by implementing GTIN identifiers – will take many years, if it will succeed at all (and it’s not at all certain that NIST will even be interested in adding a new identifier to the NVD. They may think that CPE is just fine, thank you very much). The NVD can’t be the basis for a new IoT vulnerability database.

So, the FCC needs a new vulnerability database for IoT products. While creating a new vulnerability database sounds hard, the fact is that new vulnerability databases pop up all the time. One reason that changes take so long with the NVD is that portions of the database are 10-20 years old, so there’s a huge amount of legacy baggage that a new database wouldn’t have to deal with. A new IoT vulnerability database would need to download all the device data from the NVD and update it continually. Since the entire NVD can be downloaded in much less than an hour (I’m told), this should be the least of the problems.

The big problem for the Device Registry will be getting device manufacturers to start reporting vulnerabilities, since – except for a few device makers like Cisco – they really aren’t doing that today. However, device makers won’t be able to report vulnerabilities to CVE.org today, since GTINs aren’t supported in CVE reports now, and – as I’ve already documented – changing the CVE JSON spec will require several years.

How about if there were a new vulnerability type, perhaps operated by CVE.org but perhaps not? This might resemble the current CVE spec, but it will have to differ from it if it includes GTINs. Why not design a new vulnerability type that might be more suited to intelligent devices and might also make the device makers more interested in reporting vulnerabilities?

I have no idea what this new vulnerability spec would look like, but I do know that, if the FCC wants to have a way for device users (and prospective users) to learn about vulnerabilities in intelligent devices, there needs to be an easy-to-use database, which has good data on device vulnerabilities. Neither of these is the case today.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

I lead the OWASP SBOM Forum. If you would like to join or contribute to our group, please go here, or email me with any questions.