Cybersecurity Insights
- The supply chain is under attack, and many companies simply don’t know what’s in their software or what’s really running on their plant floor. A software bill of materials (SBOM) provides an itemized list of what’s in a piece of software so companies can better track their vulnerabilities.
- When an organization first starts using SBOMs, things are likely to get worse before they get better. The more you are looking for vulnerabilities, the more you’ll find. But they are a good way to prioritize vulnerabilities and fully understand your environment.
Recent events, such as the SolarWinds and Kaseya hacks, have proven that the software supply chain is not only at risk, it’s also under attack. One of the tools that can help protect the supply chain — a tool the federal government is recommending — is a software bill of materials, or SBOM. CFE spoke with leading experts for this week’s Industrial Cybersecurity Pulse Roundtable discussion about SBOMs and why things are likely to get worse (on the surface) before they get better.
Once again, joining Gary Cohen, senior editor of Industrial Cybersecurity Pulse, are Ron Brash, vice president of technical research and integrations at aDolus Technology; Eric Byres, chief technology officer (CTO) and a board member at aDolus Technology; and Dino Busalachi, CTO and co-founder of Velta Technology.
This discussion has been edited for clarity.
ICS Pulse: What is the role of SBOMs in protecting the supply chain? How much were they being used before, and how much can they help?
Ron Brash: [For] certain government agencies, there has been the equivalent of an SBOM in the past that isn’t called an SBOM, but it’s something along those lines. [It’s] an ingredient list. But from a general standpoint, I’ve almost never seen someone generate an SBOM for an embedded product or a Windows product up until relatively recently, within the last five [to} seven years. So that’s been a problem.
What should they be used for? I think of them as a general map. They tell you kind of the lay of the land from a block diagram perspective [and] what kind of pieces are in a product. Like looking at your car, you know it should have a steering wheel, [and] you should know it has four wheels. Do you know what those four wheel sizes are? Nope. Not really relevant at that point, but you know that there’s all these components in there. You know it’s a front-wheel drive or an all-wheel drive. You know those pieces. That, at least, is a very good start with what an SBOM should be used for.
Now, what should it also be used for? It’s a way for product security teams to know for legacy products or from acquisitions or divestations, what kind of things that are going to come bubbling up to the surface and haunt them later, or which things are going to get shown up as a vulnerability advisory later. They should have [an] action plan later to respond back and say, “No, just because you see that piece of software there, it’s not vulnerable.”
It is a very good indicator for groups to get a lay of the land. There’s, again, much more that. I think SBOMs actually have a really good place for asset owners in understanding what it is that they’re buying before they buy it. An SBOM might be a good way for organizations to see if they’re buying a product that’s reasonably high quality, [and has] enough security before it gets into their facility and begins degrading.
Dino Busalachi: But how do you keep it from being the wild wild West, again, referencing something [I experienced] just recently [with a Windows 10 machine that] had over 400 applications on it. You’re talking about a machine that’s sitting down inside the OT (operational technology) environment. It’s acting as an HMI (human machine interface) and an engineering workstation with 400 applications. Why? I mean, really, why? It only does a couple things, right? So the key there is how do you keep it that way once you get it that way. Again, it gets back to the inventory. If you don’t know what’s out there, it’s like, why don’t you unload 350 of these applications because there’s no reason for them to be on this machine? But it’s like that though. It’s like the wild wild West in a lot of cases in some of these environments.
We predominantly focus on the mid-tier manufacturer. We’re trying not to chase the large enterprise guys that have the resources and skills and in-depth in the organization to do some of this research and to own these critical key roles that you guys are describing compared to somebody who’s just trying to make paper board for wallpaper 24/7, 365, nonstop. Because they’re printing money. That’s all they’re thinking about is making paper board for wallpaper, but they want to secure their environment. They know they need to do that, and you only got one guy.
Eric Byres: I think going to what you said Dino about the demand on the resources is where we really need to focus and where the security industry has made its mistakes. What we need to do is make security simpler. If you just look at an SBOM, you’ll go, “Oh no, this is going to get more complicated.” But, honestly, I think the SBOMs, and the things like VEX and CSAF and the standards that are associated to it, are really designed to take that unreasonable workload off the backs of people on the platform and automate that. A good example, I just was on a call this morning with the German Standards Institute, and they were talking about how they’ve been working a lot on vulnerability standards documents that are machine readable because a very responsible, good vendor will spend a lot of time building this really nice, pretty PDF that announces that they’ve got a vulnerability, and it’s all got this wonderful text and somebody’s got to read that.
And here’s a five-page document, and your poor engineer, first thing on a Monday morning, is reading a stack of these things. Nothing’s getting done. I think what’s really critical is we make those not as a pretty PDF, but start to use technologies and standards like CSAF, VEX and SBOMs — the standard SBOMs formats that have been approved — and make this automated so it’s not about trying to decide, “Does this vulnerability apply to my plant?” That’s not a human decision. It’s, hey, you use these products, they have these components, their vulnerability is announced for these components. They are exploitable in your product. You need to care. Or your product uses this component. It’s got a vulnerability, but it’s not exploitable, so go back to sleep and focus on something else that matters in your plant. That is what I really hope happens. It’s what Ron and I spend just about all our time on is, how do we make this so security is easy to do, and we do the right thing by default, not by making things more and more complicated.
ICSP: Eric, you and I had a conversation a little while ago about SBOMs, and you said at first companies are going to have an avalanche of vulnerabilities. The more they look, the more they’ll find. Sometimes things have to get worse before they can get better.
Byres: Yea, absolutely. I want to be really clear: The avalanche of vulnerabilities is a problem when they’re just all vulnerabilities with no idea if they actually apply to you or not, or if they’re actually exploitable. What you want to do is find those very nasty, pointy needles in that haystack and deal with those so they don’t poke you when you’re not looking.
Busalachi: One of the outcomes from the work that we do, we create what we call a connected device index. It’s CDBI. It’s just to give you that look at the vulnerabilities and exposures that you have, not only per asset but also the critical ones, where you might want to say anything that has a stack buffer overflow vulnerability, you should go after and fix. Some of these other things, remote code execution and pointer errors and things along those lines, we need to push those down. We actually create an index, which is like a FICO score. How do you get a FICO score into somebody’s hands to show them where they are today, currently, right now in real time, so they can have a measuring stick to see how they can improve over time with measurable information and metrics.
I think that’s one of the things that’s key to this that’s been missing. We find it to be very valuable for folks to have that information at their fingertips so they can show that to their executive teams and go after the money that they’re looking for and be able to tell the insurance companies, “Here’s our risk. Here’s where we’re at. Here’s what we’re focused on.” Right now, a lot of them don’t even have a good idea of what’s out there running in space. They just don’t know. I mean, they’ve been out there. They’ve got Windows 7 machines, for God’s sake. They’ve been around for a couple of decades, and the same thing with PLCs (programmable logic controllers). They’ve been out there for three decades, and [with] mergers and acquisitions and the people that have changed hands, they just don’t know what they don’t know.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
