Risk assessment the attacker way! How secured are your assets in reality?

I will talk a little bit about exposure management, not risk assessment, but risk is definitely something which I'm going to highlight here because it informs everything. And the question that I wanna raise is how secure are your assets in reality? If you think about where we are coming from, I started in IT about 20 years ago and back in the day we had servers, we had clients, we had laptops, printers were super important back then, right? And now if you think about the new world, right, the IT surface, the attack surface or the is becoming more and more complex, right?

So when we speak with organizations about their own attack service, they've been saying, Hey, in the past two years it has been increasing. And there's a lot of reasons for this, which also has an impact on the attack surface itself. So about two years ago we moved back from Australia to Germany. One of the reasons was covid, of course. So back in the day, people started to work from home, from anywhere, and there was a rapid pace in adopting cloud technologies as part of the digital transformation.

When we think about this from the other perspective, from the adversary perspective, and we as CrowdStrike, we do a lot of incident response service. We track adversaries as part of our threat intelligence that attack vectors, ransomware, malware attacks don't go away. But there's also a huge emphasis on identity-based risks. Once you have a to on an identity, you can move laterally. But one area, if you think about how adversaries that sell identities in the deep and dark web get hold of it, right? They oftentimes use phishing attacks, but they're also exploit vulnerabilities.

And if you go back to log four J, move it, there's a lot of emphasis these days about typical supply chain attacks. Now when you look into attack chains, right? People think attack chains are quite linear, right? People started the initial axis and then they, they move laterally Before they do this, they escalate privileges before they have that impact. This can be data destruction or data exfiltration, but the the, the reality is very different. So you can see on the one hand a sheer num amount of exploits. So when I started out, the CV numbers were four di three digits.

Now we have four digits. We have over roughly 200,000 exploits that are described in ACVE database. This means this problem won't go away, right? At the same time we see drive-by downloads. We see also vulnerable drivers. And it's every part of the attack chain. Every tech technique and technique vulnerabilities play a huge role. And from an adversary perspective, from the moment they enter the organization all the way to moving laterally, this takes on average 79 minutes. So I'm not talking about the meantime to detection, I'm talking about how quickly adversary can move within a network.

And the fastest one range about seven minutes. So it's very important to keep on top of all these underlying issues. As mentioned before, one of the trends that we described in our threat reports is primarily that adversaries are adopting more and more knowledge about how to start an attack in the cloud. And if you think about organizations that are adopting hybrid cloud approaches, multi-cloud approaches and moving their identity also into the cloud, and there's always a pathway how these specific, these information is being synced as of today.

And while we are hybrid, it also means that the attack surface is becoming bigger. So speak with a lot of companies in my role in the CTO office at CrowdStrike, and one of the feedback is vulnerability management failures, right? And I'll speak a little bit about the traditional approach and a few changes in the CVSS and also why exposure management may play an important role going forward. So traditionally, one of the key challenges is of course understanding your assets in the environment.

If you shift into the cloud, if you're adopting more services, if you have OT environments, that is a huge thing to basically keep track not only about the assets but also what kind of applications are running, what kind of libraries are running in there, and how these interconnected. And when people measure risk, it's always relying on what you know and it's really hard to defend what you cannot see, which means not understanding the asset is also a challenge, right? The security teams do not have a deep understanding about what these assets are actually doing.

And there's also an inability to scale and keep pace with the DevOps team, with the agile development from my vulnerability perspective. Challenges here, of course finding all these vulnerabilities in time and identify these vulnerabilities. But there's also huge reliance on manual scan with a focus on the inside rather than trying to understand if there's specific risks from the outside in as well as from the inside out.

And yeah, so then these vulnerability teams typically take these kind of data and information and they throw it over the fence. And that information lacks off of of context, especially business context. If you don't understand the criticality of your assets. Yeah. How do you want to basically inform the patch management teams that are typically overworked, that this is really a priority? Think about this. If everything's a priority, nothing's a priority. And there's also inconsistency.

If you think about specific vulnerabilities in the cloud in your application stack, in the OT environment on-premise, right? Trying to basically get a holistic view and provide the right scoring, the right metrics and the same metrics behind this is also a key challenge, let alone the supply chain attacks. I think if you think about lock four J, how many layers deep do you wanna basically go to measure that kind of risks?

So it leaves blind spots and there's no good understanding about the actual attack path, which then means that organizations are accepting risks or too many risks that they're not really aware of. And to quote the first cso, Steve Katz, there are no security risks at the end of the day. There's only business risks if we circle back a little bit, right? Where we are from a vulnerability management perspective as an organization. So one thing to consider is that vulnerabilities, they have a score and most organizations that are looking into vulnerabilities, they take the base CVSS score.

That's important, but it doesn't basically describe the risk because at the end of the day, in layman's terms, uncertainty of outcome is actually what risk is. And this is pretty much what happens when the threat, when a threat exploits a vulnerability. So you can think about this vulnerability plus threat is the probability. And then the blast radios the impact. And if you look at this Venn diagram at the center is where risk actually occurs. So it's very important in vulnerability management or vulnerability risk management to prioritize risks based on threat intelligence.

So what are the adversaries doing? Are there exploit code out there? How mature is the exploit code? Am I exposed? And what assets do I have in my organizations? And then providing that kind of business context to start prioritizing the right things. And with CrowdStrike, we've been tracking adversaries. So we used to say you don't have a malware problem, you have an adversary problem. But the same thing holds true for vulnerabilities, right? You don't have a vulnerability problem, you still have an adversary problem.

So now it's quite exciting in a way, if you think about CVSS scoring systems 3.1, as mentioned before, most people are still using the base metric group. Most people do not use the temporal group. And I highlighted this one in red, the ones where which were basically removed in in version four, and then let alone the environmental metric group, which basically helps you understand the impact. The scoring itself hasn't changed too much. We still range from non to low medium with 0.1 increments. And I think there's a few reasons why this had had to change. And there was refinement required.

So first reasons of course in version four that the attack complexity and user action metrics didn't make a lot of sense, especially the temporal metric group wasn't used, right? It was this complex to to, to use too many vulnerabilities were pushed into the higher scale. That's a huge issue.

Again, if everything is critical and high, there's only so much you can patch and let alone, there's always availability targets you need to meet as well. And I think the other part is it didn't take account for the OT environment. And also if you think about the supplemental metric group, which is new on the right hand side, there's a few things like how automatable is a a, a, an exploit and other aspects which basically is regarding the safety of OT systems, but also the ability for vendors to prioritize specific things if there's an, sorry, a patch available.

Now, if you look at this, and I know it's hard to read, but one of the key differences is also nomenclature, which means moving away from the base score. Whenever you define or communicate A-C-V-S-S score, it needs to happen in the context of what kind of score you're using. So it can be the base score, the base plus threat, the base plus threat plus environmental, the base plus environmental. And you can see some stark differences here.

So for example, if you just take one, and I don't wanna bash on any vendors here, so I leave this out, that's a vulnerability from 2020 on a network device exploit, which is exploitable theoretically. But you can see the base score is an 8.1. If you go to the right hand side to version four, and that's an example from the the first organization that is running this. You can see the difference is here, because of the lack of exploit maturity, there is no proof of concept available. The actual base and threat score is much, much lower, right?

I'm not suggesting do not patch, I'm just suggesting if you wanna prioritize, prioritize it based on data and not so much on, hey, there is a name out there or there's a logo out there, right? So we at CrowdStrike have been spending a lot of time speaking with customers and building all the technologies. So I'll talk a little bit about our concept, how to handle exposure management going forward. And I'm also glad that we have two people from Deutsche Burse later on that are going to basically provide you insights about building the right framework for this.

Now, if you think about exposure management, for us it's actually a four step approach. Number one is discovery, making sure that you discover all the assets. This means that you need to leverage APIs, control plane APIs into cloud providers. You need to basically be part of the CSD pipeline. It also means that you need to have an understanding of the OT environment if you're in a manufacturing assess.

Yeah, which means then understanding what kind of weaknesses you have. And we can distinguish between actual vulnerabilities and weaknesses. So if you're using a password admin, admin, it's on the vulnerability.

But yeah, you don't need to be a rocket scientist to basically exploit this. And of course, prioritization, which always needs to be adversary driven and factor in also the criticality of the assets and then remediate. And this is also something where of course you can inform people via ticket, but you can also build more complex rules.

Again, this is something that is not, we have a platform, but you don't solve with one tool only, right? And this is important to have that kind of openness to ingest third party information. So you can ingest for us with, with GroundStrike, you can ingest quass other information from Tenable just to make sure that you basically have all this information. But this becomes more important when we talk about how to prioritize this.

And then of course you need to inform ingest information from your identity providers, from your using other APIs, from your ticketing providers, et cetera, et cetera. And there's going to be a combination of agent based approaches, scan based approaches, right? And also basically API driven approaches to get the data. And then starting to build out relationships so you understand how are these systems actually communicating so you can understand what is an attack path could possibly look like.

And the way we, we, we do this, we think about these problems is if we take this Venn diagram for example, we prioritize things if they are exploitable over the network obviously. And then I'll speak a little bit more about how we use AI to prioritize and provide a better scoring system. And on top of this, if you have basically our AI algorithm, which works in parallel with the CVSS base scores, you can see both. And you have the network exploitability and there is an an exploit in the wild. This is basically how we start prioritizing things for you.

And again, you do start somewhere. The other part is of course misconfiguration. So making sure that you have all your systems hardened using ideally CS benchmark. But you can apply your own rules and getting also of you about the adversaries. So if you have specific adversaries targeting your industry, it might inform you about where you need to basically lay a focus. So one thing we've been doing for for many years is using machine learning and ai. And the way we do this is you require very good data.

So we've been hunting adversaries, we track over 200 adversaries and we basically infuse that knowledge about what exploits are being actually actively leveraged by adversaries, but also breaking down malware. And then we can go in and understand, okay, are they using this? Is this a priority? And this score changes over time, of course. And it's also important to basically keep track of this because something that might be a 5.4 might change if there's a readily available export code. And at the end of the day, if it's a metals plot, everyone can use it. Even myself.

Also, once we have this AI model, we can basically apply that rating. That also means that you can ingest other third party information and apply the same rating. And the key advantage is pretty much that if you look at the red dotted line, this basically constitutes the number of patches a typical patch management team can handle. And then the other questions, of course, if you take the normal CVSs S 3.1 score, and our scoring system, the idea behind this is we are focusing on the ones which are going to be exploited in the wild. So you have basically the same effort around 200% more yield.

And again, if you can patch everything, please do so. I'm not suggesting to deprioritize patching, I'm just suggesting that if you need to prioritize, it should be data driven, right? And at the end of the day, adversary driven also means the question, how exposed are we? So providing external tech, surface monitoring, understanding, especially in an agile world, if systems are basically internet facing, and I used to live in Australia, so one of my telcos reached out to me about two years ago saying that they exposed an API to the internet without any authentication.

So my driver's license was leaked, right? So having that information continuously, what you're exposing and that changes and hardened agile world requires basically to scan the internet continuously, but also to tap into the, the DevOps and the respective cloud infrastructure providers. So first question, how exposed are we? That system might not be critical, but if you think about this, the system might be interconnected with systems that hold critical information, right? So is there a possible way to lateral move? What is the actual risk?

And this is something where input from the organizations is definitely required. So you need to basically say, these assets are important because of at the moment we're also building AI to basically help you and automate that process as well, right? And finally, once you have that, you need to basically aggregate that kind of information, inform the teams, provide reports, but also if you look at these chains, just hover over and understand pretty much the state of that system. And finally the last step, of course, remediate.

So once you have that kind of information, yeah, you need to inform specific teams. This should be API driven, it should be sort driven, right? And you should basically be able to define rules to automate that process, inform the right people and start patching what matters very quickly.

So again, two pillars, right? Crosstalk.

Again, most people know us more from the incident response side, threat intelligence side, X-D-R-E-D-R side and threat hunting side. But in order for us to stop the breach, we also basically need to make sure that we strengthen the, or supercharge the proactive side. So we are combining a lot of these technologies. And as an API first company, we're ingesting also other information.

And again, think about this more as a framework for yourself. You don't have to use CrowdStrike necessarily, get to these outcomes, but think about this more as a, a framework. And then of course, what do you wanna do with that information? And this is where the, the, the saw, the third parties play an important role.

So again, for us, zero infrastructure to to, to basically get this done. But I wanna open this up for, for questions. If there's one thing you wanna take away from this, two things actually first stay in this room. There's going to be another exciting talk about how to manage vulnerabilities. But more importantly, we stop breaches. Thank you.