One of my biggest eye-opening
experiences of 2022 was when Tom Pace of NetRise described to the SBOM Forum (a
group I lead) a maker of networking devices used by the military and critical
infrastructure, which has never reported a single vulnerability for any of
their devices – so naturally, a search on one of their devices in the NVD will
leave many users with the impression that their devices are all vulnerability-free!
Unfortunately, the reality
is different: Just a single device that Tom’s company examined likely had at
least 40,000 unpatched vulnerabilities in components included in the device’s
firmware. Of course, I was full of righteous indignation at this supplier
(whose website doesn’t even mention “security” or “vulnerability”). How dare
they shirk their obligation to report vulnerabilities to CVE.org (which is where the NVD, as well as any
other database that uses CVEs, learns about its vulnerabilities)? After all, I’m
sure (or was sure at the time) that all major intelligent device manufacturers
(and software developers) diligently report all their vulnerabilities to
CVE.org.
Since a lot of people who work
with vulnerabilities all the time don’t understand how they get into a vulnerability
database (and I didn’t, until about a year ago), I’ll give a brief summary:
1.
CVE.org is part
of DHS and is funded by CISA. It is staffed by the MITRE Corporation and used
to be known just as “MITRE”. However, it is now run by an independent board
which includes representatives of private organizations, CISA, NIST (which runs
the NVD), and MITRE.
2.
New
vulnerabilities are usually identified by the developer of a software product
in their own software. If the developer is what’s known as a CNA (see the
CVE.org website for a discussion of CNAs), they will be able to write up the
CVE report and submit it to CVE.org. If they aren’t a CNA – and only about 200
organizations are CNAs; becoming a CNA requires training – they can go to a CNA
for help if the CNA’s “scope” includes them. For example, Red Hat (a
longstanding CNA) will help any open source project (I believe); GitHub will
help any GitHub project; there are country- and industry-specific CNAs; etc.
3.
If a developer
that wants to report a new vulnerability doesn’t think that their organization
can be served by any of the CNAs, they can always approach MITRE directly
(through CVE.org, of course), since they are the “CNA of last resort”. The CNA
will help the developer (or device manufacturer) create the CVE report. The
report will include information on the affected product, but not a CPE name;
that name will be assigned by the NIST people later.
4.
The report is
submitted to CVE.org and if approved, it will be passed to the NVD, where it
automatically becomes part of the database. Around 20,000 new CVEs were identified
in 2022.
5.
When the CVE
report reaches the NVD, someone on the NIST team that runs the NVD will assign a
CPE name to the product. Unfortunately, they don’t always do it correctly and
the product becomes hard (if not impossible) to find in the NVD; the developer
is left to apologize to their customers for NIST’s mistake. One of the changes
the SBOM Forum has discussed with NIST is allowing the developer to assign the
CPE name themselves.
Currently, there won’t be a CPE
name for any product for which a CVE report hasn’t been submitted; that is,
NIST currently only creates a CPE name when a vulnerability is reported for the
product. This in itself wouldn’t be terrible were it not for the fact that,
when a user creates a CPE name (following the specification) for a product they
want to learn about and enters it on the search bar, they will receive the same
message - “There are 0 matching records” - if no CPE exists with that name
(which will be the case if the manufacturer has never reported a vulnerability for it, or if the NIST person made a mistake when they created it)
as they will if the name is valid, but there are no vulnerabilities reported
for it.
In other words, the user will
have no way of knowing whether the product really has no vulnerabilities (and has
a correct CPE name) or whether it has 40,000 vulnerabilities, but was entered
under an incorrect CPE name.
(now, back to our regular
programming) When I heard Tom Pace’s
presentation last year, I initially thought that intelligent device
manufacturers – at least the larger ones (including manufacturers of IoT, IIoT,
medical devices, networking devices, etc.) - generally do a decent job
reporting vulnerabilities in their devices, since I believe that’s the case for
software developers. The main evidence that software developers are doing a
good job is the number of software vulnerabilities that can be found in the NVD.
Aren’t device manufacturers doing the same thing?
Some are. For example, when I just
searched the NVD for “Cisco ASA” (Cisco’s firewall appliance), I received 581
CPE names for different models, different versions, etc. This means that Cisco™
has reported at least one vulnerability against each of these CPE names. Of
course, the CPE name refers to “adaptive security appliance software”, not the
device itself.
And this is how I think
vulnerabilities should be reported for devices. They should be reported for the
device’s software (and firmware) as a whole, not according to the individual software
or firmware products installed in the device (since most devices include at
least some third-party software, not just software developed by the
manufacturer itself). If instead, vulnerabilities are only reported for the
individual third-party products, then the only way someone will be able to
learn about vulnerabilities in a particular device is to a) be a customer, b)
receive a current SBOM that lists all the software in the device (and I know of
no device manufacturer that is regularly releasing SBOMs to its customers. BTW,
the new
FDA requirement is unlikely to change that), and c) go through the work of
looking up each of the third party products in the NVD – based on the infinitesimal-to-faint
hope that the supplier of each of those third party products is diligently
reporting its vulnerabilities.
This week, I was quite happy when
I got a chance to have a one-on-one conversation with someone I’ve known for
three years, who is involved with product security for medical devices made by
one of the largest medical device makers (known as “MDMs” in the industry). One
of the many questions I asked him was how often they report a vulnerability for
one of their devices.
I wasn’t expecting him to say they
report vulnerabilities all the time, but I didn’t expect the answer I received:
that they have never reported a vulnerability for any of their devices, and he
isn’t even sure how to report one.
He justified that answer by saying
– and I believe him – that they have never found a vulnerability that they didn’t
patch, so their products haven’t had vulnerabilities. But here he was simply
wrong. Few if any software developers or device manufacturers would ever report
a vulnerability unless they had a patch for it. The normal procedure is that
the developer discovers the vulnerability, develops the patch, then submits a
CVE report (and usually a report to their customers) that lists the vulnerability but also provides information that
allows the user to find the patch and apply it. If the MDM doesn’t submit
anything to CVE.org, nobody will be able to learn of the vulnerability.
If this were a standalone software
product, not a device, there would be no question that the developer needs to report
the vulnerability (as well as the patch), both to CVE.org and to their
customers, since the customers need to apply the patch ASAP. However, usually
there is no way for the customer to patch a device they utilize; instead, the
supplier needs to do that.
Of course, if suppliers patched
vulnerabilities as soon as they appeared in the device (or at least the serious
vulnerabilities), there wouldn’t be any problem. I realized that this idea is
unrealistic, since device manufacturers can’t be expected to push out each
patch the day they create it. I assumed they push out monthly updates – which is
probably frequent enough to catch all but the most severely exploited
vulnerabilities before the bad guys can get into the device.
However, I asked my friend how
often they update their devices, and was amazed to hear it was usually once a
year. In other words, even if the manufacturer develops a patch for a vulnerability
the minute after they learn of it, their users will never benefit from that
patch for an average of six months. Even worse, since the manufacturer doesn’t report the vulnerability to the NVD (and presumably not to their
customers either), I’m betting that the customers wouldn’t be pleased as punch
to learn there was an important vulnerability in the device they rely on, but
it won’t be fixed for six months (and remember: the devices my friend secures are
used for sometimes life-sustaining patient care. They’re not baby monitors). In addition, no organization considering buying the product will be able to learn about this unpatched vulnerability before they buy it.
I’ll stop here and let you
contemplate this situation. By the way, do you or a loved one have any surgery
scheduled? Just wondering.
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.
No comments:
Post a Comment