As hackers become savvier, they’re beginning to see the benefits of exploiting the software supply chain by going after the weakest link in that chain. Guarding against supply chain attacks can be difficult because the majority of software produced today is not written from scratch, but rather cobbled together from existing software components or libraries. One way to help mitigate this problem is by using software bills of materials (SBOMs). These are ingredient or itemized lists of the components that make up a software application.
President Joe Biden’s recent executive order on cybersecurity pushed for mandatory SBOMs to help guard against supply chain attacks, like the ones that hit SolarWinds or software supplier Kaseya, but what impact can they really have? Eric Byres, an award-winning expert in the field of industrial control system (ICS) and operational technology (OT) security and CTO of aDolus Technology, said they’re a good place to start, and the U.S. government understands that.
The executive order mandated the U.S. National Telecommunications and Information Agency (NTIA) produce a list of what the standards and the minimum elements of SBOMS should be. When they put that out in June, Byres said, it laid out the entire format for SBOMs, both in how to produce them and how to read them. This could be useful to ICS vendors and asset owners who are still figuring out the value of SBOMs.
“We haven’t even thought about half the things that SBOMs can be used for and why companies will want to know [about them],” Byres said. “For example, in the last couple of weeks, we’ve been getting a lot of phone calls from our clients wanting to know country of origin information about components that they have bought. They know that they bought a PLC (programmable logic controller) from Vendor X, which is based, say, in Europe, but where are the software components coming from? Are they coming from a nation-state that is not somebody they want to have supplying software to them?”
The can of soup
That basic information — Who produced the components? What is their country of origin? Who was involved? — is a simple use case for SBOMs. At their roots, SBOMs are supposed to inform people about all the components in a software package. With that knowledge, asset owners can then make informed decisions about the products they’re purchasing and determine which vulnerabilities they have. It’s essential to know whether components could potentially harbor malware or if they actually come from where they say they’re from.
“Most companies don’t know about hundreds of vulnerabilities that are sitting on their plant floor.”
“Is that component that you think came from Rockwell Automation actually from Rockwell Automation, or is it from North Korea?” Byres said. “These are things that we just generally haven’t known until we had SBOMs.
“I’ll tie it back to my favorite analogy, the can of soup. When we go and we look at the ingredients on a can of soup — or when I do it in the store — there’s lots of information there. And then I might be looking for particular ingredients that are of concern to me. My daughter-in-law is allergic to peanuts, so I’ll be looking for peanuts. Are there any peanuts in this soup, yes or no? And that’s the same sort of thing that asset owners can start to do once they understand what are the components in a package. [They can] say, ‘OK, which of these components pose a risk to my operations?’”
Without an SBOM, even a company that thinks it’s doing a good job with its updates and patches might be missing something. If they don’t know all the components that go into a piece of software, they don’t know the breadth of the vulnerabilities they should be trying to match or patch.
“What we’re discovering is that most companies don’t know about hundreds of vulnerabilities that are sitting on their plant floor,” Byres said. “I analyzed a remote terminal unit (RTU) a little while ago using our tools, and I was expecting to find half a dozen potential vulnerabilities. At 200 and counting, I started to overload our system. And this applies to whoever’s using that RTU. In this case, the RTU was coming from a large Midwestern pipeline, and they had no idea that they were sitting on literally a minefield of vulnerabilities. Some of these could be exploited, and some of them couldn’t be.”
Byres cited the example of QNX, an operating system that had several undisclosed vulnerabilities that were recently disclosed. He said “the bad guys” probably knew of those vulnerabilities for a long time, but many people on the plant floor had no idea if they were running QNX or not. And if they don’t know QNX is part of a system they’ve purchased, they are essentially flying blind.
“Until we start to empower the plant floor people and the companies to really understand what they’ve bought, we’re going to be on the back foot against the attackers,” Byres said. “The attackers can figure this out pretty quickly. ‘Oh, yeah, that controller there, it’s using such and such operating system. These are the vulnerabilities against it. They came from this supplier. It’s got this component for its particular functionality.’ And then they have just the absolute perfect shopping list for attacks. The vendor, on the other hand, is lacking a roadmap.”
How to use SBOMs
There are many benefits to SBOMs, but most companies initially use them for tracking vulnerabilities and getting a better understanding of what they’re exposed to. It’s easy to buy an ICS product and not see any vulnerabilities listed in the national vulnerability database. Underneath, however, the product could be full of vulnerabilities, depending on the components the manufacturer used.
“Unfortunately, the SBOMs are going to make an already bad situation probably worse in the short term.”
Byres said some vendors are now leveraging SBOMs to determine if they’re susceptible to technical support problems because antivirus software can flag their product as malware. For example, a new legitimate product will get released, but because some component looks a bit suspicious, antivirus software will start sending out alarms. That can be difficult on asset owners and vendors, who end up wasting time chasing problems that don’t exist.
“If you can analyze the components and say, ‘Hey, yeah, this component is likely to trigger antivirus,’ you’re starting to get ahead of the problem,” Byres said.
To maintain any semblance of cybersecurity, it’s essential to understand not just who your suppliers are, but who the sub-component suppliers are, as well. Are they trustworthy? Are they from a company you want to deal with? Are they from a country you want to deal with? These are all common use cases for SBOMs.
Good news, bad news
Vulnerability management can be a big headache for many companies. While SBOMs will help with this in the long run, the news isn’t as good for the immediate future.
“You are going to end up with an avalanche of vulnerabilities,” Byres said. “Unfortunately, the SBOMs are going to make an already bad situation probably worse in the short term. You’re going to get presented with more vulnerabilities.
“But I think there’s really good news on that front. Along with the NTIA’s efforts to standardize SBOMs, they’ve also standardized something called the Vulnerability Exploitability eXchange format. It is … basically is a machine-readable document that will allow companies to not just tell if there’s a vulnerability there, but how exploitable it is.”
This should allow people to focus on which vulnerabilities should be top of mind versus ones that are not mission-critical. To protect their systems, people need to think like hackers. That starts with understanding where the weak links in the supply chain are. SBOMs can provide visibility and help shine a light on the minutiae attackers have been watching for a long time.
In Part 1 of our interview with aDolus Technology’s Eric Byres, he discussed how to manage supply chain risk and what the government is doing to address this problem. And check out our Industrial Cybersecurity Pulse YouTube page to view previous installments from our expert interview series.