Friday, January 5, 2024

What would an IoT vulnerability database look like?

I recently wrote about the FCC’s Notice of Proposed Rulemaking for an IoT device cybersecurity labeling program, issued last July and due to be updated around now (the program itself isn’t planned to be in place before the end of 2024). One of their suggestions in the NOPR is a “device registry”, i.e. a database where users and prospective users of IoT devices can go to learn about both product features and vulnerabilities, and use the information they find to compare different products before purchase.

Regarding product features, I don’t see any point in making a big effort to gather them into a single database, since probably every device manufacturer has a website where current and prospective customers can learn all they want to about their products. I know part of the FCC’s idea is that the device registry will make it easy to compare products, since the user will be able to choose two or more devices and compare their specifications side by side.

This is a nice idea, but it’s fantasy. If you’ve ever tried to compare products (of any sort) from two manufacturers by looking at their websites, you’ll know it’s very hard to make any straightforward comparison, because they almost never report exactly the same types of information in the same way (unless they’re mandated to do so, of course). This is no accident, since the last thing a manufacturer wants you to do is be able to hone in immediately on the advantage their biggest competitor has over them.

And in case you think that’s all the more reason to include “standardized” product information in the FCC’s device registry, I’ll just say that doing this is going to require a small army of researchers (or even a large one). Besides their salaries, those researchers will have to have a huge budget for buying and testing every new version of every device listed in the registry. If these were devices with military use or with significant safety impact, the cost might be justified. But for the great majority of IoT and IIoT devices, it isn’t justified at all.

But that leaves vulnerabilities. Regarding the idea of reporting vulnerabilities for devices in the registry, the FCC says in their NOPR, “We propose that consumers be made aware of any vulnerabilities….through the IoT registry.” At first, I pooh-poohed this statement. The purpose of a vulnerability database is not to inform users (along with every hacker in the world) of unpatched vulnerabilities in particular products. Rather, the purpose is for the supplier of the product to announce, after they have developed a patch for a vulnerability, which version(s) of the product are affected by that vulnerability and what the mitigation is for each of those versions – either applying a patch or upgrading to a new version that includes the patch.

You might ask what is the purpose of having a device registry for vulnerabilities, if the only vulnerabilities listed will be ones that have a patch available and therefore don’t pose a threat to a user that has applied the patch? For one thing, there will always be users who haven’t applied the patch, perhaps because they didn’t see the manufacturer’s notification of the vulnerability, which was sent to customers by email or posted on the manufacturer’s website.

But this reason alone isn’t a justification for the device registry, since there is already a “device registry” for vulnerabilities in IoT devices: It’s called the National Vulnerability Database (NVD). Why would the FCC want to go beyond what the NVD currently offers for identifying vulnerabilities in IoT devices? And, if the FCC decided to go beyond what the NVD now offers, where would they go? Are there any other vulnerability databases for IoT products?

To answer the last question first, I don’t believe there’s any other vulnerability database for IoT products other than the NVD or databases based on the NVD, like VulnDB. VulnDB (which has a very good reputation, by the way) starts from the current NVD data, but adds other vulnerabilities to the set of CVEs currently found in the NVD; they also clean up some of the NVD’s data. But they also charge for their services and most importantly are subject to what I believe is the primary problem with the NVD: how software and IoT products are identified in it.

The only way to identify any product in the NVD is by using a CPE (Common Platform Enumeration) name, which poses a lot of limitations for the user trying to find vulnerabilities in an IoT device. Even though CPE names are based on a rigid specification, they are not created by any automatic process. Instead, they are created by individual NIST staff members who are part of the NVD team.

Breaking news: Like all other people, NIST staff members make mistakes. This means that someone who is looking to find a particular device is not likely to find it if the NIST person made even a simple mistake in creating the CPE name. Unlike Google, the NVD doesn’t use fuzzy logic or AI to come up with suggestions for what you might be looking for. To get a usable result, you must enter an exact match to something in the database. Otherwise, you’re SOL (don’t ask what that means. It’s a technical term).

What if the NIST staff member didn’t make a mistake? Will it almost always be easy to find the CPE name you’re looking for? No. CPE names are created using the information that is included in a CVE report, which is created by one of the 300+ Certified Numbering Authorities (CNAs) that work on behalf of CVE.org. The CNA almost always gets the information to put in the report from someone who works for the manufacturer of the device (note that most CNAs are themselves software developers like Oracle and Red Hat). And believe it or not, those people aren’t perfectly consistent among themselves, either.

For example, suppose that in February, Jim Jones of Device Manufacturer A reports to a CNA that CVE-2024-12345 is found in the device that he calls “Router XYZ version 2.10.5”; that information is included in a CVE Report - which initially is sent to CVE.org, but from there flows down to the NVD. The CPE name listed as affected by that CVE is then created (by a NIST employee on the NVD team) using the information that Jim provided. But in March, Sue Smith of Device Manufacturer A reports that CVE-2024-23456 is found in the device she calls “Router_XYZ vsn. 02.10.05”. Is this the same device? After all, both the product name and the version string are different.

Rather than take a chance of being wrong if they decide that both vulnerabilities apply to the same device, the NIST NVD team member is likely to construct the two CPEs using different product names and version numbers – i.e., they will create a different CPE for each CVE report.

Of course, if Jim and Sue were referring to different versions of different products, that would be fine. But, if they were actually referring to the same version of the same product, that wouldn’t be fine. In that case, searching on one of the CPE names will just yield the one vulnerability that applies to that name. When someone searches for “Router XYZ version 2.10.5”, they will only find CVE-2024-12345. But when they search for “Router_XYZ v2.10.05”, they will only find CVE-2024-23456.

Thus, if the "two devices" are actually the same, a user of that device will not be able to learn about both vulnerabilities, unless they somehow know that the same product is listed under two CPE names. And how would they ever learn that there are two names (by the way, this same problem would occur if the NIST employee tried to use the first CPE name in the second CVE report, but instead made a typo. There would be two CPE names for the device, each listing just one vulnerability).

How about a user mistake? What happens if a customer of Device Manufacturer A fat fingers their NVD search and enters “Routet XYZ version 2.10.5”, not “Router XYZ version 2.10.5”? Instead of being told that CVE-2024-12345 is applicable to that product, will that person be told they probably mis-entered the product name? No, they won’t. They will see the message “There are 0 matching records.”

Unfortunately, this message appears just about every time a search doesn’t return any vulnerabilities. It could mean many different things, including:

a.      There is a CPE name that closely matches the information entered, but there is one small difference (perhaps “XYZ Inc.” instead of “XYZ, Inc.”) that makes it appear to be a different name. This might be due to a batch of product labels that omitted the comma in the company name, to a mistake made by the NIST person that created the CPE, or to a typo by the user executing the search – as well as other things.

b.      The device has been sold to a different manufacturer, meaning the CPE name for current and future vulnerabilities for that product/version has changed to include the new manufacturer name. Since the user doing the search is entering the name of the previous manufacturer, they can’t find any current vulnerabilities, because they are all entered using the new manufacturer’s name.

c.      The device is still made by the same manufacturer, but the marketing department has decided that “Router XYZ” isn’t the most scintillating name for it. They have decided that “SupeRouter” is much better. So, searching on “Router XYZ” now only identifies old versions of the product.

d.      The manufacturer decided to change how they represent product versions, so that minor versions are indicated with a letter and the patch level is prefaced by “Patch”. When the manufacturer introduces a new major version 3, instead of being referred to as “version 3.0.0”, it is referenced as “version 3A Patch 0”. If someone has an old version of the device and wants to find the new major version (and hasn’t been following the manufacturer’s announcements religiously), they will enter “version 3.0.0” and just see “There are 0 matching records.”

e.      The device searched for is completely vulnerability free (therefore, there are no matching CVE records).

f.       The device searched for is loaded with vulnerabilities, but the manufacturer has never reported a single one of them. Because a CPE name is only created when a CVE report refers to that device, no search for that device will ever turn up any matching records.

The last two reasons for the “There are 0 matching records” message are the most telling: The NVD will provide the same message when a user searches for a product that has no vulnerabilities as it does when the product is loaded with vulnerabilities (40,000 vulnerabilities in one case, as described in the post just referenced), but the manufacturer has never reported any of them. Unfortunately, most people who search the NVD are likely to be anticipating a good outcome: the product they’re searching for doesn’t have any vulnerabilities. They will always be pleased with this result, but their happiness will only be justified half the time.

The above should show that CPE is simply not a good identifier for IoT devices. What identifier would be better? I have been discussing purl a lot, since it is currently the only other identifier used in vulnerability databases, besides CPE. The OWASP SBOM Forum made purl the centerpiece of the “proposal” we put together in 2022 to (ultimately) replace CPE in the NVD. The best thing about purl is that there's no central database. 

To find an open source product in a vulnerability database based on purl, such as OSS Index, the user just needs to know the URL for the repository from which they downloaded the software (e.g. a package manager), and the name and version string of the project in that repository. However, purl can only be used with software that can be downloaded from a defined internet location. So far, nobody has been able to demonstrate to me a way to download a smart thermostat by clicking on a URL.

When the SBOM Forum put together the proposal in 2022, we would have preferred to find an “intrinsic” identifier (i.e., one that didn’t require a central database. See pages 7-9 of the proposal) for intelligent devices (purl is the poster child for intrinsic identifiers). Of course, there are none today.

However, another quality we were looking for in an identifier for IoT was that it would already be in use to identify devices. That is why Steve Springett suggested the GS1 standards, which the world knows because they include standards for barcodes (see pages 12-14 of the proposal); UPC is one of those standards. These are the primary standards used for commerce, for intelligent devices as well as many other products.

The big advantage of using these standards – specifically, GTIN and possibly GMN - is that, since they’re already so widely implemented, it should not be hard to learn the GTIN of a device you already have. It might be printed on the barcode label, but otherwise you can scan the FCC’s device cybersecurity label (which, in case you hadn’t guessed, will consist of a QR code attached to the device. It will take you to a website with the "label" information) – or else scan the barcode itself.

The disadvantage of using the GS1 standards is that, if a manufacturer doesn’t already have a barcode for their product, they will have to pay a fee to GS1 to obtain one (and perhaps to license its use annually). I would assume that’s a modest fee, but if a manufacturer can’t pay it, there would need to be some alternative way to assign the product a numeric code,

However, if the FCC decides to use the GS1 standards to identify IoT devices in the Device Registry, this means the registry can’t be based on the NVD, although it can certainly incorporate CVE data and CPE names from the NVD (as well as update them daily or even more frequently). And since there is no alternative vulnerability database for IoT devices, this means the FCC will need to develop their own, although probably with some help from interested third parties.

The FCC will also need to require that device manufacturers start taking steps they are seldom taking today (presumably, this would be a condition for receiving the label). More on that topic in a post that’s coming soon to a blog near you.

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.

 

No comments:

Post a Comment