Cybersecurity practitioners are beginning to get more visibility into systems, but visibility itself should never be the endgame. So how can organizations take those next crucial steps? The Industrial Cybersecurity Pulse Podcast recently sat down with Thomas Pace, CEO and co-founder at Netrise Inc., to discuss the prevalence of ransomware, the danger of supply chain attacks and how software bill of materials (SBOMs) can help secure systems.
Listen to the full podcast here, and you can read Part one of the transcript here and Part two here. The following was edited for clarity.
ICS Pulse: In this past few years, ransomware and ransomware-as-a-service have really proliferated. Do you think that will continue to be the primary attack vector this year, or do you think it will maybe shift to something a little bit different?
Tom Pace: Ransomware is a bigger problem in OT (operational technology) and ICS (industrial control systems) than it ever has been. That’s for sure. But when you say “ever has been,” it’s like, “What is that number?” That’s not a very big number. Even the Colonial Pipeline attack, that was not an attack against the OT environment. It was an attack that impacted the IT (information technology) environment’s billing system that then forced the pipeline to take down the OT environment. Otherwise, they basically would’ve went bankrupt, which obviously was a good decision even though it had a crazy impact.
That was the DarkSide Group, or whatever their name was. They actually came out, if you guys remember, and issued an apology, because they were like, “Hey, we didn’t know that this was this entity, or organization, or whatever.” The reason I bring all that up is, there’s this concept in nuclear weapons proliferation known as mutually assured destruction. I think it takes a special breed of crazy to go after OT and ICS devices with ransomware, in particular, because that’s a one-way street for a lot of these devices. Unlike in the IT world, where you can generally back up, restore, get things back online, that’s not really the set of circumstances you run into with OT and ICS. It’s not that it can’t happen. It’s not that it’s not an unbelievably insane risk. All of those things are obviously true. I don’t think there’s data to support it is really what it comes down to, at the end of the day.
If that is what actually starts to happen, I think that will lead to a set of activities that no one really wants to see happen. Now, there was that big research that came out recently about the first — was it the first POC, or RTU? — encrypted by a ransomware attack. That got destroyed by the industry pretty quickly. I do think that will still be a problem. Just taking things offline in a targeted way will probably generally still be what tends to happen.
ICSP: Are there any big cybersecurity stories that you expect to see in 2023? What’s your biggest concern going forward?
Pace: There’s a lot of analysis and data being generated around the software supply chain, but not a lot of “What now?” Meaning, people are getting visibility into things that haven’t been around in the last, let’s call it, four years. There’s a really big concept of software supply chain security, or software transparency has become a really big thing — SBOMs (software bill of materials), and all of that. I think one of the issues is, you have to start trying to solve this problem by providing visibility, of course, but getting visibility is only part of it.
The changes that are meant to come after visibility aren’t coming at the same pace. That, I think, is going to lend itself to some pretty interesting challenges. It’s like, “Here’s a bunch of problems, but we don’t have capital to solve all of them,” so that’s the issue we have here. That’s one of my big concerns is, these supply chain attacks are not going away, and they’re only going to probably get more prolific over time.
ICSP: You mentioned SBOMs. Those are one of the things that maybe can help against these supply chain attacks. What do you think the value of SBOMs is going forward? In supply chain attacks, how can they be used and used well?
Pace: I’ve given a handful of talks on this concept. I put up a picture of a PLC (programmable logic controller), and I put up a picture of a red wagon. We have a bill of materials for one of those things, but not the other. I’ll let you guys guess which one we have a bill of materials for.
ICSP: I’m guessing it’s the red wagon.
Pace: It is, indeed. Or it’s like, “Hey, I can tell you all of the ingredients that are in this can of SpaghettiOs, but I can’t tell you about all of the ingredients or software components in this router, or firewall, or security camera, or printer.” Why? It’s not because we can’t. It’s because we haven’t. I’m never going to be one of these people who ever claims that an SBOM is the cure for cancer. There are a lot of people out there making those claims, which frankly are just doing all of us a disservice, so stop. However it is, in my opinion, probably the best way.
By the way, if someone comes up with a better way and calls it something else, great. That’s what we’ll do. I don’t really care. But right now, with what is available, it seems to me that an SBOM is probably the best approach in terms of getting that kind of transparency and visibility into what exists, and what the risks of those things are that exist in devices, and software packages, and applications, etc. It’s a very logical and reasonable next step for everybody.
ICSP: What would you say to someone who posits that listing everything in a piece of software is actually helping the attackers, or any of these other misconceptions out there about SBOMs and how they’re used?
Pace: Yeah, I’ve heard some folks say that, and that argument is just so comical. The only person you’re not giving a path to is the defender. This idea that the attacker can’t figure out what software components are in X, Y or Z is like, “What are you basing that on?” I can tell you what you’re basing it on. You’re basing it on the fact that you’re too lazy to go do it. That’s what you’re basing it on. You’re not basing it on the fact that like, “Oh, this is so hard to do. It’s impossible for any network to ever identify the software components that exist here to compromise this device.” It’s fundamentally and factually inaccurate. The only people we are hampering in this scenario is the defender. Period.
ICSP: How much do the government actions on SBOMs help the cause?
Pace: To take a step back, No. 1, I am generally pretty opposed to government interference with just about anything, frankly. I guess that makes me a libertarian or something. I don’t know. I like to say I hate everybody equally.
ICSP: It’s the only sane way to live.
Pace: To be aligned with any particular group is — I mean, good for you, I guess — but I just don’t have time for it, and so that’s the first thing. That being said, I’ll tell you that what the federal government has done around SBOMs is wildly impressive, in my opinion. I was part of the NTIA (National Telecommunications and Information Administration) working groups that helped put out a lot of the SBOM stuff. Let me be wildly clear here, guys. I was a minor cog in that wheel, probably the smallest cog. But it was a really amazing group of humans that was spearheaded by Alan Friedman, who’s now with CISA (Cybersecurity and Infrastructure Security Agency). Another guy named Josh Corman was very involved in a lot of that, so [it was a] really impressive amount of work that came out of there. Here is what’s so fascinating to me about it though: that it’s not legislation yet, that it’s not an enforceable regulatory thing. That is not the case yet.
Companies are reaching out to us and saying, “Our customers are demanding a software bill of materials for this device, or this software package, or this whatever.” Point being, the toothpaste is out of the SBOM tube. If you had to hold a gun to my head and say, “What was the real objective of all of this?” I think that was actually the objective. Now, will we still put regulation in place that says SBOMs must be provided for anything that the federal government’s buying? I’m assuming that will, in fact, happen. But I think the actual intended consequence is what has already happened organically. Whether that’s the case or not, I have no idea. The proof is in the pudding, I suppose.
That effort has undeniably moved the industry forward in a positive direction, as far as I’m concerned. This isn’t even an offensive statement, in my opinion, to the federal government. This is not the federal government’s responsibility, right? They should not be the entity that is telling people to do things that they should already be doing. But the fact that they did, and it worked, and it’s done what it’s done for the industry … man, it was just a job well done. That is an exception, not the rule, from the federal government, generally speaking.
ICSP: They can be the tail that wags the dog. Isn’t the whole idea to create a floor, to create a baseline?
Pace: Yeah, that’s right. The problem is, here’s an example of where that’s a totally failed concept. You have CMMC, or NIST 800-53, and they’re like, “Guys, I’m compliant with 800-53,” and it’s like, “Yeah, I get that you are, but I can just walk in the front door, right?” So that’s the problem. That’s the game you always have to weigh and play. But in this scenario, I like this approach much better, where it’s just like, “This thing should be happening.” It’s not overly prescriptive necessarily. In some scenarios, I guess it is, but I just think it makes a ton of sense.
Will there be friction in the next five to 10 years? Yeah. Is there a potentiality where a bad thing might happen because someone now knows that this software component is here? Maybe. But that’s not the way you evaluate problems. We’re going to start implementing a solution, and by implementing that solution, some negative things are almost certainly going to happen. But over time, it’s undeniable that we are going to find ourselves in a better state. That’s the way I evaluate and look at these things. Which, to me, is undoubtedly true when it comes to the SBOM movement.
ICSP: If you could give one piece of advice to manufacturers and engineers about cybersecurity, what would it be?
Pace: Create a relationship with the people on the other side of the table, the IT team, the cybersecurity people. When I was at DoE (Department of Energy), we would do lunch-and-learns once a month. They’d come in, and they would do one and be like, “Here’s how this PLC works, and here’s how the network traffic flows, and we use these protocols.” We would come in and be like, “Here’s how this works,” and then guess what happens. Whenever we explain to them like, “Here’s how we monitor our network traffic on the IT network,” then they’re like, “Oh, that makes sense. Do you guys mind? Can we implement our intrusion detection system in the OT network?” Well, they already understand that now. They understand that we’re not trying to go in line. We’re just trying to make a copy of the traffic, which will not impact the availability of any of your devices, just so we can provide enhanced visibility to us for security purposes, and to you for asset management, for whatever other use cases you guys have.
It just makes the friction between those groups significantly less whenever there’s a well-established relationship there. I mean, this is just like people 101. Take people to lunch, buy them a beer, bring in balloons or something. That’s what we’ve found to be really effective. Just begin that relationship with people, and generally, things will get better over time.
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.
