Supply chain insights
- Supply chain attacks will keep happening. The ones that make the news aren’t everything that’s going on. There many others that never become part of the news cycle.
- Protecting the supply chain is a shared responsibility. It takes a lot of different domain expertise to come together and get on the same sheet of music.
- Software bill of materials (SBOMs) and other tools are helping improve our visibility and transparency, but there is still a long way to go.
- The most mature organizations have a CISO that has the full support of the board and C-suite, and has the political capital to touch on the IT and OT side.
Supply chain attacks could be the next frontier of cyber threat given how profitable they can be. The attack on SolarWinds was a perfect example. Once the threat actors got into SolarWinds’ networks, they were able to amplify their attack by accessing hundreds of other companies. So how can companies guard against supply chain attacks, what are the lessons to be learned from recent strikes and who should be in charge of supply chain security?
John Deskurakis, chief product security officer at Carrier, and Tony Turner, vice president of Fortress Labs with Fortress Information Security, discussed how to protect against supply chain attacks and offered viewpoints from two very different perspectives — manufacturing and security — in this partial transcript from the May 6, 2022, RCEP PDH webcast (archived for one year), “How to Protect Against Supply Chain Attacks.” Check out Part 1 of their discussion on why supply chain attacks create such a target-rich environment. In Part 2, they discussed why supply chain attacks and ransomware are a toxic mix. In Part 3, they discussed managing upstream versus downstream attacks.
This article has been edited for clarity.
ICS Pulse: What are the primary differences between CycloneDX and SPDX? And what happened to SWID?
Turner: SPDX is an older, more mature format. It’s an ISO standard. It goes through a standards adoption process, hence being an ISO standard. In many ways, it’s a much more mature software billing materials specification. Many manufacturers [that] have adopted SPDX are some of the foundational use cases around SPDX, or around licensing. Not so much the vulnerability and security use cases, but more around licensing and protecting themselves. When we look at more of the application security use cases, we see projects like CycloneDX, which is an OWASP. SPDX is out of the Linux foundation.
CycloneDX is a more recent specification. It’s updated much more frequently because it doesn’t go [through] the same kind of standards adoption process, but it’s run by a team of application security subject matter experts that are looking to solve the application security and software security-related risks. It [has] expanded beyond just being a software bill of materials (SBOM) format. They now have a hardware bill of materials, what they call a manufacturing bill of materials or MBOM specification. I think of it more like a supply chain descriptor data specification.
SWID was one of the early standards that was posited by the early NTIA efforts through the Department of Commerce effort to evangelize SBOMs a couple years ago. I think the industry at large has realized that SWID is less of an SBOM format and more of a software-naming mechanism, similar to CPE. From my standpoint, I don’t think of it so much as an SBOM format, but more as a potential competitor or maybe ultimate replacement one day to CPE, if we can ever figure out the CPE and CDE NBD ecosystem, which is really why the industry at large still uses CPE.
ICSP: What is a VEX and why is that important for SBOMs?
Turner: VEX, or the concept of VEX, is really kind of a companion document or data format to an SBOM. VEX stands for vulnerability exploitability exchange. It’s this concept of an attestation framework to answer the question: Is my product vulnerable? There are a couple of pieces [to] this. Ideally, you want suppliers to be providing software bill of materials and VEX documents because the data has the highest fidelity when it comes from the supplier. They understand their products better than anyone. There is this whole concept of third parties that are producing SBOMs and VEX’s. Obviously, that’s more challenging when you don’t understand the software as well. But one of the promises of VEX is to answer the question about exploitability, or is my product affected by a specific CBE.
What happens a lot of times is a supplier will take a component that has a bunch of vulnerabilities in it. They may strip out all the vulnerable functions and reissue that software in their own product and not rename the software component. If you see open SSL 1.1, is it the vulnerable version or is it the not vulnerable version? Just looking at the SBOM, it may be challenging to understand that because all you have is a name to go by. But with a VEX, this is an attestation that can be provided by the supplier to say, “Not affected because I don’t use a vulnerable function. I don’t call the code. We actually fixed the code,” or some other reason why that vulnerability does not exist.
ICSP: What are some of the prominent supply chain attacks that we should consider as examples of lessons to be learned?
Deskurakis: Tony and I have talked about a couple of notable ones that are very good recent examples about securing the supply chain. Log4j was, as we mentioned, something that is not too difficult to remediate in a single instance and manage in one instance, but the problem is it proliferates across thousands and hundreds of thousands of places for one given supplier. The lesson learned there for manufacturing is some of the stuff we were talking about. These will keep happening. These events, the ones that hit the news, aren’t even everything that’s going on. There are other ones that won’t become part of the news cycle that people like Tony and I are dealing with all the time. If this isn’t part of your day-to-day job, great, but when they hit the news cycle, I’m actually relieved because it brings a lot of awareness to folks that aren’t focused on this work every day.
ICSP: Do you think the industry has actually learned from these examples?
Deskurakis: Unfortunately, the truth is that the folks that really learn from it are the ones that are impacted directly and financially. They learned the immediate lesson. There is still a bit of a prevalence across industry and in some areas where folks think, “Well, that’s not going to happen to me,” or they overestimate their relative security and maturity within their operations. The right posture to have is to never settle, to continually improve and to constantly refocus your efforts on what you’re doing. Can you do it better?
The folks that believe they have things all figured out are the ones that I am most suspicious of and concerned about. When they’re part of my own supply chain at my company where we’re ingesting their goods to redistribute or to use for ourselves, you quickly figure that out. So, has industry learned? I think some folks in industry have learned from the recent examples and the fact that it seems to be becoming more and more prevalent, but I think there are others that overestimate their ability and their ability to respond with their current methods. And the folks that approach this formulaic are likely to eventually fall into some sort of a problem.
Turner: I think it’s a very difficult question to answer because how do you measure learning? How do you measure success of learning? By and large, more organizations are starting to learn from these things and starting to do the right things. Obviously, we haven’t learned yet. Even if you look at issues like buffer overflow attacks and sequel injection, these are things that have been known about for decades and decades. Yet we still see these problems creeping into our software. Are we getting better at these? Yes, absolutely. Many of the frameworks that we use for software development now have controls built in to help defend against some of these attacks. It takes time. This is not a problem that we can solve overnight, but the other piece of this is our visibility is getting better.
We have better detection tools. Software bill of materials is a really good example of more recent efforts to improve our visibility and transparency into these kinds of things. So are we getting worse? Are we getting better? Well, I see more things, [but] does that mean things are getting worse? No, maybe it just means that I’m detecting more things. I’ve worked with customers in the past that said, “I don’t have a security problem because I haven’t had a security incident in three years.” And I ask them, “Well, what kinds of detection capabilities do you have? Are you inspecting encrypted traffic? Do you have an effective log management or SIM event management, security event management program?” And find that they have very, very lax controls on the detection side, and they’re measuring their success based off of, “Did I have a major consequence that I knew about?” That may not be the most effective way to understand whether they’re being targeted and whether they’re seeing bad things happening inside their environment.
Deskurakis: The answer is it’s kind of a culture change. It’s a culture type of a thing. Are we evolving into an industry culture where this is considered more of an important thing to continually work on? We’re starting to see the proliferation of a lot of new legislation coming out — some of it good, some of it hard to understand and maybe amiss — but the idea that jurisdictional governments are worried about this. That’s a good culture change sign to me.
I’m starting to see signs that the culture is shifting in a different direction, not just in industry but also in different countries and governments. Folks are wanting to actually attack this now, [but] are we doing a good job of it yet today? I think you and I would argue if we looked industry-wide, we’re probably not at that level of maturity we need to get to. But it’s a continual process. I don’t think we’ll ever be in a good enough state.
Turner: One of the interesting things to me, especially working in critical infrastructure, there’s very strong safety culture in critical infrastructure. If you look at the risks in electric power and under manufacturing, [it] is very focused on [what is] core and endemic to what people focus on. Anything that gets tied back to safety is non-negotiable. It really doesn’t matter if human life is at risk, we will do this thing. We will implement this control. I think we’re also starting to see a shift of equating many cybersecurity risks to safety risks, and that’s helping to drive the cultural shift, at least [for] the customers that I’m working with.
ICSP: That safety culture speaks to the decision makers and is something, especially on the OT side, that is already part of what they do. So who should own cybersecurity? Who should be in charge of supply chain security for a business?
Turner: I think it has to be a partnership across the organization. We obviously do need a clear owner that is responsible at the risk level across the organization. It’s more than just a product security problem. We have to dovetail into all the areas of business where we are utilizing better products and services. Procurement needs a seat at the table. Legal needs a seat at the table, risk [and] obviously compliance. I would say the group within most organizations that is most frequently missing in the conversation are the people that are responsible for securing the company, so security operation [and] security architecture. They absolutely have to be part of this conversation. I would say that organizations I’ve seen that are the most mature are when we have a CISO that has the full support of the board for these issues and has the relationships and the political capital inside the organization, especially to touch on the IT and the OT side.
The challenge that I see here is, where are the budgets? Many CISO’s tend to be much more IT focused, and they use IT-centric solutions to secure their environments. Then OT gets left to fend for themselves and figure out their own path. If we have strong security leadership within the C-suite from a CISO standpoint that has strong alignment with the OT side of the house, and they’re taking the OT side seriously, I think it can be a very effective mechanism.
But I don’t think there’s a clear answer because every organization is different. The way they’re structured is different, their culture is different [and] where they prioritize their business focus is different. You kind of have to take each organization as an individual entity and [ask], “What makes sense for us?” In my company, IT and security are in the same group, so my CISO actually manages IT inside my company, which is kind of unusual. Normally, it’s the other way around.
Deskurakis: That is another complicated question: Who should be responsible for industrial security when it’s a beast with many heads? It’s very complicated, very difficult. It takes a lot of different domain expertise to come together and get on the same sheet of music. What we like to say at Carrier is that cyber is a team sport, and it’s a shared responsibility amongst many. From the manufacturer perspective, if we’re shipping products, services and offerings, we have a responsibility upstream and downstream to ensure our part of the job is done internally inside of the company. That responsibility requires that [we work] with all kinds of channel partners. Where I work, we are not actually shipping product to the end users, but we still have to work with the end users.
That is a complicated thing to do. We’re dealing with dealers, distributors, end users [and] our suppliers, as well. So that whole ecosystem is very complicated. Where I’m at, we have a CISO, but I’m the CPSO. So my focus is products because the way you secure products and offerings is very different than how you do IT cybersecurity. Sometimes there’s a convergence, but many times there’s not. The way we engineer or secure a product is not the same way as you would secure company infrastructure, but sometimes they have to coalesce. So there’s that shared responsibility internally [and] externally, which is why we say it’s a team sport. It’s everybody’s responsibility.
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.
