More on “roadmap for the attacker”

In my most recent post, I discussed a frequently-heard objection to software bills of materials: They will furnish a “roadmap for the attacker”. In the post, I pointed out why I think this isn’t a valid objection.

This morning, I got an email from a friend who is (I believe) in charge of product security for a major software supplier to the electric power industry. His objection to my post was simple:

1.      My main refutation of the objection is that the bad guys can generate their own SBOMs, since it’s fairly easy to do if you have access to the software installation files (which I believe every customer of on-premises-installed software has).

2.      My friend pointed out that this vendor has very strict distribution control. He said “(Our) software has never been made available publicly, and our license agreement prevents our customers from providing our software to any third-parties.”

3.      In other words, the bad guys simply aren’t going to be able to get their grubby little hands on this supplier’s installation files. This, combined with their strict legal protections for those files, makes it (almost) impossible that they’ll be able to produce their own SBOMs, for this product.

My reply to him made two main points. The first is that my friend’s company is in a position that probably most suppliers (and certainly not Microsoft, Oracle, etc) are not in, so his objection doesn’t apply to them. The second point is that defense-in-depth considerations still dictate (IMHO) that they should produce SBOMs for their customers. Here is the body of my email to him, with a few edits to make it a little clearer:

It's correct that a customer would have to give the bad guys access to your installation files, or the bad guys would have to become a customer themselves, in order to make an SBOM. Perhaps for your organization, that's not a big problem, since your software is big-ticket and by the nature of what you do, you have lots of interaction with your customers. However, I think you are much more the exception than the rule in this regard. Certainly, Microsoft can't say the same thing (and they used to give out SBOMs in the SWID format with – I believe - all of their software. They recently stopped doing that, but I'm sure it wasn't for security reasons that they did so).

However, arguing that "if only" no customer shares installation files with a bad guy, there won't be any need for your customers to have SBOMs ignores the defense-in-depth principle. There are countless Maginot Lines that have been relied upon in the cybersecurity field, and they've all fallen (or will). For example:

1. "We're protected because we're completely isolated from the internet" - as I'm sure was assumed by the folks at the Natanz plant in Iran on the eve of Stuxnet destroying most of their centrifuges.
2. "We don't have to fear software that's been digitally signed by the supplier, if we trust the supplier" - as 18,000 SolarWinds customers were I'm sure thinking in early December of last year, before FireEye noticed a new device had been added to one of their accounts...

The attackers don't need SBOMs in order to attack software vulnerabilities that are due to components. They can simply use the WannaCry approach. They send out mass phishing emails that get them inside firewalls. Then they do a "spray and pray" attack where they hit every software product on the network with exploits for one or more vulnerabilities. Finally, they compromise that software, perhaps with a ransomware attack on the machine that it runs on. 

Having SBOMs will ultimately let software users know about vulnerabilities in components of a software product they use, as well as the vulnerabilities in the "first-party" code (which they know now, of course). This will let them deploy defenses that - assuming the supplier hasn't already patched the vulnerabilities - prevent exploitation of those vulnerabilities. So not producing an SBOM doesn't secure your customers - just the opposite. It removes a key part of a defense-in-depth approach to software component vulnerabilities.

I hope you'll participate in at least the public meetings of the PoC, since that's where issues like this one will be debated. 

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.