The big problem with securing devices

Starting in 2017, the FDA has said they intend to require SBOMs for medical devices. Early this year, they released a draft requirement for comment, saying they planned to finalize a requirement and make it mandatory by the end of the year.

However, a few weeks ago, I heard in one of the bi-weekly meetings for the Healthcare SBOM Proof of Concept (which is now conducted under the auspices of the Healthcare ISAC) that the FDA had just announced they were going to postpone enforcement of the requirement until late next year (and moreover, that they weren’t going to allow any changes to the draft requirements, even though they…ahem!...left a lot to be desired). Of course, this was disappointing, since there was a lot of agreement (including among medical device makers) that it’s important to have the SBOM requirement.

But, in the CISA SBOM Onramps and Adoption workgroup meeting this week, Josh Corman announced that the Patch Act had been passed last week in the year-end rush of legislation. This is a piece of legislation that requires the FDA to mandate cyber protections for medical devices. It had initially shown promise of being passed, but was withdrawn without a vote earlier this year. The FDA has 30 days to complete the rulemaking for this (and I hope they’ll change what they proposed last April), which seems to indicate it’s on a fast track to implementation. While the Act doesn’t specifically mandate SBOMs, it lists them as one of the measures that might be required, and the word is they will be required.

This is important for two reasons. One is that this will be the first mandatory requirement for SBOMs anywhere in the world (at least as far as I know). Of course, nobody is advocating such a mandatory requirement for every software product and device in every industry, but there are certain cases where mandatory SBOMs are justified. I would say that medical devices, which literally keep people alive in hospitals, are one of the best of those cases.

However, in my opinion the second reason is even more compelling: It’s that intelligent devices in general, not just medical devices, pose a unique cybersecurity challenge; SBOMs can play a key role in addressing that challenge.

I had never stumbled upon that challenge before I and Isaac Dangana, who works for my client Red Alert Labs (a company based in Paris that focuses on security and compliance for IoT devices), published this article in the Journal of Innovation last summer. While that article was primarily intended to be an introduction to SBOMs for people in the IoT and IIoT worlds who weren’t familiar with the concept, Isaac and I ended up pointing to a serious issue that affects the ability of a user to secure an IoT or IIoT device, or even to learn about vulnerabilities that may affect it. In fact, we ended up making the case – without intending to – that IoT and IIoT devices may currently be less secure, and are certainly much less transparent to users, than are “user-managed” software products (i.e. standard software running on Intel-standard servers).

The problem begins with the fact that IoT and IIoT devices are intentionally sealed. The results of this include the fact that users can’t identify by themselves the software products installed in the device, and they can’t update or patch any of the individual software packages in the device.

Instead, all the software in the device is treated as a single “lump” (to quote a friend who manages cybersecurity for the thousands of medical devices installed at a large hospital chain). The device comes with all the required software installed, and patches or updates to individual software products in the device are held until the next scheduled device update – at which point the entire “lump” is replaced as a unit, often at night via an internet connection.

Of course, for a network administrator who runs him or herself ragged, trying to keep up with vulnerabilities found in the hodgepodge of software products running on the servers they’re responsible for - as well as trying to apply the never-ending stream of patches to software products installed on those servers - the idea that all responsibility for vulnerability management and patching would be completely taken out of their hands and assigned to some gremlins that expect neither pay nor recognition must seem like heaven on earth.

However, this is only heaven on earth if the device user has complete confidence that the device manufacturer will:

a)      Monitor each software product installed in the device for vulnerabilities and “coordinate with” (i.e. bug the hell out of) the software product’s supplier to make sure they expeditiously patch any serious vulnerabilities in it.

b)     Require the supplier of at least every “top level” software product installed in the device to provide an SBOM for their software and update the SBOM whenever they release an update or patch for that software.

c)      Using the SBOMs, track components in each of the software products installed in the device and identify vulnerabilities applicable to each component.

d)     Require each software supplier to provide VEX notifications, which will let them know about component vulnerabilities that aren’t in fact exploitable in the product and prevent their wasting a lot of time chasing down non-existent vulnerabilities.

e)     Whenever a serious vulnerability can’t be patched immediately, provide a notification to all the customers of the device regarding mitigations they should apply to make it less likely that the vulnerability will be used to compromise the device.

f)       If one of the software products installed in the device has proved to be a “problem child”, with multiple longstanding vulnerabilities and no commitment by the software’s supplier to fix those in anything less than the remaining life of the universe, commit to replacing that software within say three months.

g)      When a software product has reached end of life status, commit to replacing it within say six months.

h)     When an open source software product hasn’t been patched or updated for say six months, admit that the product is effectively in end of life status and commit to replacing it within six months - although sooner if there are one or more serious unpatched vulnerabilities in the product.

i)       Require that the supplier of each software product installed in the device either attest they have followed every provision of the NIST Secure Software Development Framework (SSDF), or identify any provisions they haven’t followed and provide an explanation of why they haven’t done so.

j)       Etc., etc.

Of course, the device manufacturer is likely to complain lustily that they can’t stay in business if they’re really forced to do all of the above, with respect to every software or firmware product that’s installed in their device. And believe it or not, I agree that this is too much to ask of them.

However, by the same token, I say it’s too much to ask of their customers that they stay in Fat, Dumb and Happy mode, in total ignorance of any security measures that the device manufacturer took or didn’t take to secure the software within their device. If the manufacturer isn’t willing to do literally everything possible to secure the device (i.e., all of the items listed above), they should at least give their customers the information they need to learn about the measures they have taken, and express willingness to have a discussion with any customer who thinks there are measures the manufacturer should take but hasn’t.

What is the information the end user should have about the device? First, they need at least a “one-level” SBOM, showing every software or firmware product installed directly in the device, along with whatever identifiers are required to look up the software in the NVD or another vulnerability database like OSS Index. If the customer has that much, they’ll be at the same point that most users of “user-managed” software find themselves at, with respect to the software installed on the servers they operate: They’ll know what software products are directly installed on each device (or on each server, in the case of user-managed software), and they’ll be able to investigate vulnerabilities found in those products.

But is that enough? After all, any server administrator today can identify every software product that’s installed on their servers using a tool like PowerShell or even Windows™ Explorer; then they can learn about vulnerabilities in those products by looking them up in the NVD or another vulnerability database. But they won’t learn about vulnerabilities caused by components of those software products if they don’t also have an SBOM for each product; then they can look up each component in the NVD, to learn about its vulnerabilities.

How will the server administrator get an SBOM for one of the user-managed software products? They’ll probably ask the software’s supplier for it, and they’re likely to get it, too (at least one SBOM, anyway). Why is the product’s supplier likely to give it to them? Because they’re a customer, of course.

However, if an IoT or IIoT device manufacturer gives a customer a first level SBOM for the device, the customer will just know the names of the software products installed in the device – the equivalent of what they could learn from running Windows Explorer on a standalone server. The IoT customer won’t know anything about components of those products, unless they have an SBOM from the supplier of each software product installed in the device.

At least, having a first level SBOM, the device customer will know the names of the software products installed in the device and their suppliers’ names. What will they hear when they contact those suppliers to ask for an SBOM? Most likely nothing at all, or perhaps “Get lost”. The problem is that the device customer isn’t a customer of the suppliers of the software installed in the device; the device manufacturer is. It’s very likely that only the manufacturer will be able to get the SBOMs, and perhaps not even them..

Thus, it isn’t likely that IoT or IIoT device customers will be able to obtain SBOMs for software products installed in intelligent devices they own or utilize. Of course, they can beg the device’s manufacturer to please, pretty please get the SBOMs for them – but I doubt that will be a very productive exercise.

But more generally, why should analysis of cyber risks found in intelligent devices be exclusively the responsibility of end users? After all, the manufacturer chose the “first level” software and firmware products that are installed in the device. It’s their job to make sure they’re secure; if they’re not, it’s the manufacturer’s responsibility either to get the supplier to fix vulnerabilities in their software, or to replace the software with a more reliable product.

But how can the device customer even “audit” the manufacturer’s performance in vulnerability management? If the customer receives an SBOM that lists the first-level software and firmware products installed in the device (which will hopefully start happening soon with medical devices), that at least puts the device customer on the same level as the server administrator that identifies each software product installed on their server using Windows Explorer: The device customer will usually be able to learn about vulnerabilities in those products, although they won’t learn about vulnerabilities found in the immediate components (dependencies) of those products.

However, why should the device customer even have to look up vulnerabilities in each of the “first-level” software and firmware products installed in the device? Each customer presumably has exactly the same set of software products installed in their device as any other customer does. If there are say 10,000 customers of a device, why should every one of them have to perform exactly the same set of steps to learn about vulnerabilities in the device, when the manufacturer can perform those steps for all 10,000 customers at once?

And not only can the manufacturer perform those steps themselves, but they should be performing them already. That is, they should be doing it, assuming they care about securing the devices they sell. For example, if there are say 15 software and firmware products directly installed in the device (there may be a lot more, of course), why can’t the manufacturer share with their customers every exploitable vulnerability associated with those products?

Besides reporting each vulnerability to their customers, the manufacturer also needs to register the device itself in the National Vulnerability Database (NVD) and report all exploitable vulnerabilities they identify in the device. This includes both vulnerabilities due to code written by the manufacturer and vulnerabilities due to code written by the suppliers of the third party software and firmware products installed in the device.

When device manufacturers start doing this, vulnerability management for intelligent devices, including medical devices, will be much easier. The customer will just have to search on the device’s CPE name in the NVD, in order to learn about all exploitable vulnerabilities in the device. This is what software users are supposed to be able to do now. Why shouldn’t device users be able to do the same thing?

I hope the FDA includes this in their device security requirements, along with requiring an SBOM for the device.

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.