In case you haven’t noticed, I’ve
written a lot about software supply chain security in the past couple of years.
I’ve focused on this topic because that’s where some of the biggest cybersecurity
attacks have appeared. SolarWinds, Kaseya, Log4j, ransomware in general, etc. were
(and are, since none of them have ended yet) all software supply chain attacks,
or at least incidents.
However, even though software currently
poses the biggest supply chain security threat (and certainly one of the two or
three biggest cybersecurity threats in general), I think there’s ultimately a
much bigger threat which we’re just beginning to deal with now: the supply
chain of intelligent devices. This includes devices that have been sold for
specialized purposes – electronic relays in electric power substations,
infusion pumps and heart monitors in hospitals, controllers of all sorts in
factories, networking equipment like firewalls and switches, etc. But it also
includes a lot of devices used for much more pedestrian purposes, including
security cameras and even baby monitors.
I first realized how much greater the
risks are with devices through a presentation (and follow up discussions) by Tom
Pace of NetRise to the SBOM Forum this spring. I wrote about the presentation
itself in this post; I followed it up with 3-4 further posts. The most relevant
of those further posts to our current discussion is this
one.
NetRise specializes in firmware
security, so obviously devices are their main concern. Tom’s initial
presentation discussed a network device that, believe it or not, is used in
critical infrastructure environments, including the US military. In his original
presentation, he noted that he had identified, through analyzing the components
of firmware in the device, at least 1,237 unpatched vulnerabilities; however,
he was sure there were more. In the second post linked above, I noted he had
later told me he was now sure there were at least 40,000 unpatched software
and firmware vulnerabilities in that one device, which (using a general
guesstimate of 5% of component vulnerabilities being exploitable) probably
includes 2,000 exploitable vulnerabilities.
Of course, I doubt you’ve ever
heard of a software product with 2,000 unpatched exploitable vulnerabilities; I
certainly haven’t. How could there be so many in one device? For one thing, the
device contains lots of software and firmware products. But I’m sure we’re
talking about 50-100 products, not 1,000. This would still mean there are at
least 20 exploitable vulnerabilities per product. A software product with 20
unpatched vulnerabilities would meet a lot of resistance. How is it that a
device can have 2,000 vulnerabilities and still be on US military purchase
lists?
The clue to this miracle is
revealed in both of the posts: The manufacturer of this device has never
reported a single vulnerability for it. In fact, the manufacturer has never
reported a vulnerability for any of the 50-odd devices it sells. If this were a
software product, anyone could scan it and discover at least some of these
vulnerabilities. The software supplier would never get away with not reporting
any vulnerabilities at all.
But the situation is quite
different for a device. It’s a sealed box. The end user can’t even find out
what software is in the box, let alone scan it for vulnerabilities. It would
certainly help to have a software bill of materials (SBOM) for the device, but
– other than a small number of medical device makers, who are facing a
mandatory requirement to provide SBOMs to their customers later this year – I
have never heard of a device manufacturer that regularly distributes SBOMs to
users.
In fact, I know of one key device
manufacturer, that sells into an important critical infrastructure industry and
has a huge market share, that seems to be actively campaigning against SBOMs.
They’ve pulled out the old chestnuts about “roadmap
for the attacker”, etc. I always used to have a
high opinion of this company for their cybersecurity posture (which is otherwise
exemplary), but having seen – and experienced in online and phone conversations
– their opposition to SBOMs, I honestly have to wonder: What are they hiding? I
sure hope it’s not 40,000 unpatched vulnerabilities in one product.
A few months ago, I and Isaac
Dangana of Red Alert Labs published an article in the Journal of Innovation. It noted that, when
it comes to vulnerability management for intelligent devices, the device
manufacturers hold all the cards. The user can’t usually even learn what
software is installed in the device. The manufacturer normally distributes all
updates, for all software and firmware in the device, in a single “lump”. When
the update gets applied (often “over the air”, without the user being involved
at all), the user has no control over what products are patched or not patched;
whatever is in the lump gets applied, or else nothing gets applied.
In our recommendations at the end
of the article, Isaac and I said that device manufacturers should distribute an
SBOM whenever they update the software and firmware in their device. But that
wasn’t the most important recommendation, which was that the manufacturer needs
to register the device as a single product and report any vulnerabilities in
any of the software in the device to that single product.
The way that would work today is:
1.
The manufacturer obtains
a CPE name for the device from CVE.org (aka MITRE Corp.). This would normally
be done when reporting a CVE (vulnerability) as applicable to the device, but I
believe it can be done even before a CVE is reported.
2.
Whenever the
manufacturer learns that a CVE is applicable to (i.e., exploitable in) any of
the software or firmware products included in the device, they will report this
to CVE.org. If the supplier of the individual software product hasn’t reported themselves
that their software product has this vulnerability (meaning that an NVD search
on the product name and version would uncover the CVE), then the device
manufacturer might do that themselves.
3.
However, it’s not too
important whether or not the manufacturer reports that the individual software
product is vulnerable. What is important is that they report the
vulnerability as applicable to the device – i.e. the device’s CPE name. That
way, a user of the device will simply have to enter the CPE name in the NVD, in
order to see all reported CVEs for any of the software or firmware in the
device.
4.
As an aside, I’d like
to note that, when the proposal regarding product naming in the NVD is implemented - which
the SBOM Forum released recently – there will be no need to use CPE names with the
NVD (although that will still be an option). Instead, hardware devices will be
identifiable using their GTIN number, which is a set of international standards
for naming intelligent devices. One of the GTIN standards is UPC, meaning that,
in order to search for a device in the NVD, the user will just need to scan the
UPC barcode on their device. Any applicable CVEs should appear immediately (or
the user could enter the UPC code manually, which wouldn’t be too hard. The
point is that there should be no need to search for the product in the
hit-or-miss fashion that NVD users know and love today[i]).
In other words, in order for intelligent
device users to realistically be able to manage vulnerabilities in devices, the
device needs to be listed in the NVD and any CVEs that are applicable to any
software or firmware product included in the device need to be listed as
applicable to the device itself. I’ll admit that this won’t be an easy policy
to sell to the manufacturers. And while, as a former student of Milton
Friedman, I don’t like to see government regulation used in cases where it isn’t
absolutely necessary, in this case it may be. Which do you want with your IoT
device: 40,000 unpatched vulnerabilities or government regulations?
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] The
hardware portion of the SBOM Forum’s proposal will probably take more than a
year to be implemented, once the proposal itself (or at least its main points)
is approved by CISA. The software portion of the proposal will be implemented
much quicker, since no linking of databases is required.
No comments:
Post a Comment