Thursday, August 24, 2023

“British cuisine”, “Device security”, and other oxymorons

 

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