 The bank will have a different relationship with me than I have with them. The third one, as well, is everything is contextual. So by context, it's like, what is the environment? What am I trying to do? Is it the right time to do so? So I want to just throw this out, because this is one of the best definitions I've seen of trust for in quite a while. And so I want to throw this out just to begin with. Now, before we get started with it, I want to talk about a smaller, it's a bigger topic in a smaller setting, which is like why vex? And the why of this actually comes down to economics. So economics at the end of the day, one way of thinking of it is this concept of risk and reward. So with risk and reward, like we get up in the morning, some of us hop into cars. There's risk there. The reward is that we get to go do things that help us drive more income, get to see friends. So there's a risk and reward for each thing. The same is true if you are attacking a system. There is a risk, there is a reward of like, what is a reward if I break into this thing? Like maybe someone's going to mine Bitcoin. Maybe somebody is going to try to break into something to extract information out. Maybe there's a reputation part of it that they're looking towards it. There's a risk. What is the risk of being caught? Like is the risk they lose access to the system? Is the risk that they're going to be contacted by their local law enforcement? So what is that penalty? And there's also an opportunity cost. So the opportunity cost is I could spend a week going after a hardened target. And maybe I could have made more efforts to go after a squishier target and get better results out of it in the long run. So there's also an opportunity cost. Even advanced persistent threats, when we say advanced persistent threats, we specifically mean well-funded groups, well-funded criminal organizations or governments that have a large quantity of resources, large quantity of people, but even they have limited resources. Any moment they are spending time going after your organization or your area, it's time that they could have been spending doing something else, trying to attack a different target. So even at scale, this ends up mattering. And time is also a factor for them as well. Like if there's a particular event or there's some type of thing that they're trying to do, the time necessary to do it may have passed if they don't move fast enough. So there may be certain effects at the geopolitical side that they may be looking for. And so time is also a factor with them. And then we talk about, look at it from the defender side. So as a defender, what is the value of the thing that I'm protecting? So I'm gonna protect a simple video game I make differently from the way I would protect financial information. What is the likeliness of that thing being attacked? And likeliness here is also a bit interesting as well because it's not just, is it likely to be attacked? Of course, all systems are gonna be attacked over time. But the likeliness also comes towards what is the amount of effort that the attacker is going to put? So this ties it back to the economics from the attacker side. And the defender also ends up looking at things like what is the value lost if an incident occurs or if the attack is successful? So maybe there's a particular device and if the device, by incident, let's say it's stolen just as an example, there's the value of what was on there. There's the value of the hardware. There are possible penalties if the device is stolen and there were not enough protections on it. So we call this the exposure factor. And finally, what is the cost of protecting the system? So every defense that we take has a cost associated to it. So the cost could be like what is the cost of encrypting all hard drives? What is the cost of spending the time in order to set up a service mesh, the time to operate an administrative? And so cost to a defender, often in quantitative analysis, you'll see these type of equations. So there tends to be somebody in larger organizations who are using some derivative of these type of things. So these three I put up just to give you an idea as to what type of things people look for. So single loss expectancy is like, some incident occurs, let's say it's a break-in or something's lost, then what is the exposure? So in other words, the value of the asset and the exposure factor. Exposure factor is a multiplicative thing where you take the value and let's say that you lose 20% of the value if a certain attack occurs. So that means that if you have something that's worth $1,000, the attack's successful, the remainder value or the loss at that time is 20%. So your exposure factor would be 0.2. So this then feeds into the annualized loss expectancy. So what that is is like, okay, we expect to lose 500 hard drives over the year. So then you can take all of that and say, well, let's multiply whatever that number was before by 500 and that gets you the average loss per year. Interestingly, this also works even if the thing that only happens, let's say once every 10 years, like maybe you say once every 10 years we have a flood that damages the data center. Your annual rate of occurrence at that point is 0.1. So this even works in long time scales. The residual value, and this is really the number to watch out for is what is the cost, what is the value of what is your protecting minus the cost of operating and defending it? Because that remainder value is the total value of the product or of the thing that you're working with or of the data. And the reality of it is that if you have a negative residual value, this is actually costing you money. And at that point you have to ask the question, is it worth, whatever we're doing, is it worth doing or we're doing or is there a different way we can defend it while still meeting our expectations? So this residual value becomes very important when you're trying to decide what are we going to defend. So a really simple example is what is the cost of log for shell? So if you're applying these equations to log for shell, like what is the asset value, what is the cost of that particular thing has been compromised? The annual rate of occurrence, well how many systems out there do we have to go and repair over time? What was that cost? The residual cost was like we had that value of whatever it is we were running that infrastructure minus the cost of mitigating and defending the log for shell issue. And so we can see that our residual value has dropped as a result of such an attack. So we can see this in there. So why this little mini talk before is because anything we do when we talk about like why are we bringing in S-bombs? Why are we bringing in all the variety of things you see here, the economics matter. And so if we use this concept of qualitative, risk and reward, quantitative, trying to determine what the value is, then that helps provide us with some model that we can try to work out, what to prioritize. And so the attackers want maximum reward for a minimal risk. So there may be a financial, they may be looking at time, they may be looking at the chances of being caught, what's the penalty being caught? And there's numerous other factors as well, but start to think about some of this as not only in terms of what is the cost of the defender, also think about it, what is the value that the attacker's gonna get out of this and what is their effort, what is their chance of being caught? Because if you look like a hardened target with limited value, you'll still be attacked, but there'll be more time spent in targets that are higher in value and easier to compromise over time. So with that, the main message is do everything you ethically and morally can to shift the economic equations in your favor. So just keep that in mind. So with that, let's talk about VEX. So if we look at some of the newer trends that are coming on, we have software build of materials. So there are a set of claims. Just one little note, when you hear the term claim, you'll hear the term claim quite often and you'll hear the term at the stations. The claim is a mouth, I have a claim, I have something that professes something, and at the station is a verb. So I attest something generated claim. So the S-bomb of materials is a set of claims that will describe who built it, who provided it, what is within that particular package, what are the artifacts, when was it created, where was it created? So there's a whole bunch of things that are within an S-bomb that are included. And so one of the key things though as well is we have these dependencies and the dependencies of dependencies also mapped out, ideally as a set of recursive S-bombs that we can go in and look through. It does, often it does not include the how. So the how is like, I ran this compiler, these are the steps that I took, these are the ways I included these particular artifacts, those matter as well, but very often you have to bring in something else like in Toto to deal with it. So generally, software build of material gives you a good picture of what's in something but it's not the full story. So there's a modeling gap here. The modeling gap is that S-bombs are static. You produce them at build time generally or shortly afterwards. And vulnerabilities tend to be dynamic. We discover them over time. So this means that there are some people who think oh, why don't we stick the CVs in the S-bomb? A better approach instead is we keep the S-bomb. That S-bomb becomes a key to your CVE database. So you're able to then check, okay, well I have this version of log for J keyed against these vulnerabilities. I was able to see, I can get a sense as to as to where things are. But this does leave us with a modeling gap that's there. And so there is a major effort going on throughout multiple companies and has been for a while in order to map versions to CVEs. One of the newer manifestations of this is mapping the actual CVs or the S-bombs to your CVs. So literally the S-bomb identifier is your key. You extract all the dependencies and then you can recursively check, okay, let's go check each of those with their keys to see what's inside of it. And with that, we would expect to be done but unfortunately we are not. The reason why is that CVEs don't tell the whole story. So not everything is affected by its vulnerabilities. And so when you spin up a dashboard or you're running a whole bunch of scanners, you often get a whole bunch of different vulnerabilities that you're not affected by. And so this creates, when you're running a large operation this generates a lot of noise. Like how many people as developers you run a static code scanner or something that looks for vulnerabilities and the number of red flags that comes up that are false positives like just makes your development team say, I don't wanna do this anymore because at that point every time that you have these vulnerabilities pop up that are not affecting you, it draws your attention. You have to explain to the security team why it's not an issue. It ends up creating issues where maybe there is a real vulnerability there but there's so many other things there that you're not gonna, even if you spend the time to try to find it there's a good chance you might miss it. So now think about this and now imagine you're running an organization that has thousands of applications, tens of thousands, hundreds of thousands of workloads and spread across multiple locations. Now you're talking about a problem that at scale is incredibly expensive and the CVE noise that you have there ends up limiting the total value that you have there and you have to make much broader approaches in terms of how to mitigate them. One of my favorite examples is Lib Curl. So Lib Curl is a library you can use to, has a client to connect to all sorts of different things. Most people know of it as an HTTP client but it turns out you can also support other protocols like TFTP. There was a bug in TFTP that was thought to be fixed. Turns out it wasn't fixed and what it did is if you connected it using an SSL certificate, it would leak out some information that would allow for decryption of whatever that material is and I believe a compromise of the actual private key itself I believe was part of it. This only occurred if you were using TFTP. So very few people use TFTP. So if you were not using that, then you were in good shape. You run a scanner on top of it though you're gonna get a message saying hey you have this really high level CVE I think it was like a 9.0 or something of that level out of 10 that you need to go and resolve. So of course your teams are gonna come back and say you have to patch this because they have no way to tell whether or not you're vulnerable. You can have a conversation with them but from their scanning perspectives they're not able to tell. And so most applications though were not affected even though they were vulnerable because they did not use TFTP. So we have to work around the gap. Today the way we work around those gaps is we often create policies that say whenever a CVE over a certain number is there we have to upgrade it, no questions asked. This ends up increasing the total costs of ownership also includes risk because whenever you upgrade something there is a risk that you might end up with something failing. There's a risk that you might have something misconfigured. And so there is additional costs and risks that's attached there. You may end up hopping onto your vendor and saying hey is this thing affected or is it not affected? Maybe you go look for a blog post. You may have a vendor representative that you go and discuss. Like literally hop onto the phones and say hey are we affected by log for J? Yes or no. And having been on the conversation for some of these I've seen multiple answers that were like no we're not affected because we shut that off or because the library was brought in but we never spin it up, we never use it. But when you do the scan it's there. You can see it. There's also issues around how you can also look at mitigating it. So mitigating say well let's fix something in front of it that'll scan for these type of attacks or you may end up accepting the risk. Saying you know what we know it's there but we're gonna operate anyway because we've analyzed, we're gonna accept the risk. You eliminate it by saying hey we're just gonna get rid of the product. Like the product's too troublesome or it's not generating enough. The residual value is now negative, not worth running anymore and we don't have any obligations to continue running it. So sometimes you may see it eliminated over time. There's also another one which is a little bit weird which is you can transfer the risk. It turns out with ransomware there's a whole bunch of companies that say oh we're covered for ransomware. Oh great how did you mitigate it? Oh we got an insurance policy we'll pay out. It's like okay this is terrible. There's actually a couple things that if I don't know if they passed or not but there were some discussions by some governments that if they were to declare ransomware attacks to be a terrorist attack then at that point the insurance companies that deal in that space would not be able to pay out for ransomware. So they'd be able to cover other things like the hard drive was lost or something like that and then help you recoup getting another hard drive. But in terms of ransomware attacks it's possible that if it's not already there's a good chance that we may actually see that particular one go away at least in the transfer of risk. And so with that we have all these ways of like we're trying to work around it that are unique to every organization. And so there's a couple groups that got together in order to create this program called VEX. And so right now VEX is a draft in the new OASIS CSAF 2.0 standard. There's a couple implementations of VEX that don't follow the CSAF example but they provide the same structure the same piece of information. And it's designed for one thing it's designed to provide a common way to tell from a machine readable perspective am I vulnerable not only am I vulnerable but specifically am I affected by a specific vulnerability. So every VEX document has at the minimum there's a little bit more than this but at the minimum it has these things. It'll have a product tree which lists all of the products that have been referenced by that document. The affected status is it fixed is it known to be affected is it known to not be affected by it like the TFTP lip curl thing when you don't use TFTP or is it currently under investigation. Part of it as well is there is a gap here where the CVE has to link to some ID which could be a CVE or might be a bug ID. And so if you have one of those you're good but if you don't then you have to have some way of eventually binding it. So that's one little nuance with it. But one of the neat things about it though is that there's also information where you can describe how to resolve it. So the way you resolve might say upgrade to this version or it might say to mitigate using these steps. You know follow these three steps disable this into configuration and then you will no longer be affected. And there'll also be notes quite often about the details of it. So this is designed to be machine readable with a workflow that looks something like this. You have a deployed application. You have an S-bomb or a set of S-bombs that describe your application. Let's say the new CVE comes out and so now the CVE is popped up in your dashboard. Best case scenario you have analysis you're able to work out that the CVE is there so you need to determine how are you going to work with this particular system. If you don't have VEX you have to assume you're affected. You have to force an upgrade or you have to go find more information through other channels. With VEX the team can look up a VEX document. If no VEX statement exists then my preferred approach is going to be to ask the vendors hey can you please publish something because if they publish it then that's not just me that receives the information it's everyone who's on the product who receives it. So it helps with that. But let's assume that they've issued a VEX statement out that VEX statement can then be ingested into the cybersecurity dashboards of the various InfoSec teams which that initial flag turned on because of the CVE being there. And then if it's affected it stays on and we can say hey this has been the vendor has stated or we can shut it off and say hey the vendor has even though we see it there we sit still in our report our vendor has given us assurances that we're in good shape which means you get to focus your attention on the areas where you actually have vulnerability or where you have a lack of information. So in short Sbombs tell you what's in your infrastructure CVEs tell you what vulnerabilities are in your infrastructure and VEX tells you which of those vulnerabilities you're affected by. So this is the one the three liner will say. See a couple of people taking photos so I'll give it a brief moment. So there are a couple of gaps. The first gap is that so VEX is a claim as to whether a software product is given by a vulnerability. So the first part is do you trust the person or the organization who is putting together the statement because I could put together a VEX statement about your product and say I believe it has this problem or does not have this problem. So you wanna look at who's generating it who's generating that information. So in general vendors will probably be considered to be higher quality. You may also have over time, you might find that certain vendors might be a little bit more flaky. So given enough time, we may be able to pick up some information. Flaky's wrong word. We'll say inaccurate because of the complexity of the products. And so over time we'll be able to tell what from a percentage perspective given a long enough time horizon, what is the likeness and what is the accuracy of those statements. So that's still an open question but generally it's gonna be much better than what we had before. VEX does not also provide a way to normalize the vendor and product information. By that it's like you pull in a product, there might be, let's say you pull in Kubernetes. How many different ways are there to say I use Kubernetes and to version that information within the SBOM. So there's some issues around version normalization that needs to occur. And finally, if there's a vulnerability with no CV or common bug ID that you can point to like a GitHub issue or a bugzilla or so on, then it is a required element to have it in there. So we may have to put something in there to just say hey we have an internal database or there's something there that we can bind against. So with that I wanna thank you for your time and I'll be around shortly afterwards but are we able to take questions as well? We still have a little bit of time. So are there any questions that people have? So I see one and then there's one second one back there. Can we have the microphone on please? You hear me? Okay. The question is about SBOM. So it's always problematic to let me say force the developers to embrace the SBOM in a normal way. So there are some automated way language independent to generate this kind of artifact. Because otherwise this is a beautiful approach to manage this kind of security problem but we don't give some tools to the developers it's very hard to implement it. Yeah that's a good question. So let me make sure I paraphrase it just to be that I have a problem. So you're worried about the SBOM itself that they're not standardized or might be different reporting standards, different versions or names and ways that people live together. So what was the last one? And also the automation of the generation this kind of artifact. Ah yes and the generation of it as well. Different tools put out different things. So this is a problem. SBOMs are a relatively new thing. So we're still in the phase of learning how to generate them properly and with enough information. I think that there's a few things that are gonna happen over time. So the first one is the commercial products. Those ones will be a little bit easier because in time the companies will say these are the type of things we're looking for. I think we'll see forces, the economic forces will normalize some of those over time. One of the problems that we do see and let me go ahead and shut this off because there's a graphic on it so I'll put it here. So one of the problems that we have is that if you're running an open source community we're already starting to see people reach out saying you're an open source vendor who's provided me with this thing. You have to provide the SBOM. And it's like telling an open source that they have to maintain or they have to do something when they're not paying them for it, they're not, there's no business relationship. There was really weird. And so a couple of ways to go about this in order to help is for the larger projects we have, I think projects are in a CNCF and so on we're trying to set up through the attack security and other similar groups to try to work out what's proper guidance to help the developers in that area. But if it's something that's important to you there's a couple of ways that we're starting to see this handle. So the first one is that some of the companies are starting to reach out to open source companies and say hey we'll provide financial means or we'll provide people to help make this happen, and make sure that automation occurs. Another thing that, another pattern we're starting to see happen as well is that if a company ingests a open source project even if there's no SBOM there they'll, it's like when you cite your sources we'll say this came from this person at this particular time and we've signed the, we've counter signed it just so we say that that's when it was. So, and here's the scan that we did on top of it. So there's some use for scanning for the scanning style SBOMs rather than the build time SBOMs that we're gonna see used in this as well. Not as high quality of information unfortunately because you lose information during the build time but those are some of the patterns that we're seeing in order to help there. And then over time we'll see where things progress as the industry matures. So does that answer the question? Perfect, and there was another one back there. Thank you. I was wondering how available is VEX documents today and is there some kind of catalog where we can find the existing VEX documents to easily ingest this kind of data? That's a great question. So this is very new. Like as in this is all stuff that's been developing in the past we'll say six months or so. So there's not a very good repository yet for these type of VEX statements to be created. That is something that I think as an industry it's actually a gap that I'm hoping that over time perhaps the open source software security foundation, open SSF might be able to help with or perhaps the CNCF may be a help in some of these areas but that is a major gap over and it also depends on over time. We'll see where some of this ends up as well but we're starting to see some of the VEX information start to appear not only in the CSAP OASIS project but we're also starting to see like CyclingDX has their own version of the same information that's attached there as well under the VEX name as well. So in time right now it's very new. So this is not something that you could go in today implement today but it's something to keep in mind if you're a vendor, if you're in charge of this kind of stuff or if you're on the consumer side to be able to say hey we're really interested in this because it helps reduce the total cost of ownership and helps you focus and shifts the needle on the economics on where to spend your time. So anything that helps in that direction I'm hoping we'll see some engagement towards this. So right now it's very new. We're seeing a lot of interest in this. Interestingly the largest group that is interested in this stuff is the U.S. government. So if they managed to put it inside of their, or if they decide to put it inside of their FedRAMP or one of the other similar programs and then at that point we should see massive adoption throughout at least the major portions of the private sector and hopefully those tools will evolve and mature and then a best case scenario they'll be easy to use dashboards or easy ways to generate these documents in ways that don't cost the developers much because again we're talking about the economics. What is economics to the developer? It's expensive to the developer. They're probably not going to want to do it or be able to do it because of the expense. And so we do have to keep an eye on those type of properties not only for VEX but also the creation of S-bombs. So I think there's one here and then at that point we'll be at time. And thank you very much for helping. I feel what VEX is trying to do is sometimes done through CVEs. So you would have for example Log4Shell that has a CVE number but you would also have vendors like products that consume Log4Shell, Log4J Story that also have a CVE associated to report that they're vulnerable to it. So how do you think about like we could manage this situation and avoid having multiple CVEs for one root vulnerability for all the products that consume that dependency. Yeah, that's a good question. And so the problem that we run into with CVEs, there's two problems. So the first CVEs, if you've ever tried to parse a CVE from the MITRE group, it's possible to parse it but it was really made for presenting to humans. So that's the first problem we run into. The second problem that we run into is so if it's a one-to-one product like you have a vendor that says, hey, our product over here has this problem or a small number of vendors and then you're in okay shape. But what ends up happening is when you get something like Log4J the quantity of products that were affected by it are so high that that CVE, if you were to list every single product that's inside of it, that CVE is gonna be like massive and will be useless to people. So being able to create the VEX document that links that CVE and says whether they're affected or not helps. And usually what they do is there's a number called a CPE. So they usually look at the CPE number and then look at the version there and then match that to the vulnerability. But that says the vulnerability is there but doesn't tell you whether or not that particular product is affected or not. So your scanners will say, yes, this is there. Then you have to assume you're affected. And so VEX will provide additional context that will help determine whether or not it's affected or not with information coming from the vendor or a trusted source. So hopefully, does that help answer the question? It was more about duplicate CVEs. So like instead of having a CPE that says, okay, this product is also affected by that CVE sometimes you would see another CVE created. Oh, yes. You know, so like... Yeah, hopefully we reduce that because that's also noisy. Like if you can have one CVE and then you're able to say, these are all the products are affected by it is a much better than saying here are the 10 CVEs that all map to the same thing. So thank you for highlighting that. That is something that I think VEX will definitely help with. So I wanna thank you for your time and also thank Tiffany for helping with this as well. So thank you. Thank you.