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