Proof of Concept: Managing Software Supply Chain Woes

Read Transcript

Anna Delaney: This is Proof of Concept, a talk show where we invite leading experts to discuss the cybersecurity and privacy challenges of today and tomorrow, and how we can potentially solve them. We are your hosts. I'm Anna Delaney, director of production at ISMG.

Tom Field: I'm Tom Field, I'm senior vice president of editorial. And it's been far too long. Very good to see you.

Delaney: It has, indeed, and really good to see you, Tom. So in a moment, we'll be joined by two distinguished cybersecurity leaders. And our focus today is on software supply chain security and software bills of materials or SBOMs, and evaluating where we are right now, and where improvements still need to be made. And it's just over two years since President Biden released the executive order on improving cybersecurity in the United States, which called for the standardization of secure code practices. And I'm sure you'll think this is all. You'll agree that over the past couple of years, the conversation around SBOMs has certainly evolved. There's more awareness, for sure. However, with more adoption, we're also seeing more operational challenges. And it seems that many organizations are still struggling with where to get started on the basic requirements for building an SBOM. So what are your thoughts? Tom, I know you have plenty of conversations with security leaders at the roundtables, the summits. What are you hearing from them as to how they're doing two years on when it comes to implementing and operationalizing SBOMs?

Field: Right, it's a huge topic, we talk about it a lot. I'm going to take you back to a 40-year old American movie, I don't know that you've seen. I've talked to you about it, called A Christmas Story. And in the movie, there's a scene where a young boy sticks his tongue to a frozen metal pole. And he's asking his friends to come help him remove it. And the school bell rings, it's time to go in from recess. And the friends say the bell rang. And the boy said, "Ah, the bell rang." That's similar to the conversation I see about the SBOM. It's been called for, it's been required. A lot of organizations haven't quite figured out what they're going to do, how they're going to use this, but it's the SBOM, we have to have the SBOM. I haven't seen a move much beyond that.

Delaney: That's a great analogy. My tongue is beginning to hurt. But let's move on to the bulk of the conversation. I think it's time to welcome our first guest. I'm delighted to introduce CISO Chris Hughes, and author of the book Software Transparency, Understanding Supply Chain Security in an Era of a Software-Driven Society. Chris joined the studio. Thank you very much for joining us.

Chris Hughes: Yeah, absolutely. I'm excited to chat with you. And as an original Cleveland native, I appreciate Tom's reference to the movie there.

Delaney: Very good. Well, as I mentioned, you have written this book on why software transparency is critical. As you gathered your intel, your data, what did you learn in the process about where we are as an industry in the understanding of software supply chain security, and also the gaps that still need to be filled?

Hughes: Yeah, honestly, the reason I got down the path of writing the book is, you know, I've been a longtime cyber practitioner, and have been trying to deal with this problem organizationally myself with federal agencies and commercial companies. And I started trying to dig into the topic, and realize there's no book on it, despite everyone talking about this there's no actual, you know, book on the topic. And then there's practices like software asset inventory that have been like a SANS or CIS critical security control for 20 years now. But when you look at organizations, you know, in terms of their software, to software, asset inventory, they just have abysmal, you know, success of having a good inventory. And the problem has only gotten worse when we see the advent of cloud, managed service providers, cloud service providers, you know, adoption of open-source software, we simply don't know what software we're using in our organizations, and it's causing a lot of problems. Also, there's been some evolution. From the attackers perspective, they've realized rather than targeting one single organization, they can target, you know, one widely used open-source software component or a cloud service provider, managed service provider, and have a massive downstream impact across many organizations, hundreds and thousands of organizations and millions of users - it's just far more efficient for them. So that said, there's a lot of challenges we have as an industry. And we've seen a lot of organizations, you know, come out with guidance, whether it's in the federal side with NIST and NSA and CISA and others, or commercial organizations like CNCF, and the Linux Foundation, OWASP and others. But that said, we have a long way to go. And also, unfortunately, some of the aspects of software supply chain security, certain things that are in the toolbox, like an SBOM, for example, have kind of been painted as a silver bullet, you know, as if it's going to solve all of our woes and challenges around software supply chain security, when it really is just one tool in the toolbox. It's going to help us tackle this challenge. So we have a long way to go. And looking forward to the conversation here.

Delaney:I wanted to address a story that's really top of mind, very current for us, as a media platform. The move at supply chain attacks and the Clop ransomware. As of earlier this week, at least 545 organizations appear to have been directly or indirectly affected by Clop's MOVEit attack. So how big is this threat, and will organizations actually get ahead of it?

Hughes: Yes, this one was massive - folks have called it potentially the largest zero day exploit we've ever seen, as you said, hundreds of organizations, millions of users by the last count I saw, including many federal agencies, state local governments, and, of course, many commercial organizations as well. In terms of how to get ahead of it, it's a bit of a challenge, because we are using external software from many different sources, whether it's self-hosted software in our environments, or SAS software, open-source software in our development activities. And, you know, it's a bit of doing the basics in terms of having good software as an inventory, patching it in a timely manner, having good threat intelligence to understand, you know, what are the malicious actors doing? How do we respond to these incidents and have been prepared for them? Obviously, I know you guys are big proponents of things like zero trust. So having zero trust in place, and having those practices to kind of limit the blast radius when something does go wrong; implementing least permissive access, and access control in our environments is huge. But it's a bit of a challenge too, because, you know, if you look at like SolarWinds, and other incidents like that, either patch patch patch, but what happens if it's a software supply chain attack where the patch itself, the update is poisoned, and you quickly apply it to your environment, now you've kind of compromised yourself. So it's a very challenging situation, you got to have those best practices in place, and just have a playbook to be able to respond when something happens, because, as I mentioned, in the beginning, malicious actors have realized that the software suppliers are a rich target that can compromise many people across the ecosystem. So it's going to happen again, and you got to be prepared to respond to it, you got to be keeping an ear to the ground to what's going on in the industry around threat activities, and have those best practices like zero trust and limited access for privileged access, you know, patching things like that in place, too.

Delaney: You mentioned that suppose that mean, in an ideal world, what does good look like? And what steps should organizations be taking now to build SBOMs into their pipelines?

Hughes: Yeah, so it's a great question. And one, I think we're still figuring out to be honest with you, as an industry, we saw SBOM get a lot of momentum, you know, underneath NTIA from the federal government. And then, of course, move to CISA with folks like Dr. Allan Friedman, and the industry has really evolved. We've seen two SBOM formats, you know, CycloneDX from OWASP, and SPDX from Linux Foundation really take hold, organizations are starting to play with tools to produce SBOMs, up to the question of what does good look like and then what the heck to actually do with this thing, once I have it. It's kind of where we are as an industry. So there's a lot of different tools in terms of vendors integrating these things into their platform to produce SBOMs, you know, open-source software tools, you can put in your CI/CD pipelines, for example, to create an SBOM. But the problem we're seeing now is that it also creates a lot of noise. Maybe I can see all the components in my software, whether it's from a supplier or software I've created, maybe I can see all the vulnerabilities. But now I need to add some context to that, you know, what's actually exploitable? What do I need to be concerned with what actually poses risk to me as an organization, and that's why we're seeing efforts like you know, EPSS, you know, kind of in vulnerability enrichment, you know, kind of things take hold in the industry, is trying to help organizations make some signal from the noise, understand what to focus on. But for organizations looking to get started, you know, talk to your vendors, see if they can produce an SBOM, that's kind of a signal of a more mature provider, more mature software supplier, for example. If they can provide that artifact to you, it shows that they're at least moving that direction. And then internally on your own software development efforts, integrate those tools into your pipeline, start creating these artifacts, these SBOMs, for example. I'm going to lean formats, see what kind of information you can see, you know, what kind of open-source software usually you have in place and what vulnerabilities exist in that open-source software. Just starting down that path and building that maturity is a great first step.

Delaney: That's really very useful. Chris, thank you so much for your perspective and insight, just for now. I'm going to pass on the baton to Tom.

Field: Excellent. We have another guest joining us. He's an old friend. He's a VP and CISO at DXC Technology. Please welcome Mike Baker. Mike, thanks so much for being here with us today.

Mike Baker: Thanks for having me, Tom.

Field: Now, I remember soon after the Biden executive order came out that you and I were talking and at that point, you had introduced the term SBOM at every vendor conversation that you were having He had a lot of answers. But you raised the question. So two years later, what challenges have you faced in adopting secure software development frameworks or even validating the project products that you use to ensure that they adhere to these frameworks?

Baker: Yeah, honestly, I think Chris said it right. You know, the formats have come out. I think the mandate hit us in the executive order kind of out of the blue was something that we were playing with or toying with or talking about academically, but when the requirement came out, it was something that really put some oomph into the industry. But I still think we're, I still think we're catching up. I mean, Chris said it best. The executive order came out two years ago. It really introduced SBOM into the lexicon of secure software development and the delivery of software. But we're still trying to get there. From an operational standpoint, we have a lot of work to go. Now, I've seen, you know, Chris talks about where we are as it relates to formats and the emerging tools, I haven't seen a tool that can do it at scale yet. And from a vendor perspective, it's still pretty few and far between and who can produce that the revolution that I see coming up, though, that I think is really going to put some gas on this fire is going to be generative AI. And again, I hate to be a broken record, I'm sure that you talk to everyone, and they're like, AI is the next big thing. And it is. And it is for a lot of stuff here, around developing software. But most importantly, I think the development in the generation of an accurate SBOM. And I'm hoping that's going to put some adrenaline in the industry and get us really to where we need to be. But again, I kind of want to take it back a little bit of time. When we talk a lot about SBOMs, Chris said it perfectly, is one tool in the toolbox. And at this point, it's a very immature tool, we should be talking about the journey. And the journey around developing secure software starts at the development frameworks, the secure development frameworks, the adoption of those frameworks, the mandate across our software companies that they need to follow that and demonstrate that to customers like myself who consume that, and then we go on the journey of SBOMs that can then revolutionize vulnerability management, etc. So I think we're like cart ahead of the horse a little bit here, I think we need to take a step back and make sure the industry is really adopting those frameworks that are absolutely necessary, just do the basic blocking and tackling, delivering secure software.

Field: You bring the horse right back into the barn, and you've got organizations of all sizes, their challenge is to know what they have for code within their organization. And there's a huge asset inventory issue throughout. How have you dealt with that to know what kind of code you're developing and what you're ingesting from your partners?

Baker: Yeah, I mean, yeah, it's a huge problem. I kind of went into the AI question there in terms of, of how do you do it? How do you have some accuracy behind that SBOM? How do you have some defensiveness, some defensibility. So if I consume a piece of software, and I'm talking to a software provider, about that SBOM and what I consume, and I have an issue with it, how do I know that it's an accurate reflection of that inventory, as everyone knows, in the cyber industry is kind of like the number one thing you need to do. If you don't know what you have, you can't secure it. And it's a constant challenge. And I think the biggest thing around any inventory question whether you're developing software, or you're counting hosts, or you're counting cloud workloads, is you have to commit to the basis, you can't forget about it. You know, as a practitioner of cyber and a leader of cybersecurity programs for the last eight to nine years, the minute you forget about the basics is when you've lost the battle. You have to always remember inventory, you have to always double down on hardening and managing vulnerabilities. And making sure your logging and monitoring is up to speed before you can even go into the world of SBOMs and VEXes and CycloneDX.

Field: So Michael, for those that have produced or have received SBOMs, I'm starting to hear questions like, "Okay, you've got your SBOM, the ingredients. What do you do with this now? How do you operationalize this?" And there aren't a lot of answers there. What tools have you investigated to be able to consume and use and operationalize the SBOMs you receive?

Baker: So I don't think it's a tool question here as much as it is a people and a human capital issue. So I'm sure the tools will come. The industry is here. People are writing great books about this. Now, you know, we have good resources, it's now in the national cyber strategy as long as along with the CEO, I think the issue is going to be is how are we training the next generation of people who are smart, like Chris Hughes, in this topic that understand what it is and consume it? And then the operational component of is exactly what Chris mentioned, you have to consume it. Okay, what tool do we have the consumer that produces a VEX? Once I get the VEX, who do I hand it off to to go make changes? Who do I talk to do this? What is the risk trade off associated with different things that the VEX has? Because, again, from a tooling perspective, I think we have a long way to go. But again, as a CISO, the biggest thing for me is going to be, you're going to hand me VEX, I'm going to say, "Okay, what do I do with it? What is my risk threshold as it relates to this unique risk has been presented to me, because there's going to be no clean VEXes. Chris, you back me up here. You've probably seen a bunch of them. There's always going to be dirty VEXes.

Hughes: I was just going to say if I see a software that has no vulnerabilities, I think people just haven't looked hard enough quite yet.

Baker: Yeah. So you get back to the angel question, Tom, which is what is that risk trade off? What does that risk tolerance, how do you communicate it internally and externally as it relates to how you're operating with that, essentially, new report that you have to manage? So I think you got to hire the right people. You have to invest in the training, anything in this new aspect. And you have to alter your risk management program to adopt this at scale of which these programs are already, like drowning at scale. You know, so Chris had mentioned how this could revolutionize vulnerability management, I'm looking forward to that. We've gone through scanning, to having an ocean of vulnerabilities to risk-based vulnerability management to different scoring mechanisms across the board and different vendors. And you should do this before this. This to me is hopefully going to be the gateway to true risk-based vulnerability management based on exploits, there encode, and also the true gateway to zero day response, where we can see within the libraries, how we can see those exploits and code. That's my hope. But I would say we're still years away from that.

Field: So well said, Michael, I appreciate that. And I'm going to turn this over to you, Anna. I'm going to challenge you to use the term dirty VEXes in a sentence.

Delaney: Yeah. Challenge accepted. No, well, bringing the body together just a bit of future gazing, this last question, looking ahead to the next 12 to 18 months. So what are your top software transparency predictions over this next year or so? Maybe Chris, we could start with you.

Hughes: Yeah, I think we'll see the industry continue to mature, you know, in terms of their adoption of SBOMs, both from suppliers trying to prove these artifacts and provide actionable information to downstream consumers and customers. And then on the customer side, for folks like Michael, they're going to start to mature their organizational practices, integrating things into procurement in your vulnerability and compliance teams, how to ingest these artifacts, how to make sense of them, how to start to request them from suppliers. And then not only that, but going beyond the SBOM piece, like he talked about, we're seeing a big push for things like NIST secure software development framework, if you're a software supplier, show me how you're producing software securely. I can start to attest to that information, you know, provide that to me as part of a procurement activity, it starts to be a competitive differentiator, for example, of people consuming software. So as he said, I think we've got a long way to go, but we're moving in the right direction. And that's promising.

Baker: Jump in there as well. So just adding on what Chris said, I think we're entering into an era of which is good transparency, number one, we've talked about SBOMs, but also accountability. Number two, all really good things, all can be great opportunities to organizations are going to be great risk organization. So the moral of the story for me is that the stakes just got much higher. When you look at a national cyber strategy, they use the words accountability, they use duty of care, those sorts of words. So this is no longer like a niche hobby and people that are, you know, just shouting from the corner that we need to develop secure software. We've seen example after example, year after year, where we've had to respond to the software vulnerabilities at scale that puts our nation at risk. So what we're looking at here is I'm going to see an explosion of products and hopefully opportunities on the market that can make this more simple and more easy to achieve. And that's what I'm really looking forward to is that accountability portion, when you look at the changing verbiage is something that's going to drastically change our industry. And I think it's going to really change the way that software providers look at their liability or their opportunities when they deliver software again across the nation.

Delaney: All right, good. Well, this has been extremely insightful and educational. I've really enjoyed it. I think, Tom, you did too.

Field: Oh, absolutely. Chris, Michael, thanks so much for being a part of this conversation today. I really appreciate it.

Delaney: And thanks so much for watching. Until next time.