Tony Turner -- Threat Modeling and SBOM

Have you ever considered using an SBOM to inform your threat modeling? Tony Turner has. Tony joins us to discuss SBOMs, threat modeling, and the importance of Cyber Informed Engineering. 

Tony delves into the SBOM (Software Bill of Materials) concept, highlighting their value proposition in identifying vulnerabilities, demonstrating compliance with software licenses, and informing M&A activities and incident response indicators related to cyberattacks. We also explore the integration of SBOMs into the system engineering process and security engineering.

Tony further introduces the concept of Consequence-Driven Cyber Informed Engineering, which emphasizes understanding the potential consequences of cyberattacks on critical infrastructure rather than just on individuals or individual businesses. We discuss the four-step process of consequence-driven CIE. The conversation also addresses the challenges in communicating SBOM information, the importance of demanding transparency from suppliers, and the need to place trust in trusted third-party attestations.

Follow up:

- Research tools for integrating SBOMs into threat modeling
- Explore methods of communicating SBOM information
- Investigate Cyber Informed Engineering and Consequence-Driven principles in more detail

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

[00:00:00] Tony Turner is the CEO and founder of Opswright, a new type of cybersecurity company, disrupting security engineering for critical infrastructure. I found Tony via a talk he did on threat modeling and SBOM Topic caught my attention, so I reached out to have a conversation. We talk about threat modeling in SBOM, the value proposition of SBOM, security Engineering in SBOM and Cyber Informed engineering.

[00:00:28] This is something you'll wanna learn about. I'd never heard of it before, but it could also help us in building more secure applications and products. Both. We hope you enjoy this conversation with Tony Turner. Hey folks. Welcome to another episode of the Application security podcast. This is Chris Romeo, CEO of Kerr Ventures, and one of the co-hosts here. My good friend Robert Hurlbut, joins us as well. Hey,

[00:01:36] Robert Hurlbut: Hey, Chris. Yeah, Robert Hurlbut and I'm a principal application security architect and threat modeling lead at Aquia. And, uh, really glad to be here, uh, with you to talk about another great application security topic.

[00:01:50] Chris Romeo: I mean, getting into a style of threat modeling or a, a way of thinking about threat modeling that's different than anything else I've ever learned or, or heard about before, is something that's always super exciting for me because, you know, we, we do this podcast because we wanna learn and we bring people on who can help teach us things, and we can ask questions, and then everybody in the audience gets to take part as well.

[00:02:10] So I'm super excited to have Tony Turner here with us. Today. Um, Tony, we don't give our audience, or our, sorry, our audience, we don't give our guests much time to get warmed up. We just throw you right in and say, what's your security origin story? Or how'd you get started in this crazy world of security?

[00:02:27] Tony Turner: Thanks Chris. So, uh, so I'm currently the CEO of a cybersecurity software company called Opswright that focuses on security engineering software for critical infrastructure. But like the path that I took to get here was far from straightforward. Um, if I go back, you know, 25, 30 years ago, I was an English major.

[00:02:49] I was a combat correspondent in the Marine Corps. Uh, I got out and I was, you know, writing stories for like the local, uh, city magazine, downtown, you know, Hawaiian Tropic Beauty contest at, you know, so-and-so's bar and that kind of stuff, as far away from cybersecurity as you could probably get. Right. Um, and the guy that ran.

[00:03:12] The guy that ran the local company scammed me and a bunch of other people out of a bunch of money, took the advertising revenue and skipped town. That was kind of one of my first, uh, exposures to the concept of fraud and crime, um, as a victim. Uh, and then kind of fast forward as things went on, I found myself naturally gravitating towards technology roles.

[00:03:32] Wasn't trained, didn't go to school for it. You know, uh, I developed webpages for my dorm mates in college for beer money and, you know, stuff like that. It just, it was just a thing. It was easy. It came easy to me. Um, and, uh, you know, kind of as time went on, I found myself in more and more tech roles and, you know, I guess about 20, 20 plus years ago, um, it kind of as the advent of, you know, the malware and worm activity and these kinds of, uh, intrusions into our.

[00:04:03] Organization's infrastructure started to become more and more prevalent. It was really pain, right? And I tell people all the time that the best way to change behavior is to encounter pain and change course. Um, like no one changes anything unless they have a reason to change the thing. And for me, um, it was shifting from I'm just gonna be an IT guy to.

[00:04:28] I'm gonna learn how to secure the environment so that I can avoid that pain and that other people's can avoid that pain. Um, I'm, I'm a generalist really. I kind of reinvent myself every few years. I don't know if it's out of boredom or what, but it seems like I'll spend three to five years diving deep on the topic, whether it's network security, it was in deep in the application delivery and WAF space for a number of years doing exploitation and, uh, ran the O O WIC project.

[00:04:56] Uh, for a number of years, still technically run that. Um, and then for the last, I guess, I guess really for like the last five or six years, I've been more focused on critical infrastructure, um, security spec, specifically defense and, uh, electric power and, uh, really for the last several years in supply chain, uh, security.

[00:05:15] And, and most recently with my new company focused on the concepts around cyber informed engineering. So,

[00:05:23] Chris Romeo: And so when you, when you mentioned kind of in the context of working with critical infrastructure, you know, cyber informed engineering. Uh, is your focus on trying to secure the code that's being written and going into the critical infrastructure or critical infrastructure itself, or kind of what is, what's the, the lane that, that you're kind of focused on there?

[00:05:46] Tony Turner: The scope is very large. Um, and. Cyber informed engineering really speaks to the cyber born impacts to critical infrastructure. But, uh, or rather, the cyber causes of harm and critical infrastructure, but the controls that need to be implemented are not necessarily all cybersecurity controls, right? They may be engineered manual safeguards, physical security related things as well, uh, and the scope.

[00:06:16] We may be talking about an entire site, like I'm building a new substation. I need to make sure my substation is secure. And, and really what we're really talking about there is securing the critical function, not securing a piece of software or securing a product. Because at the end of the day, organization doesn't really care about product security.

[00:06:35] They care about whatever their function is and making sure that their functions are resilient and they can, uh, fulfill their mandate. but to answer your software is certainly part of that.

[00:06:48] Chris Romeo: Hmm.

[00:06:49] Mm-hmm. 

[00:06:49] Robert Hurlbut: cool. So to jump in to, uh, our topic today, uh, Tony, what's an sbo? I know we've heard this term out there and, and, uh, people are talking about it more and more. Uh, but what is it and what are the types.

[00:07:07] Tony Turner: So, uh, an SBOM or software bill of materials, um, has obviously exploded onto the scene recently based off of, uh, you know, the efforts, uh, uh, president Biden over the last, uh, couple years in the executive order, uh, as well as just industry kind of coalescing around this concept that we need. Software transparency.

[00:07:26] We need to know what's inside the software. And the, the, probably the best analogy is to think of it as like an ingredients list, like what you might see on a box of cereal, right? You go to the grocery store, you buy a box of Cocoa Puffs, and you could, you just, you can make an informed decision as a consumer by looking at the ingredients list.

[00:07:45] Uh, am I okay with what's inside this thing that I'm about to eat? Um, but software's always been kind of a black box to consumers. Um, , um, the many times vulnerabilities that are 10, 15 years or older. Just hanging around in, you know, firmware or software that we rely on every day and we have no idea. We just kind of go through life blindly assuming that everything's okay because we have a trust relationship with our vendor and surely our vendor would never put us at that kind of risk.

[00:08:14] Right. Um, as far as types of SBOs, uh, the type, when people talk about types of s bombs, they're really talking about when the SBOM was generated. Or from what data the SBOM was generated, right? So am I generating the SBOM from my source code, including a bunch of cruft that might be in there that gets dropped as part of the build process, right?

[00:08:37] Or is it part of my build? Is it, uh, from the finished product? Is it a reverse engineered sbo? Is it a runtime sbo? Meaning, uh, I may have, uh, included system libraries that my application relies on. If I'm doing an SPO from source, they're not in my source code, but they're on your machine. , um, and they're all part of this holistic understanding of how that piece of software actually works.

[00:09:00] Um, the advantages of doing that means I get a much more accurate picture of what's running inside my software. The disadvantage of that is it may not be a scalable way to do SBOs, because now I need to look at it on every single system because you may, the two of you may be running the same software and using different versions of the same software library, uh, that gets pulled into that piece of software.

[00:09:22] And so if I look at Robert's machine, , and he's running a vulnerable version, but Chris is running a newer version of that system library. I may make an inappropriate assumption about where the, you know, are you vulnerable, yes or no? Right.

[00:09:38] Chris Romeo: So Tony, when you think of the. Value proposition of SBOM Like I'm, I'm curious to, to hear from your perspective as somebody who's been working in this space for a long time and studied, it really dove deep into it. You know, as we were talking in the, in the prelude to, uh, hitting the record button, I feel like I'm a bit of a pundit in the world of SBOM and May, it may, it may be just because I don't. I haven't thought deeply enough about kind of where we're going with this, and so I'd love to understand kind of from your perspective, like what is the value proposition, what's the end game that we're heading towards with sbo?

[00:10:12] Tony Turner: So there's really one primary use case that people fixate on as the value proposition of SBOM, but there are many others. So, but I'll start with the. Big one. Uh, big one in the room is just vulnerabilities, right? Understanding where we have vulnerabilities in our software. Now, the one thing I always try to caution people to understand is when you look at an S bomb and identify the vulnerabilities, this is the world of potential vulnerabilities in your software because there's quite frequently, at times, a high level of false positives.

[00:10:46] In the vulnerabilities that are identified from the S bm, a couple of reasons for that. One, being back boarded fixes a vendor may have resolved an issue but not updated the version. And the way this SBOM vulnerability identification looks is just a simple lookup against the national vulnerability database based off of a product version, a component version, right?

[00:11:05] Um, and so that component version is not illustrative of what's actually running inside the software. I mean, no one is looking at the code and saying, The sbam is not analyzing code, it's just looking at, you know, uh, vendor component version and doing some data correlation to say, okay, you might have vulnerability.

[00:11:26] The other reason that this happens, especially an open source, I may use an open source pro, um, component in my product. and I may only need 10% of the functionality of that library that I just pulled in. So if there are 10 functions that can be called in this library, I only use one of them. That's not the vulnerable function.

[00:11:45] I never call the vulnerable function in my code. Do I technically have a vulnerable version in my software? Well, yeah. Is it, can it be affected by a bad guy? , probably not. Uh, so we wind up with a lot of noise inside this process, and so it requires some further analysis beyond just saying, do I have a vulnerable component?

[00:12:07] Do we need to go beyond that and say, okay, yes, I have a potential vulnerability problem, but what now? Like, um, can it be affected through configuration? Am I actually calling it, is there a path to the vulnerability? Uh, and if so, then I, I need to make some risk decisions about what I'm gonna do about it.

[00:12:24] In some instances it may just wind up being a code cleanup and code quality issue more so than a vulnerability issue. Um, some of the other use cases that we see, uh, really the original use case for Sbam was licensing had nothing to do with vulnerabilities. Right. Um, you know, software vendors need to make sure that they're in com, they're in compliance with all the software licenses that, that they had to, had to work with.

[00:12:45] They had to, um, show to other stakeholders that that wasn't a problem. Um, and we, we started to see this in m and a. activities where, uh, even, even some VCs are expecting to, to see like, what are we actually buying here? Um, An as POM can help illustrate like how much of this is third party code? How much is this, is your code?

[00:13:09] Did you just throw a, a fancy UI on somebody's open source project? Uh, that's another use case. Um, uh, previous jobs we've even used it to help inform, uh, incident response. Uh, related, uh, indicators of compromise and software based off of SBOs and other artifacts. But the SBOM is really just one of many attestations that needs to be part of your supply chain discovery and analysis process.

[00:13:35] It is not the, it, it's not gonna give you the whole picture, right? If you look at like a SolarWinds kind of event, SBOs would not have. Would not have identified a SolarWinds problem. Like it just wouldn't. Anybody that tells you different is lying to you. Um, we wouldn't need things like behavioral analysis to understand what's happening on the network, to understand something's not right here.

[00:13:55] But then we look at other situations like a log for J where SPO is the perfect fit to understand what's going on. Uh, just like everything else in security, there is no silver bullet to any problem that we have in this industry, but it is a tool in the tool belt, uh, and we need to be smart about how we do it.

[00:14:13] Robert Hurlbut: So a little earlier you mentioned, uh, cyber informed engineering, but how does, uh, security engineering itself fit into an SBOM And then also there's a, this concept of a consequence driven cyber informed engineering. So can you talk about those two topics?

[00:14:31] Tony Turner: Yeah, sure. So I'm, I'm, I'm going to kind of raise it up, uh, a little bit higher level to just talk about. The system engineering process as a whole of which security needs to be embedded inside, right? So if we think about traditionally how we approach system engineering in a very kind of waterfall style approach, right?

[00:14:51] We have a very rigorous process to define a concept of operations, define requirements. Um, we go through this, uh, very rigorous design process until we get into like a build, test, deploy, operate kind of, kind of phase, right? That's very cyclical, right? Um, if you kind of like compare that to a more agile iterative.

[00:15:11] um, deployment or a DevOps style. Um, we have a much more, you know, continuous delivery model. But regardless of what your approach is to doing engineering in general and defining the thing that you're gonna build and doing all the checks to make sure that what you built is what you thought that you were gonna build, right?

[00:15:29] There are certain security decisions. that need to happen along the way, whether it's a human looking at a thing or whether it's just au automatically performed inside your c i c pipeline, right? And the s om is part of one of those steps that needs to happen in that engineering flow. I need to know what I'm building.

[00:15:49] I as a product supplier or product manufacturer, um, I have a certain amount of liability. For the risks that I create for the downstream consumers of whatever product that I build. If I don't know what's in my product, how can I possibly ensure my customers are not gonna have to take on some risk from using my product?

[00:16:16] Right? And I, I think by and large, I think many suppliers have. Had some degree of understanding of this, especially for their own stuff. Probably less understanding for their open source stuff other than just the licensing side of this. Um, I, but the consumer has not had any visibility, uh, into this to understand, uh, what, what's in our software.

[00:16:38] So the cyber inform engineering, uh, is a methodology proposed by the Department of Energy to, um, enforce a secure by design. Approach, uh, to doing engineering to make sure that we can provision secure systems. Um, uh, many times in critical infrastructure, these systems are in place for 20 to 30 years or more.

[00:16:58] Um, there's not a lot of opportunity to fix things once they're in place. All you're left with is just Band-Aid the problem. And I think we're starting to understand as an industry that these Band-Aids, number one, are costly. You know, especially with the economic position that the industry's in today, I think CISOs are looking for opportunities to reduce cost, reduce spend, consolidate platforms.

[00:17:18] Uh, and that's very much aligned with the need for security by design, because we reduce the need for band-aid solutions. If we design things securely in the first place, um, there's a lot more that goes into cyber informed engineering, and I won't. I won't go too, too much deeper into that. Um, you know, happy to talk more about that later if we have time.

[00:17:36] But, um, the consequence driven cyber informed engineering is really the, the how of the cyber informed engineering, uh, uh, cyber informed engineering, or c i e I'll use that abbreviation just to save some oxygen. Uh, is, um, really the, what, it's a series of, uh, 12. Principles that really guide the thinking process of how we do engineering, like design simplification.

[00:18:04] That's not a prescriptive control, right? That's not like a N 853 or 802 18 or some other kind of prescriptive control. It's how do I think about my design so that I'm simplifying it so that I'm reducing the complexity and making things more secure? How do I engineer controls so that I fail? My term feel gracefully, right?

[00:18:25] Um, uh, consequence driven cyber formed engineering is a way to go through. It's essentially a four step process that starts with identification of the consequences. So this model is very much about, uh, reducing the consequences of failure. Uh, addressing the black swan style events, right, the things that an organization just can't survive or are so painful that they're gonna create massive, massive impacts for the organization.

[00:18:55] It's not about stopping every single last problem. You probably are gonna use a, a standard controls framework approach. to do the cyber hygiene, uh, aligned with a c i E style approach to really address the really important things, right? So it starts with consequence identification. Then it goes through systems of systems modeling, which is directly related to what we're gonna talk about with, you know, the bomb based threat modeling, right?

[00:19:19] And then doing some targeting. This thing like a red team exercise. Now that I understand what could go wrong now that I understand. Um, Uh, uh, how the systems relate to each other and all the system interdependencies, right? Like, I don't have to attack the system directly if I can attack one of your dependencies, right?

[00:19:37] Uh, now I'm gonna target these things. Now once I understand how they can be targeted, let's wrap this thing up with an understanding of what protections need to be put in place to make sure the bad guy can't create those consequences, right? That that's really what a c i u's all about.

[00:19:50] Chris Romeo: Hmm. Yeah, this is the first time that I've ever bumped into cyber informed engineering. And so I guess I have so many questions, but the first question is I. As I'm looking at this, it's kind of, it's, it's, it's housed by the Idaho National Laboratory. It's like a, kind of feels like it's, is this, is this a critical infrastructure only thing or is this something that we could apply to just generally creating products inside of tech companies?

[00:20:23] Tony Turner: you could, you could apply it in any environment. It's starting as a a critical capability for critical infrastructure. Uh, it was called out a doe, uh, issued a national strategy around, uh, c i e this last summer. And if you look at the, the US National Strategy document that was just released, uh, what you know, a month or so ago, uh, there is a call out, the c i e in there, but specifically around new investments in distributed energy, resources, green energy.

[00:20:54] All the, all the new solar and wind investment that's gonna be coming into the nation's infrastructure. Uh, so even, even the White House, uh, understands, uh, the need for c i e to be embedded in, uh, a new infrastructure. Now, the one thing I will say, the reason why c i e is, um, so important and critical infrastructure, not just because of the impacts there, because these are some of the most complex systems of systems.

[00:21:20] Kind of implementations that you see as opposed to many IT systems. I'm not saying they're not complex, many are, but I think we have a much more product-centric view of our technology universe inside the IT side of the house than we do on the OT side of the house. Um, so the principles can certainly be applied, but I, I think you wind up with more kind of traditional, uh, application security.

[00:21:46] Look on the IT side, um, and product security centric solutions. Um, it certainly makes sense to go down that road, but as an industry, we're really starting on the critical infrastructure side of the house. Cause that's where the need is greatest

[00:21:59] Chris Romeo: Makes sense. And ot, you mean operational

[00:22:02] technology.

[00:22:02] right, which is more just for those, for those people that don't know, that's, I think of OT as like the systems, networks and whatnot that are required. To operate the critical infrastructure. Is that a fair assessment of ot?

[00:22:17] Tony Turner: Yeah. The, the, the industry gets super hung up on, you know, is it cyber physical systems? Is it, uh, is it scada? Which is something else, but. Falls within that bucket of, uh, industrial control systems operation technology, um, from where I, from where I sit, tends to be a parent category to the industrial control systems that may include non-industrial systems, say in healthcare, uh, hospitals, and some of those, uh, some of those things.

[00:22:45] The way I typically define this stuff is, Compute systems that have the ability to impact our physical world. So that could be an i, that could be an iot, ot, an industrial iot device. Uh, you know, it could be, you know, the insulin pump, it could be, you know, it doesn't have to be a substation or a nuclear reactor, right?

[00:23:06] Um, that there's a lot of other ways that computers are starting to affect our day-to-day life and have the ability to affect physical, uh, and, and many times safety, uh, outcomes.

[00:23:23] Robert Hurlbut: Okay, so, uh, we already you mentioned about threat modeling and uh, that certainly. You a topic of interest for us. Uh, what's the role of SBOs in threat modeling that you see?

[00:23:37] Tony Turner: So, so at the sbam part of the conversation is a piece of this, right? When, when I, when I think about. . When I think about the exercise of threat modeling, one of the inputs that's required in order to threat model a system is to understand the system. If I don't know how the system works, it's really hard to understand how threats have the ability to impact the system.

[00:24:02] Right? Um, you know, primarily I'm looking at what are my opportunities to influence the system, interact with the system, um, an interface that I can talk to. . Um, maybe, maybe these are internal interactions that are driven by code. Maybe these inter interactions that are driven by machine learning or some sort of AI model, uh, that have, that can influence a system.

[00:24:28] That too is part of your threat modeling. Um, but I think traditionally we've been thinking about like basic network-based connections. , um, I have an exposed port on, you know, I have HTP serving up, uh, on 80 or 4 43. Like, what can someone do to that? Uh, what's the difference between an unauthenticated user versus an authenticated user?

[00:24:47] Um, you know, fast forward today's world where we have APIs all over the place, so you know, what kinds of APIs do, am I do, am I exposing, and what types, types of APIs am I consuming? Right? All of this has the ability to influence. The risk factors for, for, for a system, right? Uh, things are getting far more complex.

[00:25:05] I mean, you know, average applications are consuming, you know, tens or more. External APIs, maybe even hundreds of APIs or or more in some instances, and trying to wrap your brain around that can be really, really challenging. And so the industry has kind of coalesced around this concept of a SAS bomb or a software as a service bomb.

[00:25:24] I mean, think about the SBOM Sbam only describes a product or maybe even just part of the product, right? But if I have a SaaS application that's consuming 10 external APIs, Well, there's 10 other SBOs sitting behind those APIs right now. I think when we first started going down this road, we were thinking, whoa, SAS bomb is just gonna describe all the things.

[00:25:48] Wow. That is an unscalable monstrosity that will just unlikely to happen in, in, in the near future. Right? Like, are you really gonna coordinate your. Sbam between 11 stakeholders and have them all supply information so you can create this complete picture of the application. And oh, by the way, those guys, they're also consuming upstream APIs and, and on and on and on.

[00:26:11] So now a hundred vendors, a thousand vendors, I mean, it, it's just, it's an unscalable mess. Like it is never gonna happen. So the industry is kind of focused more on let's define what our software is interacting with. It's very similar to the concept of a threat model, right? And that the SBAM is really describing services, right?

[00:26:34] Services that are exposed or consumed, data flows, the directionality of data. Uh, what kinds of data, data classification even can be passed as part of this, uh, sas. Bam. Is it pii? Is it something confidential? Is it. Proprietary, is it open, whatever, um, is it encrypted? Is it authenticated? Um, all these things are really super valuable.

[00:26:56] In my mind, the SAS bomb is, sits at the core of this concept of using bomb data to threat model, and then SBOM winds up being part of that understanding. Obviously from a software standpoint, the HBO or the hardware bill of materials, you know, all the physical components that are in it. When I think about.

[00:27:16] When I think about an asset, I have a hardware base and I have software that sits on top of the hardware. And if I'm not looking at the system holistically, I may miss some critical risk factors for that. That asset is part of that overarching system. So when I can combine the software bill materials, the hardware bill materials, and the SAS bomb, um, and maybe multiple H bombs and SBOs along with the SAS bomb, then I started to get a very complete picture.

[00:27:46] How that system functions. Uh, and I can look at the individual risk factors and bring it all in and then evaluate things holistically to understand this. Uh, the good news is that even though we have multiple documents that we need to look at here, um, the, uh, s om formats have given us the ability to link these SPOs together, the concept of a bomb link.

[00:28:13] Um, uh, so. Now the tooling is not at the place today where we can do this at scale. I mean, we're very early days in, in the days of sbam and SaaS bombs, um, are kind of this conceptual thing that people are talking about and people are doing. They, they're certainly being produced by people, right? But if you look at the, um, supply chain product landscape, you're not seeing a lot of people asking.

[00:28:41] For SAS bombs and really operationalizing this need, uh, beyond a few very mature organizations that are doing this stuff today. Um, in my research, I've mostly been using the tools that are available and in many instances using manual process to stitch these things together. It, it, it's only, but it's workable.

[00:28:59] Mm-hmm.

[00:29:00] Chris Romeo: So when you think about, like, when we think about the process that we would go through to perform threat modeling, let's just use a SAS bomb as our, our core thing that we're looking at. Like you kind of, I, I'm gonna try to tease out a little bit what I think, I think I heard you say. Just make sure kind of that, that I'm, I'm spot on here. So I would use the SAS bomb and all of the other component pieces that it provides together. And then the threat modeling process is to consider the interconnections and everything that I can, I can take away from the SAS bomb to be able to derive a list of potential threats. Am I going in the right direction here from your perspective as far as how threat modeling fits into this?

[00:29:43] Tony Turner: Yeah, I mean, I have to start with a system understanding until I understand how the system fits together. I'm kind of spinning my wheels, trying to threat model anything. Um, uh, so not only understanding how the system works, but how the system is supposed to work. Um, what, what is it supposed to do, right?

[00:30:01] Um, how do, how do users engage with it? , uh, um, in normal operations and how, what are the potentials for bad actors to engage with this system in ways that are undesirable, right? But until I understand what the system is and what it's function is, how it's supposed to be operated, a lot of those things that are part of that core, Systems engineering lifecycle.

[00:30:28] Um, for instance, I, uh, I developed a, uh, security engineering maturity matrix, uh, that I open sourced actually about a week ago. Um, and we took the Department of Transportation's engineering lifecycle. , it's a pretty mature, it's a very water fallish kind of, uh, flow. Um, but again, I don't really care when this stuff happens, just that the stuff does happen.

[00:30:50] Um, and there's really not a lot of activity around security that needs to happen inside the engineering process, in, in that flow. So, um, we actually added. The threat modeling step as an important step that needs to happen after the high level design and before you finalize the final design. Cause I think that's really where in the process this happens, right?

[00:31:12] I have to have enough understanding to be able to threat model the thing, right? But I need to do that before I finalize the thing that I'm gonna build. It has to happened early enough in the process that I actually have the ability to influence the outcome of the system that I'm building.

[00:31:27] Chris Romeo: Now you also mentioned, um, there were some tools that, uh, you used as well as kind of manual processing of these things. Any tools you could point folks to that they could potentially use to, to try to perform threat, threat modeling of a SaaS bomb.

[00:31:44] Tony Turner: Yeah. So, uh, the first thing I'll call out, and I only touched on this very briefly on my presentation at S four, but, um, areas risk, which is one of my favorite. Threat modeling tools. Fantastic tool. If you know, if your, your viewers have not checked it out, I highly recommend checking it out. I'm a big fan of the work that they do.

[00:32:04] Um, they, uh, open sourced a threat modeling language, I don't know, a year or so ago, the open threat model, um, which is a really fantastic way to describe your threat models. And so when we can go from. , the data that's in the SBO to the description of the system, uh, in using open threat model or something else.

[00:32:24] That's, that's one potential option. Um, now I'm not aware of any tools that help you do that, right? You're gonna have to kind of stitch together your own solutions, which is why I like things like pie tm, which is a Python threat modeling. Um, , it's an OWA project. Um, and it too does not accept a bomb input.

[00:32:45] So again, you're gonna have to do some work to integrate your SBOs. But the do, the thing I do like about PIE TM is it, it does apply things like c w e categories, um, to evaluate those weaknesses in your software. Uh, and, and it's a, and it's. , it is a software based framework that can be pro, it can be, it's a standalone application, or it can be used as a library that you can pull onto your own software projects to, to do threat modeling as code.

[00:33:13] Um, that uses its own descriptor language. It doesn't use open threat model. Um, and so some of the work I've been doing is how do I go from bomb to p PTM to produce an open threat model document? Um, because that's gonna give us the best, uh, Uh, the best, uh, extensibility and translatability of threat modeling information so that I can use that document in another system, like areas risk or something else.

[00:33:39] Right. And, and I think looking at kind of these data interchange formats like otm. , um, and really kind of coalescing around, okay, as an industry, this is how we're going to communicate threats. Whether it's O T M or something else, I don't care. But I think we all need to get behind these concepts as an industry.

[00:33:57] Um, and even if you look at the SBO space and, uh, this concept, uh, Um, we'll go too deeply into this with the concept of a vulnerability exploitability document or, or, uh, vulnerability exploitability exchange, which is, uh, you know, around whether vulnerabilities are exploitable or are affected. Uh, the software's affected by a vulnerability.

[00:34:17] One of the biggest challenges the industry has right now, I think is just agreeing with each other on how we're gonna communicate this information. You know, these format wars occur, it's. Beta against v h s all over again as it comes to SBOs and vexes and, uh, like just, if we could just come to agreement on how we're gonna talk about these things and describe these things and adopt them across the board, we'll reduce a lot of complexity for people that are trying to incorporate these concepts into the program.

[00:34:49] Chris Romeo: So, uh, when, uh, I'm gonna, we had another question about Cyclone Dx, but I'm, so does Cyclone Dx, like what gets me a SAS bomb? Like, I've seen some of the tooling, I've played around with some of the tooling, um, that I think is also under the same heading of, of Stpr. It's, uh, projects in O osp,

[00:35:11] Tony Turner: Yeah. 

[00:35:11] Chris Romeo: generate SBOs.

[00:35:13] But that was really just like pointing an s pointing at a, um, You know, a node package file or something

[00:35:20] and then using that as input. But so like is SaaS bomb, is that something I have to stitch together myself or is that something that, like are there open source tools that will generate an a SaaS bomb for me?

[00:35:32] Tony Turner: I am not personally aware of any open source tools. That do this, but certainly there are many commercial tools, um, especially when you look at like the, uh, interactive application security testing space, like what contrast security does, um, because they're inside the application, they can see the calls the application is making.

[00:35:53] And remember the SAS bomb is around services. So I need something that understands how the application works, either because I'm living inside the application or I'm tracing the code flows inside the application through a static. Analysis vector. Um, so either you need to understand the code or I need to be inside a runtime or something in order to get that level of visibility.

[00:36:15] Um, there are some other vendors. I I, I talked to a company, I'm trying to remember the name of the company right now that I was talking to at RSA last year. Um, but they were, they were very focused on, um, Uh, securing APIs and this whole, like, um, I used to do a lot of work in the web application firewall space, which has kind of turned into wap, you know, web application and API protection space these days.

[00:36:37] Um, there's a ton of API protection vendors that are spinning up. Um, I haven't talked to too many directly, but I think that is where you need to be. That's kind of what you need to be looking at. , right to understand where these services are. Now as far as producing the SaaS bomb document from that, I'm not aware that too many of these folks are natively supporting SaaS bomb document generation inside their platform.

[00:37:04] So you may have to export data outside of that and then transform that data into a SAS bomb format. Now Steve tells me that there is some that he, he's working with some folks that are generating SAS bombs as part of their process, but I don't know if that's a manual process, if they've written some proprietary code to do it or if there's, uh, a commercial tool out there that I'm just not a, uh, aware of.

[00:37:27] Um, but again, this is still relatively new space. Um, if it's not out there today, we'll be out there soon.

[00:37:35] Chris Romeo: Okay, cool. So I guess, um, Tony from a key takeaway or call to action, um, I do wanna mention the, the book that you and Chris Hughes have written and, uh, let the record show Tony did not mention it. I did. And I'm one of the hosts, so I can mention books as much as I want. Um, so te just quickly tell us what the name of that book is and kind of when, when folks can, uh, can find that available.

[00:38:00] Tony Turner: So it's available for, uh, pre-order now on Amazon. It's called Software Transparency, and it has a long subtitle, which I always. Say incorrectly. So I won't try, uh, . But, um, uh, it, it, it's a great book. Um, in my opinion. Obviously I'm one of the co-authors, so I'm biased. Um, that covers more than just. Software bill of materials, SBOM we do have, we have a whole chapter on SBOM but it is not a whole book on SBOM we're really focused on the concept of software supply chain risk as a whole.

[00:38:35] How the industry is, uh, tackling it, how SBOM fits into it, how other attestations, uh, fit into this picture. Uh, the whole concept of vulnerability management. We got a whole chapter on, uh, both, uh, N V D as well as vex and, uh, You know, some of the challenges that the industry is facing and kind of the directionality of this, um, cloud DevOps and even operational technology, how supply chain risks impact legacy software.

[00:39:04] Um, cuz I, I, I think the industry at large is focused on what we're building today and forgetting that we have a whole bunch of stuff sitting out there that is very risky, that's not going away for the next couple decades. So how do we, how do we secure supply chains for that stuff as well? So,

[00:39:17] Chris Romeo: Hmm. Okay. So how about a, a key takeaway then, or a call to action, uh, for our listeners? You know, based on the conversation that we had here, like is there something, is there something our listeners should be doing, um, something you wanna point them to that they should be reviewing and learning and understanding to be better prepared to deal with these software supply chain and, and other supply chain issues, you know, into the future?

[00:39:41] Tony Turner: I think the number one call to action that I would have at this point in time, yes, we need better tooling. Yes, we need better understanding of execution, but we still have a lack of transparency and a lack of data to even do anything with. It's kind of one we gotta solve one problem at a time. Um, and in, in my opinion, the most important thing that we as an industry need to think about is embedding these practices into contracting, uh, and demanding this transparency from our suppliers.

[00:40:11] We can't wait for the regulations to come to us. We have to take a risk-based approach here and understand that this lack of transparency is creating a blind spot. In our, in our risk understanding. Uh, and it's very hard to make informed decisions when you don't know what it is that you're dealing with.

[00:40:31] And we've got to get, I've done a lot of work in third party risk management, supply chain, risk management, and by and large, the contracting process. , even if there is a third party risk management office, is usually extremely siloed from your security architecture and security operations side of the house.

[00:40:48] So we've gotta get these folks to talk to, talk to each other, and make sure that these requirements are embedded in these contracts. And we need the support of the business, especially for the, what I call too big to fail vendors, right? Like, You know, the Intel, Intel Specter, meltdowns a great example of that, right?

[00:41:07] Like, you know, are you gonna, are you gonna kick every computer out of your shop that has an Intel chip? No. Heck no. But we, we need to think about like, how are we gonna handle these risks? Um, and we need to have a. Concerted, uh, and collaborative plan and effort and execution strategy along with all the governance and other boring things that most of us cybersecurity people don't like to think about too much.

[00:41:30] But this is all important. This is how we affect change. This is how we're going to get forward attraction and get, uh, action out of our suppliers. Um, and then in parallel, we have to think about, okay, once we get this level of cooperation, what are we gonna do with it? and I think, I think another bigger conversation that we as an industry need to have.

[00:41:53] Uh, and I'm sure some people out there, some veterans out there won't thank me for making this point. But one of the questions that I think we need to ask ourselves is, does the consumer need the raw software bill of materials or do they need a trusted attestation? that tells them what they would learn themselves if they were to process these software bill of materials.

[00:42:18] Right? Because I think we're, I think we're pushing an awful lot of effort off on the end consumers that maybe they are not well suited to do. Now, you may not trust the vendor, that's fine, but what about a third party that this is the bread and butter. This is all I do. Do you trust them? I, I, I would hope so.

[00:42:37] Um, and I think that's probably, , and I'm biased cause I came from a vendor that did exactly that. I don't do it anymore. I don't have any, uh, you know, I, I don't have a dog in that race. But, uh, um, I think that's the right approach as an industry. We, we need to, we need to figure out where do we want to place our trust, right?

[00:42:56] Um, and do so intentionally, uh, do so, um, intelligently, um, and. Manage the expectations of what we're expecting to do as we're engaging with our supply chains and manage that risk.

[00:43:11] Chris Romeo: Very good. Well, Tony, thank you for being with us today and sharing knowledge and, and facts and information and stuff about SBOs and how threat modeling is inter can be interwoven in here. And you know, I'm, I'm glad I learned about the cyber informed engineering and consequence, consequence driven. I'm gonna go do some more digging into that, cuz now it made me start thinking about is there, are there principles here that we can apply? You know, just like you said, bigger, bigger than i c s. Can we, can we use these same ideas elsewhere? And, and you know, you're saying that yeah, you think we can, and so I think there's, there's an opportunity for all of us to, to learn some more about this and figure out how do we, how do we include this in the things that we're doing? How do we build better software as a result of understanding principles like this? So thanks for sharing that

[00:43:54] with us, and we look forward to having another conversation with you at some point in the future about some other topic.

[00:43:59] Tony Turner: Oh, thanks for having me on the show. Chris, Robert, uh, it was great. Um, I enjoyed our, our pre-show conversation as well as our on show conversation. Uh, love to chat anytime, so thanks 

[00:44:10] again. 

[00:44:11] Chris Romeo: Thanks Tony.