In the past couple of months, it
seems events have been conspiring to tell me two things:
1.
Security in almost all
types of intelligent devices is in terrible shape and borders on being
nonexistent. However,
2.
Even if you want to
take security matters for a device into your own hands (e.g., do your own
vulnerability management), you’re going to have a hard time doing that.
The first event was when I wrote
this post, which reported that a person involved in product security
for a major medical device maker told me he had never reported a vulnerability
for one of their devices, and in fact he wouldn’t know how to report one. Since
most CVE reports (which form the basis for all listings in the NVD and the
great majority of them in other vulnerability databases) are created by the
developer of the product reporting the vulnerability (either a software product
or an intelligent device), this probably means that none of that company’s
products lists any vulnerabilities in the NVD.
In fact, since a CPE name is only
created when a vulnerability is reported for a product (more correctly, a
particular version of a product), this probably means nothing will be found
when someone searches for that product in the NVD. This isn’t good, but it’s made
worse by the fact that the message that displays when that happens is “There
are 0 matching records.” This is the same message that displays when there
is a CPE name for the product, but there aren’t any vulnerabilities
reported against the product. In other words, a user that searches on a product
and receives that message should either be elated that it’s a
“vulnerability-free” product or worried that it might be loaded with
vulnerabilities, but the supplier of the product doesn’t report them. How do you
tell which is the correct conclusion to draw? Perhaps a coin flip?
My friend defended the fact that
his company doesn’t report product vulnerabilities by saying they would only
report a vulnerability if they had patched it. This would be comforting, if we were talking about a software product, and the developer would normally quickly release a patch for a serious vulnerability.
But that's not how devices work. The user can't apply a patch themselves. They have to wait for the supplier to issue an update that includes the patch fix. And since releasing a device update requires a lot of work, device makers usually hold patches until they can be included with the next update. Even that wouldn't be terrible, if the device maker released an update every month (which I had naively assumed was the case).
But my friend said his company only releases an update for their devices (which are medical devices, remember. They aren’t baby monitors or recipe servers) once a year. This changes everything. Let’s say a device manufacturer discovers a serious vulnerability in one of their devices the day after they released their annual update. Assuming they’re on an annual update schedule, this means the vulnerability won’t be patched in the field for 364 days.
Will the manufacturer let their
customers know about this serious vulnerability and the fact that it won’t be
fixed in the device they use for another 364 days – so they can at least apply
some alternative mitigation to the device, even perhaps pulling it from their
network altogether? If they’re like my friend’s company, the answer seems to be
no. My friend said they won’t issue a notification for the vulnerability until it’s
patched in the field. Where does that leave their customers if they’re attacked
using that vulnerability during those 364 days? The answer seems to be "SOL".
I believe that an intelligent devicee manufacturer needs to promptly report vulnerabilities for the third-party software and firmware
products included in their device, as well as for the code in the device that
they wrote themselves (the first-party software). Moreover, they need to report
all these vulnerabilities as applicable to a CPE that identifies the device, not to one of the
myriad software or firmware products contained in the device.
The reason for doing this is
obvious (to everyone except the device manufacturers, it seems): Just like for
a “standalone” software product, the customer of an intelligent device needs to
be able to learn about all the vulnerabilities in their device in a single
search. Even if they have a current SBOM for the device (a dubious assumption
today, to be sure), they shouldn’t have to invest all the time and effort required
to look up each of those products in a vulnerability database (assuming they
even have a searchable identifier, which means a purl or CPE). The supplier
should be tracking all vulnerabilities for third- and first-party software and
firmware in their device, and posting them all to the single CPE for the version
of the device where those vulnerabilities are found.
What about the fact that a lot of
the vulnerabilities that a manufacturer learns about (in a vulnerability
database like the NVD) for the individual software and firmware products installed
in their device won’t in fact be exploitable in the device itself – so they don’t
actually pose a risk to their customers? Should the supplier still report every
vulnerability regardless of its exploitability status, and then issue VEX information
to let their customer know which of those vulnerabilities aren’t exploitable?
Were there any low cost, easy-to-use
and commercially supported tools available for software users, which would use
VEX information to narrow down a list of vulnerabilities in a particular
product/version to just the exploitable ones, I would say by all means, that’s
the way to do it. However, given that this is far from being the case, I’m
willing to concede that the manufacturer can apply the exploitability
information on their own and just report the small percentage of component
vulnerabilities that are exploitable in their device, not the huge number (usually around twenty times the number of exploitable vulnerabilities)
that aren’t exploitable. That will at least make the job much more manageable.
However, another thing that device
suppliers need to do is provide much more regular updates to their devices. Quarterly
updates would be a big improvement over annual ones, so maybe that’s what they
should aim for today. But the manufacturers also need to let their customers
know about serious new vulnerabilities in their devices and not wait until
the next device update to do this. That way, if a customer wants to implement
an alternative mitigation during the time remaining before the next update, they’ll
be able to do this (the manufacturer should suggest alternative mitigations in
their vulnerability report).
At the end of his recent presentation to
the SBOM Forum, Tom Pace of NetRise admitted that, given the large number of vulnerabilities
that are likely to be found in most intelligent devices (as he pointed out to
our group last
year, he examined one device – that had no vulnerabilities reported for it
in the NVD – that very likely had at least 40,000 unpatched
vulnerabilities), it was unrealistic to expect the manufacturer to be able to quickly
patch all the vulnerabilities in the device; they will need to figure out a way
to triage the vulnerabilities (using perhaps EPSS score or KEV ranking) and
patch the most important ones first.
But he did point out that some device
manufacturers have an alternative strategy for reducing the number of vulnerabilities
they’ve found in their devices, without having to patch them at all. He showed us
a message his company had received when they tried to follow up on a previous
notification to a manufacturer about a serious vulnerability they’d identified
in one of their devices. It read, “Your message to security@(manufacturername).com
has been blocked.”
Yep, that’ll do the job, too. And it’s
a lot cheaper than patching. 😊
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