How to Assess Your Software Vendors' Cybersecurity

Dave: Hey. All right. Good stuff. Thanks everybody for being here. Really appreciate it. Dave: And it’s always exciting to get an opportunity to talk to the to the crew out there about, you know, some of these things that are obviously top of mind. Dave: Um, you know, I always sort of feel sometimes like I show up and I’m like, you know, it’s it’s the captain obvious scenario. Dave: I know, you know, we know that this concept of the software supply chain is a bigger deal than it ever has been before. Dave: But what I do tend to find, not only as a sands instructor, But as a consultant, you know, I’m out hanging out in people’s data centers in their office environments just like everybody else. Dave: Um, you know, I’m having conversations with lots of different stakeholders um, sort of across the board. Dave: And what I’m finding, there’s a couple really interesting trends. Dave: This is coming from my perspective over the past probably three to five years. Dave: Number one, um, this has got the interest of more and more stakeholders at higher executive levels in organizations um, than than a lot of topics have in the past, right? Dave: I mean, you know, if it’s not ransomware, It’s probably the software supply chain, but it’s getting everybody’s attention because there’s this sort of lurking lingering concern, right? Dave: This fear that do we really know what we’re running, right? Dave: Do we really know all the stuff that’s hanging out in our house? Dave: Um, you know, and and then the answer for most organizations, certainly for larger ones, is not really. Dave: We might have a sense of it. Dave: You know, some folks have a CMDB or you’ve got some inventory mechanism in place that, you know, you feel relatively confident about. Dave: out, but that’s only part of the equation. Dave: So, you know, knowing what you have, rock and roll. Dave: Okay, I have a good sense that I’m running this software, maybe this version. Dave: The the bigger concern uh it really comes in the form of thirdparty risk management because we’re starting to really, you know, wonder what’s going on in those software, uh, you know, development houses, right? Dave: What are they doing? Dave: Are they protecting the code? Dave: Are they protecting our data? Dave: Um, you know, are they protecting all of the things we need them to protect. Dave: Um, so I have a sort of a running joke and it’s a bad joke and it’s and it’s frankly a sad joke. Dave: It’s both bad and sad, but I’ve been, you know, I’ve been sort of looking at it as a, you know, as as a litmus test in the industry for a really long time, right? Dave: So, uh, as as the, you know, lovely folks at Prev stated at the beginning, I I teach for SANS and I have been since about 2005. Dave: And, you know, SANS typically has some of these really big conferences where there’s a lot of, you know, a lot of classes are being offered and it’s all you know it’s all good right so the the joke part of this is going to that conference right you go to a conference where you got you know three dozen available SANS courses you know it’s a huge conference it’s at like Caesar’s Palace someplace that’s massive and you go to this conference as either you know instructor or an attendee and you look and see you know we got a class on pentesting right like you know you know hack and slash your way through x y and z there’s 80 people in this huge ballroom right everybody’s there you know We’re hacking and slashing for the week. Dave: This is going to be awesome. Dave: And you know, you go to, you know, attacker techniques courses things. Dave: Yeah. Dave: Same thing. Dave: You know, big big rooms full of people. Dave: You go down the hall and there’s secure coding in.net and there’s like three really bored developers that are in this class. Dave: And you know, I I’ve I’ve seen this movie enough times to where I said, you know, this is why we can’t have nice things. Dave: Because, you know, it’s not to say that people don’t care. Dave: care about software security, you know, that it’s just completely, you know, an aside. Dave: That’s probably not the case, but it hasn’t gotten the attention until fairly recently that it probably deserves. Dave: And that goes across the board for not only our organizations, but the suppliers that are building the software that we’re then installing and making use of, right? Dave: So, thinking about this, right, the nature of most people’s environments today, and this is definitely a big generalization, you know, I’m I’m sure I’m speaking for probably all of us, you know, most of us where yes, you’re concerned about thirdparty risk. Dave: You have to be um I don’t know a single organization that does it all themselves. Dave: Nobody builds their own operating systems, right? Dave: Nobody builds all of their own software. Dave: You know, they certainly aren’t constructing their own hardware and the you know, things and components that are running on top of those. Dave: So, yeah, we have dependencies, right? Dave: We have a lot of things that we have to rely on just to function as an organization of whatever type that might be. Dave: And we’ve done that for years and years and years. Dave: There’s this big, you know, ecosystem of third parties and associated parties that we do business with, but I think we’re starting to look at them, you know, a little sidelong and say, hm, you know, what’s going on there? Dave: And software, software is at the top of the list. Dave: Um, you know, today it is all about software. Dave: Everything is software cloud services all software just running in somebody else’s house. Dave: Internally, we have new and you know, crazy software that’s being deployed very actively like the, you know, the screenshot here is actually just an illustration of things like DevOps pipelines. Dave: The minute you say we’re doing DevOps and we’re going to have a pipeline, you’re going to have like dozens of new potential software packages and things coming into the mix to facilitate streamlining and automation and you know secrets management and you know checking in container images and there’s so much that goes on there and what I tend to find a lot is that um you know this stuff is going on in the background irrespective of the security team’s efforts to at least gain some control around it. Dave: So the security team the risk teams may not even be apprised that all this software is coming in and being executed and running. Dave: And if uh you know my experience holds true, things that come in as experiments very often land in production before you know it, right? Dave: So, oh, we like this thing. Dave: We’re going to keep using it and now you have a new piece of software. Dave: So, this is a cyclical situation that we’re finding ourselves in. Dave: And it’s a brand new risk category that we have to start thinking about. Dave: I mean, typically when you talk about thirdparty risk, you know, it’s service providers, you know, it’s it, you know, it’s it’s a bunch of things. Dave: But it hasn’t really been focused on software specifically until somewhat recently. Dave: Right? Dave: So you have to ask this question, right? Dave: What is the software supply chain? Dave: The software supply chain essentially is is a, you know, supply chain that creates and delivers software from the conception. Dave: So it’s, you know, it’s up on a whiteboard before anything actually gets coded to the eventual stage where it reaches the end user. Dave: And it’s all the steps in between. Dave: For any of you that have been software developers or you’ve worked with soft ware developers or you’ve seen them uh you know on YouTube videos or something um you know there’s a bunch of steps in there so there’s the uh you know coming up with things on a whiteboard um you know there’s there’s the coding of the software there’s the building of the software which very often brings in a bunch of open source and a bunch of packages and other things um and then there’s the sort of finalization of that right you’re building it and then you’re fully packaging it up and ultimately at some point it makes its way off to you and everybody else but there’s those intermediate stages along the way where we know lots of things can hypothetically and potentially go wrong and what you always have to first ask when you’re dealing with software development practices is you know what’s the risk tolerance and what’s the stance and posture with regard to shipping now look shipping is very important for software teams right? Dave: I mean if it never ships what’s the point is this you know sort of the idea but I’ve seen a lot of concessions made we have made commitments to customers we got to get this thing out the door you know, but it’s got 74 huge bugs. Dave: Gotta get it out the door, right? Dave: And let’s make sure we fix that here as soon as we can. Dave: So, you make concessions, right? Dave: And and I’m not pointing fingers by any stretch of the imagination. Dave: I totally understand the need to deliver a product and to do so ideally on a in a timely fashion, but there’s a lot of checks and balances that need to be put into practice before that stage ultimately is reached. Dave: And the big question here to bring it full circle is what’s happening in those software supply chains that I don’t have any visibility into. Dave: Right? Dave: So, three main sections that are typically uh you know big parts of it. Dave: Again, the development. Dave: This is where you’re, you know, creating the software. Dave: It’s design, it’s coding, it’s testing, it’s, you know, some of the bug fixes. Dave: It’s distribution. Dave: So, it’s getting the software to the end user. Dave: So, it’s packaging. Dave: It’s the marketing stuff and delivery. Dave: You know, increasingly that’s not done by shipping you, you know, like shrink wrapped software. Dave: We all, you know, I remember those days where, you know, soft software was predominantly, you know, you you’d get it in the mail. Dave: or whatever, right? Dave: Or you you’d buy it in a store or something. Dave: Um, today not so much. Dave: It’s mostly coming through the internet. Dave: And then the consumption is I’m installing it, I’m using it. Dave: And of course, we all know that story. Dave: That’s not where we’re focused here. Dave: That, you know, we’re predominantly going to be looking at development, distribution, because those are the big areas that need the attention with regard to the supply chain. Dave: Once we’ve got it and we’re consuming it and it’s in use, yes, we’re sort of the end stage of the software supply chain, but the presumption is, you know, hey, I at least feel comfortable enough, that’s a big presumption, I know, to install this stuff and make use of it. Dave: The, you know, the challenge though, um, you know, the challenge is we’ve seen some really ugly stuff over the course of the past couple of years. Dave: Um, these are just some examples. Dave: Um, you know, and and some of you might know some of these better than others, but I mean, we’ve seen, you know, compromise at extraordinarily low levels. Dave: Um, you know, like digital certificates that are malicious that have installed in the whole, you know, shadow hammer debacle back in 2019. Dave: Um, you know, was a compromised manufacturer, uh, you know, like way back on the supply chain. Dave: Um, you know, not even directly upfront with where a lot of the software was taking place. Dave: You know, we’re talking back to like hardware manufacturers and things like that that are ultimately being compromised. Dave: Um, you know, we have some recent ones that are happening right now. Dave: Um, probably the biggest one, which I would say, you know, everybody here, I’m guessing, is at least somewhat familiar with may be intimately familiar with is the one that started off in 2020 with Solar Winds. Dave: Um, to me, Solar Winds, Solar Winds is sort of the gift that keeps on giving in in like a bunch of really negative ways for the most part because what it made us realize is that uh, you know, this is a big software manufacturer. Dave: I mean, I I think most IT shops, a fairly significant number of IT shops anyway, are using something from Solar Winds. Dave: I mean, I I actually started life as a network engineer and I did a bunch of network security I’ve used a bunch of Solar Wind software. Dave: It’s kind of everywhere, right? Dave: It’s one of those things e whether it’s like SNMP monitoring or whether it’s you know flow monitoring or you know what have you or just network management. Dave: It’s all over the place. Dave: It’s extraordinarily privileged and it’s got visibility into well maybe ostensibly everything uh you know at least at the network level that got popped right and we know this we know the story. Dave: So I’m just doing a quick rehash for those of you that might not know all the details about it but Solar Winds made us all go, okay, what the heck is going on here? Dave: Um, and and there were things that sort of followed along past that. Dave: There was like, you know, third and fourth party situations because of Solar Winds, managed service providers got compromised and that led to compromise of their customers too. Dave: So, there’s this whole ecosystem, right? Dave: It’s this big, you know, sort of uh, you know, like waterfall of bad things occurring as a result of one core infrastructure provider having a significant breach and compromise of their actual code. Dave: And looking into this, I mean, so many questions come up where you say, you know, number one, how did the attackers get in? Dave: Number two, how did you not notice that they had added malicious code into your actual software packages? Dave: Um, you know, these are all questions that I think we would normally want to ask if it had happened to us. Dave: I mean, if you know, if our software uh development house had been compromised, we would go and say, “Guys, what’s going on?” Dave: Right? Dave: How did you not have hash values for this stuff? Dave: Were you not doing any sort of checks? Dave: Um, you know, how did the privileges get assigned? Dave: There’s a lot of questions that go with that. Dave: But when somebody else has it happen and you realize it’s a, you know, it’s essentially a completely closed environment. Dave: You don’t know anything about Solar Winds. Dave: You don’t know anything about their developers. Dave: You don’t know anything about how they develop software and the, you know, the checks and balances and security controls that they have in place or don’t have in place. Dave: None of this. Dave: Um, it made us realize back to the point that this concept of the software supply chain is big. Dave: It’s a big big problem. Dave: We all use software, we all desperately rely on it. Dave: And if we can’t trust that the providers that we’re, you know, just taking something and installing from um you know, and in a case like Solar Winds, you know, you get a piece of software from them and they have a hash value, hey, check and make sure it didn’t get corrupted or isn’t bad, the hashes match because, you know, the the compromise was so deep in their environment that it was just part of the software development practice itself. Dave: If something’s that deep, you got a big problem on your hands and there’s not much you can do about it, you know, on the surface other than say, okay, what do I now need to start doing to go ask these questions and figure out what my providers are actually up to within their own environments, right? Dave: So, where do these attacks fit? Dave: And and just to sort of tie some of this together, there’s all sorts of places in a software supply chain where different types of attacks and different stages of attacks could hypothetically take place. Dave: So, even in the early design phases. Dave: You know, you might have one of your developers that’s completely compromised. Dave: I mean, what we actually see a lot today um and we’re probably going to continue to see is not even so much always efforts to, you know, disseminate compromised software. Dave: That’s one factor here. Dave: Another big one is a desire to steal and access intellectual property. Dave: So, if I manage to compromise at an extraordinarily deep level some of the developers in huge software development environments like Apple uh you know or or you know or Microsoft or you know who knows name name a huge software provider right? Dave: I mean you can come up with whoever you want but if I manage to compromise at that deep level and I’m basically just hanging out I’m an attacker that really is not interested in you know like making waves making my presence known in any way shape or form I just want to steal. Dave: I just want to take things and surreptitiously you know sort of slide them out the door when nobody’s paying attention. Dave: And if I can compromise the developer that are doing the design work long before any code even hypothetically gets written. Dave: You know, if I’m a competitor or if I’m a nation state that, you know, likes to steal because there are a few, I might develop something and release it beforehand. Dave: I, you know, release a knockoff or I’ll try to beat them to market. Dave: And this kind of stuff is happening all the time and it’s going to continue to happen. Dave: So, it doesn’t mean just by virtue of one of your software developers getting compromised that you’re going to get compromised. Dave: It just means there, you know, there’s all sorts of theft and criminal activity going on. Dave: in a number of ways. Dave: Now, you flip that into the actual compromise situations, you know, how low can you go is the question. Dave: And uh as we’ve seen with, you know, again, things like Shadow Hammer with the certificates, with some of the infrastructure, you know, like drivers, you know, getting down into drivers that might need to be updated and installed for some types of software to work, you know, getting down into software development kits. Dave: This happened at Twilio. Dave: Um, you know, getting into your software repos where, you know, you got packages and you’ve got libraries and things like that. Dave: You know, the list goes on, right? Dave: The list goes on and on and on and on and on. Dave: And so, I guess if you had to sum this up, it’s hard. Dave: So, really locking down and fully securing your software development infrastructure and environment in all phases, in all places takes definitive focus and effort. Dave: But it doesn’t mean that we shouldn’t be trying. Dave: And you know it and I know it. Dave: And really what we need to know now is whether our software developers and the uh third parties and companies that purchasing this software from know it as well and they’re taking actions to do something about it. Dave: So again, here’s Solar Winds. Dave: It’s the example that keeps on giving. Dave: You know, 2020 this attack, you know, attackers corrupted the Solar Wind software update process. Dave: Uh it was detected in December, but it, you know, it had been going on for a minute. Dave: And so we always, you know, sort of use that date and time stamp like, oh, yep, December 2020. Dave: But it had been going on for quite some time. Dave: Um, you know, there were thousands and thousands and thousands and thousands of customers that were impact uh impacted by this and really you know what a horrifying realization that is to say okay you know I’ve got this software it’s been running in here for months and it has access to a lot and it has privileges that are pretty extensive in order to facilitate the network monitoring and control that it does and it’s and it’s owned um you know and and you don’t know who it’s owned by you don’t know much about the campaign you don’t know the attackers’s goals you know and maybe you didn’t even notice that there was anything going on in your environment. Dave: But sure enough, because of the level of access most Solar Winds infrastructure had, you now have everything sort of suspect within the core parts of your data center. Dave: Not a great feeling. Dave: A lot of uh clients that I work with were in that position. Dave: Some of you might have been in that position. Dave: It It’s a pretty bad one, right? Dave: And like I said, it’s the gift that keeps on giving. Dave: Not so much because hopefully we’ve got all of our environments cleaned up by now. Dave: I’m hoping I’m hoping for everybody. Dave: It’s more so because it got everybody’s attention. Dave: Um, you know, executives like, “What do you mean we’re owned? Dave: We have all these security controls and security capabilities in place, you know.” Well, there wasn’t much we could have done about it because it was coming from one of our providers, right? Dave: It was coming from a provider and we trusted that provider and and maybe the right answer is, you know, should we have trusted the provider? Dave: Um, but how do you just, you know, how do you just not trust everybody, you know, other than just unplugging yourselves in in your entirety? Dave: and going and living in a cave or something, right? Dave: So, uh, you know, um, and a question just came in. Dave: How do you how do we inspect, review, audit the software value chain at any given company to support them on any exposure they may or may not have? Dave: Hold that thought. Dave: Um, I’m actually going to talk about this uh, as well. Dave: So, just, you know, yeah, give me give me a little bit and I’ll talk about some of the things that we should be thinking of and thinking about trying to do as we go along. Dave: So, it is not all doom and gloom. Dave: Um, too many of these webinars tend to be extraordinarily doom and gloom. Dave: I’m still in the doom and gloom phase of this webinar incidentally, but I will attempt to move towards a more optimistic outcome here in just a moment. Dave: Um, so there we go. Dave: Right, we’ve got this malware. Dave: It’s coming in and now of course we’ve got infected DLS. Dave: Things are bad and boom, there you go. Dave: Okay, next one. Dave: Log before shell. Dave: It’s another gift that keeps on giving. Dave: And this one in a totally negative way because it’s quite frankly still giving. Dave: Um, it’s everywhere and it’s just one of those things. Dave: I mean, we should know better. Dave: I mean, Look, some of you might remember hearkening back to the ancient times of, you know, gosh, what was it, 2008 or nine or 10, I don’t know, I’m old, but uh, you know, way back in the day when we basically realized that every vendor on the planet was using OpenSSL, right? Dave: They’re still doing it, but OpenSSL was just manifest. Dave: It’s everywhere. Dave: You know, no vendors are writing their own, you know, SSL termination and connectivity frameworks and libraries and packages. Dave: They’re going and grabbing a bunch of open source stuff and it turns out that there were major bugs, right? Dave: So huge bugs all of a sudden you realize it’s everywhere. Dave: Log for shell feels like that one. Dave: It’s a logging framework for Java. Dave: Uh you know just a little bit ago, well I mean 2021 so that’s still relatively recent. Dave: Um you know we had a big vulnerability and it was everywhere and it’s still everywhere and so basically you know now we’re we’re tasked with going out and desperately trying to build some detect mechanisms you know looking for these LDAP queries and you know messages and things coming in because this was pretty nasty. Dave: It is still pretty nasty. Dave: In fact, I know some clients um for reasons that have been unable to, you know, completely replace this or patch this stuff. Dave: They know they have those problems and they’re having to build ancillary controls and compensating controls just to try to prevent themselves from ultimately being compromised, right? Dave: Like locking this stuff away, knowing you’re, you know, unsafe. Dave: And I’m quite sure there’s plenty of other folks in exactly that same boat. Dave: But back to the point, where is this stuff in your software development uh companies and providers house? Dave: This is happening all over. Dave: It’s not just the software developers and manufacturers. Dave: You know, it’s us too. Dave: Um you know, we’ve had different types of data breaches from third parties in some of these development infrastructure environments. Dave: Um you know, Sentinel One packages uploaded to uh you know, basically the the Python package management environment. Dave: Nasty, right? Dave: So Sentinel one I mean Sentinel one is an EDR tool. Dave: I mean this comes all the way back full circle to security platform. Dave: security tools, you know, can you trust those? Dave: I mean, if you can’t trust the security tools in your environment and some of the packages that are going into, you know, software development kits there, what can you trust? Dave: And I’m not, again, I’m not pointing fingers. Dave: The Sentinel One folks are great, but this stuff is everywhere. Dave: Everybody’s got online repositories. Dave: Everybody’s making use of things like cloud storage and other types of things. Dave: Um, you know, the pipeline is complicated. Dave: Uh, you know, I always laugh when I first started getting into the realm of cloud and, you know, working with DevOps teams and things. Dave: I think there was this impression that ah we’re going to streamline this thing it’s going to be automated and it you know sounds good but what you ultimately end up in the realm of devops and cloud you got a lot more software and there’s interconnections across it and there’s APIs that are now open and it doesn’t always get easier and especially the surface area that is accessible and potentially open to threats often grows much larger and uh does so quickly right so look um you know Gardner does always agree with me. Dave: I don’t always agree with them, but last year I will say, yeah, they they certainly nailed this one down and and actually called out the software supply chain as part of their uh digital supply chain risk and said, you know, look, it’s not just supply chain, it’s very much all the software that’s flying about in the ether that, you know, you’re using, they’re using. Dave: And you know, the thing about software manufacturing is that, you know, you’re buying something from Oracle or you’re buying something from Microsoft or buying something from you know insert vendor here they’re going and grabbing stuff online they have other vendors I mean it is a multi-entacled hydra this whole concept of software supply chain and it touches everybody so you don’t even know who they’re procuring packages from or who’s building things um you know in what ways in some of these other places can you imagine the number of vendors that Microsoft has on their list of third parties it’s staggering it’s huge they’re not developing everything completely from scratch. Dave: Why would they? Dave: They’re using a bunch of stuff. Dave: They have other providers. Dave: They’ve brought stuff into their house. Dave: I’m not picking on Microsoft. Dave: I’m just saying, look, it’s a huge software company and they have all the same problems just like all of us do. Dave: So, you know, it’s a big deal. Dave: What to do, right? Dave: So, of course, like I said, we want to pivot a little bit away from the, you know, ah, sky is falling. Dave: Um, you know, what do we start doing to think about this? Dave: And I think there really are two fundamental questions. Dave: I’m not trying to oversimplify this, but I think there’s two big things that we need to sort of drag out into the uh into the light and say all right you know what am I looking at here I mean first is you know what’s what’s at risk in my house right which of my products are at risk um you know and of course what are the mitigation measures there’s a lot of things you could start sort of start this conversation with I mean first off you’re guessing right like which of my products are at risk what I might do is say all right you know what’s the maturity of the vendor right like how uh well known are they and then somebody’s going to go but what about Solar Winds Dave weren’t they a mature respected vendor and yeah okay fair point right so but I would look there uh I would look to see whether I had any information about those vendors whether they had supplied me with any risk mitigation measures and security controls and processes and policies that they had internally many of them don’t right so you go across your 173 software companies that you have things working in your house uh right now right um maybe seven of them have given you some details about their software development practices um and of course being mildly sarcastic, but it does feel like a pretty slim picking situation. Dave: What do you do to mitigate? Dave: So, security advisories. Dave: Yeah, I mean, you know, it’s a good idea. Dave: Um, you know, it’s a good idea to keep track of this stuff and make sure that you’re apprised of any vulnerabilities that are being published, uh, any sort of major attacks that are coming out. Dave: Some of this is like a threat intel situation. Dave: Um, you know, but to to be fair, uh, I know a lot of clients that don’t even know who the software owners are or the application owners are. Dave: are in their environments. Dave: And even if they do, there’s a good chance that those people are busy with their day jobs and they’re not out there really even paying attention to some of this stuff, right? Dave: It’s I mean, and again, I’m not pointing fingers. Dave: It’s just the nature of how these things work. Dave: I bought this thing to do this thing. Dave: It’s over here running. Dave: Um, you know, if they have a big problem, is somebody on that mailing list? Dave: Do you know? Dave: So, again, yeah, lots of stuff. Dave: I’m asking the vendors, and of course, I’m laughing at that because the vendors themselves have, at least in the past, not been wholly forthcoming about uh you know, whether things are going on. Dave: And I mean, look, a lot of vendors aren’t aren’t really keen to come right out and be like, “Ah, yeah. Dave: Yeah, we really suck at security. Dave: We’re terrible. Dave: We’re working on it though, right? Dave: I mean, no, nobody’s going to come out and say that right out.” Dave: So, how do you ask the questions? Dave: What kind of investigations can we do? Dave: One of the things that start has come up recently is this, you know, concept of using, you know, a uh, you know, basically a software bill of materials. Dave: But, you know, of course, I’m I’m being facitious here. Dave: Good luck. Dave: We got a a lot of software. Dave: You know, this is not easy. Dave: This is not an easy thing to tackle, especially if you’re trying to do it peacemeal. Dave: We’re going from vendor to vendor to vendor and, you know, trying to find out how to contact, trying to find your app owners. Dave: Um, you know, how do you start g getting a handle on this is basically the question. Dave: I would say the first thing, and there’s a lot of conversation going on about this out in the industry at the moment, is, you know, hey, um, you know, what what can we get from them? Dave: What kinds of things could we potentially ask for? Dave: The software bill of materials is a great idea. Dave: Um, and personally I think this is a great idea for vendors to have as well because it allows them to have a more complete tracking of all the components and the libraries and things in the first place. Dave: I I think that’s a good idea. Dave: This is your product. Dave: You are creating this thing. Dave: Um, you know, it makes sense for you to have a really accurate and up-to-date uh, you know, kind of kind of chronicle of everything that’s in there so that you know when you need to update things and and ultimately what we’re asking for with this software bill of materials is for them to provide that to us, you know, as the consumers of the software to say, “Hey, look, if I ask you for your software bill of materials or your sbomb, if you prefer, um I I need to know I need to know whether I am at risk by using your software.” Dave: Um that doesn’t mean you’re giving me uh you know, deep dark secrets. Dave: Um you know, doesn’t mean that you’re giving me some intellectual property or something that I could use against you. Dave: What I’m doing is trying to assess my risk surface. Dave: Um, you know, that that’s really the big question. Dave: So, going back, you know, log 4j came out as a critical vulnerability in December of 2021, but I had a lot of folks that went, do I even know how do I know that I have this anywhere? Dave: Right? Dave: Do I have any software running that has this in there? Dave: It really fell back to that same conversation of, you know, looking at, you know, things like OpenSSL and then coming to the realization that essentially all of your vendors had used it. Dave: I we don’t know how many uh are using log forj and have those libraries and components and dependencies and pieces in place. Dave: If somebody had been able to provide us with an sbomb and had had this in there, we would have been able to go consult it, known we had it, and then taken a pro, you know, some mitigating steps thereafter to at least prevent this from being actively exploited. Dave: Okay. Dave: Hey, this stuff lives over here. Dave: Let’s, you know, ratchet up the monitoring if nothing else to see if we start seeing illicit activity or unusual or unward behaviors that could be indicative of something bad happening in our environment or, you know, something attempting. Dave: be bad happening in our environment. Dave: Right? Dave: So there’s numerous formats and this is still actually what this shows you is that this is still in flux. Dave: Um so the question came in is it possible to quote unquote audit an SBOM? Dave: Um well this is how you would go about doing that. Dave: You would have a parsing mechanism of some type that could facilitate going through the you know the bill of materials and and basically you know trying to to validate what was in there uh at all. Dave: But at the same time um you know you might have different formats from different providers and we’re still trying to find the format that everybody could sort of uh adhere to and make use of. Dave: I don’t know when that’s going to happen. Dave: To be candid, this is a pretty new thing that’s emerging at the moment. Dave: Um SPDX is a little heavier version than Cyclone DX, but it’s also driven by the Linux Foundation and it’s got a lot of really good details and things in there as well as security references. Dave: There’s more security references and um you know like attributes and things and SPDX than Cyclone DX. Dave: So, I you know, sort of have a little bit of a preference for it, but um you know, again, it’s neither here nor there. Dave: We haven’t decided on any of these things as a uh you know, if we want to call it a standard. Dave: We haven’t seen that necessarily emerge. Dave: There’s some initiatives underway, right? Dave: So, this is where I I start pivoting from the doom and gloom off towards the hey, people are starting to pay attention. Dave: Now, look, I’m going to be the first one here. Dave: You know, some of you might be feeling the same way I am. Dave: I’m not going to wait for the government to save me, right? Dave: That could be a long wait. Dave: Uh, you know, if we’re waiting for them to get it all figured out and uh, you know, tell us exactly what we should do. Dave: And of course, again, my sarcasm is only coming out because these are slow processes. Dave: I’m extraordinarily happy to see that there’s some effort here happening. Dave: Um, you know, I think, you know, take politics out of this thing, right? Dave: I don’t care who’s president. Dave: I don’t care who’s in Congress. Dave: Everybody is going to start paying more attention to software and I think a lot of that is being driven by, you know, attacks against critical infrastructure. Dave: Um, you know, there nobody’s sleeping on this thing. Dave: So, you know, the the the fact that, yeah, they’re they’re at least um, you know, putting some executive orders out there to improve cyber security, not only for the nation, but for everybody. Dave: Um, part of that is enhancing the software supply chain. Dave: And so, the minimum elements of an SBOM are basically provided as a result of this. Dave: So, if you haven’t ever seen this one, it’s freely available. Dave: And might make some sense to at least get a sense of, you know, kind of what they’re uh what they’re including and what they’re saying. Dave: But I wouldn’t leave it wholly in the, you know, in the hands of the government. Dave: I think there’s a lot more uh, you know, to to sort of bring into the mix on this um, as well, right? Dave: I think I think the the industry is is probably going to come up with solutions and answers uh, more so before um, before the government says this is the answer, right? Dave: I think they’re still trying to figure it out, too. Dave: Now, we have lots of other things starting to align here. Dave: Because ultimately since we’re talking about software and we’re talking about software packages and we’re talking about software components, what we’re also talking about is means by which we can discover and validate that we may or may not have vulnerabilities. Dave: That has been a big problem. Dave: In fact, that’s a much bigger talk talking about essentially the notion of vulnerability disclosure, how we get that vulnerability disclosure, how we talk about advisories, how we keep ourselves apprised of this stuff, the list goes on and on. Dave: This is an ongoing debate in the security industry and Well, this is a cool effort um on the part of Oasis, the common security advisory framework, which has not once again been wholesale adopted as a standard by any means, but this is a parsible JSON formatted version of an advisory model that includes things like ESBOM attributes, right? Dave: So, it’s built to be automated. Dave: Now, are there a bunch of amazing tools readily available for you to go and just like voila implement the SE, you know, CESAF as we call it? Dave: um and make sure that you have a constant feed that immediately updates you on everything? Dave: No. Dave: Right. Dave: There’s just not there’s not a ton of this. Dave: It’s still very much emerging as we speak, but we got to pick some standards, right? Dave: We have to have things that can feed in and basically say, okay, software bill of materials. Dave: Here’s all of the pieces of that. Dave: And so, we’ve got components and elements of the software that then feed into the SESA to say, you know, what’s the current state of vulnerabilities and threat surface management related to all of those. Dave: So, we got to start aligning some of these things. Dave: Here’s something new, right? Dave: So, the open software supply chain attack reference, something that just came out relatively recently, in fact, to help start taking the attack models and bring them to this. Dave: So, again, this is fairly new. Dave: I haven’t really seen this take off, you know, again, kind of in a wholesale fashion, but I like it. Dave: I mean, you know, every one of you right now, I mean, me, you, all of us can easily point over to the folks at MITER and say, “Haha, MITER attack.” Like, you know, now there’s all these versions of MITER attack. Dave: you know, fantastic stuff. Dave: That’s great. Dave: Well, we didn’t really have that for the software supply chain attacks. Dave: We just didn’t, right? Dave: They they kind of were in there, but they weren’t as specific as I think we’d like them to be. Dave: This uh this Oscar uh project is really an effort to sort of shore that up and basically put it into that same structural model that we’ve seen uh you know with the MITER attack framework. Dave: So whether this will take off or not, don’t know, right? Dave: I think it’s pretty cool and I’m glad to see that there is some definitive emphasis on this coming about in the community, people coming together saying, “All right, look, we really need to start, you know, looking at this supply chain and bringing in reconnaissance and resource development and execution and persistence mechanisms.” Dave: And this goes right back to some of those examples that I was giving earlier. Dave: I mean, some of these things were really deep. Dave: Could we have known? Dave: Right? Dave: So, you know, and that’s always the lingering question. Dave: I wouldn’t blame Solar Winds for not ever, you know, talking about this, but could they have known? Dave: You know, what what could they have found or what could they have looked for that showed them that they for getting targeted right before the attack ultimately took place and everybody got popped? Dave: You know, what could we have known and what could we have done differently? Dave: And I think having a framework like this facilitates that, right? Dave: That’s really all we’re talking about doing is is sort of facilitating that in some way, right? Dave: So, here we are, right? Dave: What do we do to assess our own software supply chain? Dave: Looking inward, starting to figure out where we stand and what we need to be doing about all of this. Dave: You know, I would say um you know, number one, you know, get an inventory. Dave: I mean, you know, there has to be a real concerted effort to start compiling a list of your services and a list of your software um and and basically start finding out about the vendors themselves and you know looking at your own development components. Dave: That’s of course uh more of a discussion around software security and securely developing software but sure there’s you know there’s industry frameworks to help sort of build a plan. Dave: Um some of you might adhere to you know CIS controls for you know locking everything down. Dave: Um you know there’s the Nest cyber security framework. Dave: There’s Kobet, there’s high trust. Dave: I mean, I I’m not espousing or uh you know rejecting any of these. Dave: I think you use what makes the most sense for your overall you know your plan related to security posture and by extension thirdparty risk. Dave: But you know ultimately there’s got to be something that helps us. Dave: This is pretty cool. Dave: Um you know so this is actually something that came from the cloudnative computing foundation um that I thought was really really good. Dave: There’s some really cool interesting um you know like software risk analysis tools and methods coming out and so this is just one example for you um you know with the open uh software foundation it I’m not saying you should absolutely latch on to this but if I’m looking at hey you know number one what do I need to do in-house to protect my software and my developers and our code but maybe you know by by extension um you know what do I need to be asking these people right? Dave: So, you know, what are the things that I need to be going to those developers and those software companies and saying, “Hey, are you doing these things?” Dave: Right? Dave: And so, here’s just a quick snippet from the table of contents here. Dave: Um, you know, securing your source code, securing all the materials and the build pipelines and any of the artifacts, um, you know, your deployment strategy and your deployment pipeline, uh, your packaging mechanisms and ensuring that you’re validating and ensuring that, you know, none of the packages are vulnerable. Dave: Um, you know, etc. Dave: And all of those things need to be done by every body. Dave: I find a lot of security and risk teams that, you know, they’re just not this is not where they come from. Dave: They don’t come from software development backgrounds. Dave: Uh, you know, they’re trying to figure this out as they go along. Dave: And so, I think anything that helps move that needle a little bit down the road, we should we should be taking into account. Dave: Um, take a look at your third parties. Dave: So, it’s not just software because some software might be open source, right? Dave: You may have software running in your house right now that doesn’t have an associated third party by any means other than the community, right? Dave: ah you know who do I who do I blame if it’s terrible right kind of stuff but look lots of open source running in people’s environments these days you know you don’t always have somebody that you can sort of you know pin the blame on but anything commercial period you need to start bringing them into the risk review process and say all right look you know what are the controls that we need for them to demonstrate compliance I want source code analysis right I want to make sure you’re not writing crappy code right I need package analysis I need library analysis. Dave: I need container images that you didn’t just go and download from Docker Hub uh without doing any validation on them. Dave: Right? Dave: I need some limitation of privileges related to who can get to what wherein your environment and I need to make sure that at all of these various phases, you know, you’re doing gut checks and that securityurities involved and that there’s audits and reviews. Dave: I need all this. Dave: So, yeah, you got to put together a list and figure out, hey, how often do I need to talk to them? Dave: That could be driven by compliance, could be your own internal standards. Dave: That’s more of a generic thirdparty risk assessment viewpoint ideally having an always on model right so you you get some information from them you keep it within a system and then you don’t have to go oh my gosh put it on the calendar let’s go do a review of company X now you have some platforms and things that can help with that and of course what happens if they give you answers that are unsatisfactory or what if they give you nothing at all how do you handle that that’s probably a question better left for executives and some of the folks that are you know basically either acknowledging or accepting the risk in the case that they don’t get what you need. Dave: That’s something that, you know, probably needs to be had at a larger governance level than Dave telling you, hey, this is this is the best approach. Dave: Um, what should we require? Dave: I need to know about the security of the software and I need to know the ability of developers and providers to remediate, right? Dave: Those are big issues. Dave: In other words, hey, if I find because maybe you gave me an ESBOM that you’ve got some packages in there that just got a huge notification out of the industry that there’s a problem. Dave: What are you going to do about it? Dave: Are there SLAs’s? Dave: Is there an expected time frame for turning that around? Dave: What do I need to do in the meantime? Dave: How do I protect myself? Dave: I think it’s incumbent upon the software developers to help you with this. Dave: And to date, there hasn’t been a heck of a lot in the form of support and advisement in that regard. Dave: It’s oh my gosh, best effort. Dave: You know, we’ll wait on a fix. Dave: Great. Dave: Um, so yeah, you get a gold image from the manufacturer, but you know, in the case of somebody like Solar Winds, you thought it was fine. Dave: It wasn’t fine. Dave: So, we need a little bit more introspection and visib ility into those earlier stages of the development life cycle. Dave: I think you know controls that we have in place compartmentalization you know I want to make sure that if for instance some of the software we’re using or software developers that we’re working with have access to our information I need to know that you’re keeping it isolated I need to know that you’re protecting the source code I need to know that you’re doing change monitoring I need to know that you’re controlling secrets and privileges and uh you know this concept of package vulnerability management absolutely is something that needs needs to be discussed and it needs to be openly discussed and there needs to be some disclosure with how that’s being controlled and facilitated within any of the manufacturers and service providers that you’re making use of. Dave: Right? Dave: So obviously don’t use risky providers. Dave: Um you know I I love the concept of like supplier risk ratings and some of these um but they’re not infallible, right? Dave: So if you get somebody that’s just definitively shady, you know, somebody’s up in the high severity risk range um you know we’ve seen a lot of things coming from them like for instance if they get hijacked and you you know you start seeing stuff out on the dark web or you start seeing things like fishing emails emanating from their domain like you know ah panic um yeah they’re going to get a worse risk ranking but you know again going back to some of these really reputable providers they’re they they looked good on paper right so you can’t always trust this um you know for all we know right now Microsoft could be completely compromised I don’t think it’s happening right as an example but but you don’t know I don’t know we don’t No. Dave: And certainly um you know we we hope that they’re not but you know pretty much everybody’s running their software regardless. Dave: So start looking at the procurement team processes how vendor review is initiated you know how we’re looking at contract terms. Dave: You know I think there’s a lot of this that’s just bigger picture thirdparty risk. Dave: What I’m really advocating for is ensuring that software manufacturers and providers are in the mix on this stuff. Dave: Right. Dave: A lot of people have you know really had third-party risk very narrowly focused around maybe a select group of service providers, you know, cloud providers and stuff and that’s fine, but I think we need to broaden that, right? Dave: I think any any software you’re running that can touch sensitive data or is uh potentially able to uh gain privileges and and so on. Dave: Start there, right? Dave: Start with the stuff that’s closest to the sensitive data and people and then work outward from that point. Dave: But they need to be incorporated and and brought into your thirdparty risk management. Dave: uh you know scenario. Dave: So there’s a lot of room to grow here. Dave: Again, we need more transparency from providers uh you know and the suppliers of software. Dave: I’m very bullish. Dave: I think you know that that esbombs are going to take off. Dave: I think you’re going to start seeing people basically demand these things. Dave: Um and eventually that you know the software companies will get in line and start helping and providing some of this at least you know the good ones will. Dave: But I think you know given this the sheer breadth of software that we tend to run I don’t think you can do this manually in a spreadsheet. Dave: Seriously. Dave: ly, right? Dave: I mean, all those different efforts that I I sort of highlighted and said, “Hey, look, it’s getting better. Dave: There’s some efforts, right? Dave: Oasis is out there doing some stuff. Dave: You know, we’re starting to build on on some of this stuff.” Dave: Um, but I don’t think you can do it easily. Dave: Even even small organizations might have a ton of different software. Dave: So, I think it’s much harder to sort of try to keep up with this stuff uh and keep pace in a manual fashion. Dave: Uh, but, you know, it’s like I said, we’re still in fairly uh early stages at this point. Dave: So, You know, time will tell. Scott: Awesome, Dave. Scott: Uh, thank you so much for uh for the presentation today and for the insight and the best practices and more uh that uh that you offered to the group today. Scott: I just want to take a couple of minutes and review um what prevalent can do to help simplify the assessment of your thirdparty providers, including your software providers. Scott: Next slide, please, Dave. Scott: You know, as Dave said this is an exercise in just having better discipline over third party risk management and including your software providers as part of that population of folks that you’re that you’re working with isn’t necessarily a separate exercise. Scott: It’s a conjoined exercise where you’re assessing the relative security strengths and weaknesses of pretty much any entity that you do business with whether that be a critical software provider or you know a cloud hoster or you know any other type of uh you know vendor that you’re off offloading work to and throughout that process, customers continually tell us that they want to achieve three things. Scott: Number one, get the data they need to make good decisions on whether or not this particular provider or software vendor or whomever uh has the right security controls or whatever in place and kind of sifting through all of that data. Scott: Second is getting everybody together lined up in the enterprise around a single set of processes and uh um procedures. Scott: and and data kind of knocking down the silos to get everybody singing from the same handle and then third expanding that out and doing that across the entire vendor ecosystem uh that you know that they’re currently doing business with software providers and others. Scott: Next slide please Dave and as he mentioned a few minutes ago kind of the biggest thing that kind of gets in the way of that is um the usage of spreadsheets. Scott: You know we did a study uh of the industry last year and it showed that 42% of companies are still using spreadsheets to manage thirdparty auditing and then controls, identification, and enforcement. Scott: Slightly fewer than half are using outdated information and not not real-time intelligence into the vendor risk. Scott: You know, as Dave mentioned a few minutes ago, it’s not just enough to do some sort of assessment. Scott: It’s keeping a continual focus or visibility into the potential risks that are um maybe pop up in between those those uh those software assessments. Scott: And then third, the kind of the other big challenge that companies face in trying to solve the problem besides the manual nature of it all, the need to kind of pull data together and keep it real time is to satisfy all the different cooks in the kitchen. Scott: You know, I grew up on uh in farm country and, you know, the phrase that we would use then was, you know, if you have an awful lot of hands on the plow, that plow’s not going to go anywhere. Scott: And so you need to have a single set of data, single set of processes, tools, and systems that, you know, is guiding the the plow if you will in the right direction to make sure that you know you’re not going in all these different directions. Scott: This is kind of the the typical challenges. Scott: Next slide please Dave. Scott: You know what we seek to help address is third party risk at every stage of the third party life cycle. Scott: So we look at risk holistically. Scott: You know that includes um kind of understanding the risk that a potential vendor brings uh to you. Scott: So wanting to see you know a SOCK 2 report or some certification or sorry ISO certification that says that they have the right software development practices in place, the right security protocols in place and then attesting that against the evidence that you find from doing kind of external monitoring scans to validate those conclusions and the presence of controls at the inboard or intake and onboarding stage. Scott: Um you know it’s about simplifying that process and getting everybody together in the same contract uh and due diligence process so that once that vendor is on boarded, you’ve got some direction on areas that you need to drill down deeper on as that relationship progresses. Scott: And part of that naturally is scoring some inherent risk or understanding the different criteria, you know, the criticality of the software provider, for example, or whether or not it touches client-basing processes or houses client data that you may need to um u you know, have a picture of to help, you know, set set a future, you know, direction on assessment, executing the assessment and remediation process. Scott: um in a much more automated fashion, continually monitoring and validating uh measuring SLAs’s and and performance of those uh vendors or providers. Scott: And then when it comes time for that relationship to end, as all relationships do, that’s rather macob thing to say now that we’re coming off of Valentine’s Day, but relationships do eventually end. Scott: And you know, what kinds of processes do you have in place to ensure that that relationship is ending in a compliant in a secure fashion to make sure that you don’t have continued exposure to your data and systems after that after that happens. Scott: And click one more Dave. Scott: That’s what what what we specialize in. Scott: And then one more uh here at Prevalent is delivering capabilities at each one of these different stages to accomplish three things. Scott: Number one is to simplify and speed up you know onboarding of new vendors with a single source of the truth and process to manage that vendor. Scott: Second is to streamline the process and close gaps and risk coverage so we can consume certifications. Scott: We can consume uh assessments. Scott: We can consume external uh continuous monitoring data, centralize it into a single risk register so that you’ve got one place to visualize and act on risks and that by its very nature helps to accomplish the third thing and that’s unify teams across a third party life cycle. Scott: That’s what we seek to do anyway. Scott: Next slide please Dave. Scott: You know we deliver this via a combination of our people, our experts and thirdparty risk management that you know are around here to do the hard work for you from onboarding vendors, executing on assessments, performing remediations and then managing them throughout the uh the life cycle. Scott: Um consuming data from a half a million different uh endpoints and sources to help you calculate an accurate risk score not just from a cyber perspective but also some of the more qualitative measures as well like finance and ESG and reputational risks and that adds context to kind of some of the you know the uh third or the cyber security issues. Scott: and then finally put it all in a platform to help you centrally manage it with discipline uh and rigor uh throughout the life cycle of that relationship. Scott: So the combination of the of the people the data that we have in the platform and then the platform itself and the process really help to um you know help you automate and accelerate the process of assessing your vendors. Scott: Uh next slide please. Scott: Um and then we we do have tremendous coverage in terms of risk areas in the platform. Scott: You can just see some of that here. Scott: We’ll speed by this onto the next slide so we can move on to our our our Q&A time which I think is very good. Scott: Uh but we do offer a tremendous amount of risk coverage in the platform from a cyber security to operational and business risk lots of compliance assessments and continuous monitoring feeds, finance risk, reputational ESG and more all kind of come together to help uh give you a complete picture of your of your vendor’s risk uh profile. Scott: Uh last slide for me you know at the end of the day my objective for you our objective for you is to help you accomplish three things to help you be much more more uh intelligent, much smarter in your thirdparty risk management processes. Scott: That’s giving you performance insights, datadriven analytics, and role-based reporting for folks throughout your enterprise. Scott: Second, to bring it all together under a single source of the truth, so you’ve only got one place to go to find and act on risk. Scott: And third, to be very prescriptive, following industry standard best practices like NIST and ISO and others to help you progress through your third party relationship uh and ultimately get down to your to your security objectives. Scott: So, that’s what I wanted to share with you today. Scott: I’ll kind of pitch it back over to Melissa. Scott: Melissa, I don’t know whether you want to administer some of the questioning from here. Scott: I know we’ve got a couple of good ones that have come through the uh the Q&A. Melissa: Yeah, we uh I see some coming in already. Melissa: So, like Scott just said, if you do have a question you’d want to ask, throw it in the Q&A and we’ll get to that um as soon as possible. Melissa: I am going to though launch our second poll. Melissa: So, you’ll see that pop up on your screen. Melissa: Um I am curious, you know, if if you’re looking to establish an augment a third party risk program within this year, let me know. Melissa: U be honest. Melissa: We really do follow up with you. Melissa: I promise. Melissa: So, um while you do that, we will go ahead and comb through a few of these questions. Melissa: Um I know Dave, you might have already kind of attacked the first one about inspecting, reviewing, and auditing. Melissa: Anything else you wanted to say on that, or did you want to move on to a different question? Dave: No, I think we probably covered that one. Dave: I mean, it’s it still feels a little nebulous, but you know, we’ve got some resources to start piecing that together. Dave: And I think you start that process and do the best you can. Melissa: Got it. Melissa: Um I’m going to pop to the next one then. Melissa: Um what documentation can we ask for and what is the frequency to help provide us with evidence that proper risk mitigation is in place? Dave: So I have some thoughts on that. Dave: Uh and I’m sure Scott probably does as well. Dave: Um but I I mean so to me the document I mean ultimately I’d love to say oh you just need to go ask for the sbomb and you’re going to get everything. Dave: you need, but I know better and you know better. Dave: A lot of organizations don’t even have those yet. Dave: It’s just too new, right? Dave: This is a new trend and thing that’s sort of starting to emerge. Dave: So, I would say, you know, ask for that. Dave: I mean, let’s start with that and say, hey, do you have one? Dave: Um, and if they say absolutely not, you might say, well, why not? Dave: But that’s a different conversation. Dave: The things you should be looking for are controls validation mechanisms like static code analysis, dynamic testing processes, privilege minimization policies and standards. and really vulnerability management practices and ideally even tools or uh controls that are in place throughout the entirety of that life cycle because ultimately if they’re packaging up something that’s bad, you know, I want to know uh you know that that whatever’s coming to me may not have been assessed that thoroughly. Dave: So that’s the kind of things I would be asking for and I would be asking for it probably on a you know I’d say probably a monthly to bionly basis depending on the frequency of software updates. Dave: thought anything on that or you? Scott: No, no, totally agree. Scott: I mean it it’s I mean it’s a combination of things. Scott: If you’re looking for like an att testation or a certification or a thing to say that you know you you you do you’ve done all this. Scott: There are frameworks out there. Scott: I think NIST has one. Scott: Um but the things are nent and you know they’re continually evolving and more and you’ll see a lot more of that coming down the pipe as Dave said. Scott: So you know my biggest thing is is privilege. Scott: is especially in the software development life cycle and segregating or segmenting you know dev labs and sandboxes out by privileges to you know keep any potential questionable code or elements of that ultimate software deliverable out of a general production environment until it’s been thoroughly tested and vetted. Scott: So you know just one more thing to think about as part of the process really. Melissa: perfect I’m going to hop to this third question then um any thoughts thoughts on the NIS secure software development framework as an assessment tool internally and leveraging components for external supply review. Dave: I think it’s the one you just mentioned, right, Scott? Dave: I think that’s the one you were referring to probably. Dave: Yeah, I think I mean at least based on what I know um and I’m always open to new things that have emerged unbeknownst to me. Dave: Um it’s pretty good, right? Dave: It’s fairly thorough. Dave: You know, it’s I I think there’s room to build on this as always, but if if you’re looking for a starter, um That’s probably a pretty good one. Melissa: Awesome. Melissa: Well, I think that’s pretty much it for our questions um for today. Melissa: I think I’ll give the whole world a good two and a half minutes back. Melissa: Um Dave, any closing remarks or Scott, anything on your end? Dave: The only thing I would say is, you know, get get going on this now. Dave: Um you know, you’re going to need all the time you can possibly get to start pulling together the inventory and the vendors and figuring out who’s responsible for what. Dave: I mean, this is a huge area. Dave: um for everybody, right? Dave: So, there’s there’s really no time to waste. Dave: Things are not going to get better quickly and uh the the more attention you can pay to it now, I think the better off, you know, everybody is ultimately. Melissa: Perfect. Melissa: Well, thank you again, Dave and Scott, and thanks everyone for all your questions. Melissa: Um Dave gave us a lot of great information to take in today, and I hope to see many of you in your inboxes and at a future webinar. Melissa: Take care everybody. Melissa: Thank you. Dave: Hey, thanks. Dave: Bye, everybody.