“Weaponized” coffee makers?

This morning, I had a conversation with Tim Walsh of the Mayo Clinic, one of my “TEAMS friends” from the SBOM community (Tim was one of the original members of the Software Component Transparency Initiative and is still quite active in the group).

He mentioned that the Mayo Clinic has several hundred thousand devices on their network (the average hospital room has 13 networked devices), and he would love to have SBOMs for all of them. But he’s not just talking about infusion pumps and heart monitors. He’s talking about coffee makers and vending machines, since they’re all network connected now. He pointed out that a huge percentage of devices have at least some possibility of code written in Java, and that those are all very likely to have log4j, since that’s the fastest and easiest way to implement logging in that environment (it’s also free, of course).

So even though a hack of an infusion pump poses a direct threat to patient safety and a hack of a coffee maker doesn’t, hacking into a coffee maker can give the attacker a platform from which to attack lots of other devices that can affect patient safety (or the financial health of the hospital, of course). I don’t know if Tim has started patching the coffee makers yet, but he’s at least going to watch them for signs of compromise.

Of course, widespread availability of SBOMs would have saved a lot of IT people a lot of time since log4j came out. Since they’re not widely available now, this means that users have to hear from the software suppliers about whether or not they have any log4j in their product. And Tim pointed out that Mayo didn’t wait to hear from the suppliers; they’re patching all of the devices now, on the assumption that they’re all affected until proven otherwise.

This means that what’s just as important as a supplier notification that their product is affected by log4j is a notification that their product isn’t affected by it – so people like Tim don’t have to preemptively patch it. This is why I was quite pleased to see the notification today from Fortress Information Security that their three main software products aren’t affected by either of the log4j vulnerabilities.

Not only did they provide this notification in a blog post, but they also attached a VEX for each of the products. While these won’t do you any direct good at the moment, since tools aren’t available to read the VEX format (and the format is still being worked out), it’s interesting to see them, nonetheless.

I certainly recommend that other software suppliers provide a similar notification to their customers for every product of theirs that isn’t affected by log4j. You’ll be saving them a lot of unnecessary work. In fact, you might go further than that and point out the module that’s affected (log4j-core). So if that module isn’t present in the product, they don’t need to worry.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. Nor are they necessarily shared by CISA’s Software Component Transparency Initiative, for which I volunteer as co-leader of the Energy SBOM Proof of Concept. 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.