Continuous Exposure Management – XM Cyber

Welcome anyway, even for a small audience, you get more opportunities to ask questions and interact with me. The workshop is a presentation with a demo, so just interrupt me when you have questions. I don't think we have to wait until the end to ask questions. The motto of the presentation is fix less, prevent more. That's XM Cyber's motto. You don't work and work and don't get anywhere. My name is Andreas Haldi. I'm the team lead of the Customer Success Managers here in Germany, but also in Switzerland and Austria. So as I said, first a little bit of a presentation.

I'll show you a little bit of what we're focusing on. We're focusing on the remediation effort to prioritize it and cut it as low as possible. Then I'll do a demo of the platform that we have, and I'll show you a little bit what we also do at XM Cyber for support of our customers. So the question I think that everybody is asking themselves here around today, and generally if you're in this kind of industry, is how do I protect my environment? And how do I protect it comprehensively?

Because there's so many tools, there's so many ways a hacker can get into your environment, and how do you make sure that you've got it all covered? And so what you can do is you can buy a tool for EDR, you can buy something for cloud, you can buy something for Active Directory, something for vulnerabilities of course, CVEs. But are you still covered? Are you fully covered then still? So this is actually what you're going to see later also in our platform. This is how we visualize the environment of a customer.

It's a generic one here for the demo purpose, where you have a corporate network, you have a DMZ, you have a data center, the cloud of course, but then also your critical business assets, which are SAP servers or PCI servers and databases. And definitely everybody has an EDR somewhere because you don't want anybody to come in and you want to somehow detect this and respond to it when an attacker comes in somewhere into your network. But it is unlikely that you're going to catch 100%.

At one point, there's going to be somebody in your system, and now they're trying to find their way to whatever you have as critical assets in your company. They're going to move laterally across your network trying to figure out if they can move through different CVEs, if they can move through other misconfigurations or identities that have too many privileges and so on. And we need to stop them. But the problem is we have usually a ton of different tools now. We have one for the clouds that checks if the cloud is done properly. We have a tool that checks if we have all the CVEs patched.

We have a tool that is for Active Directory misconfigurations and so on. And all of these tools give you a list of thousands of different vulnerabilities. Because they have to. Because that's their job. They show their value by showing you how much they find. And so you have a whole lot of vulnerabilities now that you're trying to fix. And you don't know how to fix them, and you don't really know what is actually most vulnerable in your environment. And that is something we're trying to make better here. So here's an example.

Let's say here somebody has done, a hacker has done a phishing attack. They come in through a Windows machine, a workstation. They find a vulnerability. They move on here to another Windows machine. And then they find credentials and so on until they finally reach your PCI environment. And if you just do the siloed approach, you know, you're going to go and fix stuff. Because you have a list of stuff to fix. But where do you go fix? You fix in places that are not relevant for this attack path.

And that's one thing that we found is that 75% of all the exposures that we even find, they're just not relevant. Because they're not on an attack path to something critical. But because everybody has a tool or has tools that find these things, they just try to patch them and fix them. Because they don't have the overview. And what's worse on top of that is that you then have a security team that really is trying their best. Is trying to find all the vulnerabilities, the exposures. Is trying to make a list for IT of what to do. And of course, they're struggling.

Because they need to motivate the IT team. They need to tell the IT team why they have to do certain things. Because they're giving them a whole list of work to do. And of course, the IT team is very frustrated. Because they get a long list. And they don't have a clue if they're doing anything that's worth their time. So this all just evolves and evolves. And the lists always get longer. But they usually don't get shorter. And things are just getting worse. So what you usually have...

Most companies have some sort of vulnerability management system for CVEs where they get a long list of CVEs that are out there in the wild. But again, there they don't really know how anybody would move within their environment. So what they do is you hire a red team or you have a red team and you do some pen testing and so on. So that you get some attack paths. You do get some. That's true. But they're usually very focused. You target your red team on a specific path. You want to tell them, this is where you come in, this is where you're going to go. And that's what they're going to do.

It's not comprehensive. They also just don't do it... They do it once a month or once every three months, depending on how much money you want to spend. But you don't get your security posture every day. This can't be done with an actual pen test team. And of course, they do it on a live system. So you're running the risk that something's going to go down. And also what we've seen quite a bit, you're running the risk of leaving breadcrumbs in your system. So this is what we're trying to do now. We're trying to bring all these different vulnerabilities together.

CVEs, credentials, misconfigurations, cloud, Active Directory. We're also looking at just the ones that are in the wild, of course. But we're going a few steps further. What we're looking at next is, is the exposure even exploitable? Because if it's not exploitable, there's also no point in fixing it. And then we built the attack graph based on the exploitable vulnerabilities in our system. And we check only for the vulnerabilities that lead us to a critical asset. That's the only thing we're really interested in. And that's why we saw the 75% reduction.

The only 25% of the exposures that we found initially actually are on the way to critical assets. So you have to remediate a lot less. And what we're doing is we're doing simulations on your system. So we're not doing it in your live system. We do it separately in the cloud. And that also gives us the ability to not just get one path, not just get from one breach point to some critical asset, but we can do this for your whole environment. And then you get a lot of data.

And with this lot of data, you actually find a few points in your environment that are what we call choke points, where all the paths come together. And if you only work on these, if you only make those more secure, you have even less work to do. So there we can get another 90% reduction of what we already have, of the 25% that we had before. And so that brings us down to that you only have to fix 2% of your exposures in your network. And that should actually be enough to make your whole environment safe.

Let me explain that to you a little bit different with a graph so that you understand better what I meant with the choke points. So it's the same network as before. Now I've put all the different attack paths in. And you do see that here you have virtual machines that can be compromised. Red is always compromised, and the red arrows are the attacks. So you have here, for example, these VMs that can be compromised. And let's say we actually found a high severity vulnerability. If you have a VM tool, it's going to tell you, you've got to fix this. But why?

Because once you're on this VM, nothing else is going to happen. So unless this is already a critical asset, you don't really have to patch it.

Yes, you can, of course, long term. If you have the time, go ahead and do it. We're not going to stop you. But it's not really necessary. So we take out the dead ends. And then as you can see, you have here two choke points, a window station and some user configuration that if you can fix those, then most of your attack paths go away. Most of the ways to go to your critical assets are gone. And that's what we're focusing on. We're trying to find for you the choke points so that you can only remediate those. And once those are remediated, you're much more secure.

And then, of course, you still see one attack path still there. We are going to find that afterwards. And then we can remediate it later. But it's just one path that's left, just by cleaning up two choke points.

So again, fix less, but prevent more. We did a rough calculation what that costs for a 5,000-employee company. And if you look at this for the annual costs, if you go and remediate all these dead ends, all these 98% of vulnerabilities that you can also fix, that costs such a small company still up to $1 million a year.

Again, it's an assumption. It's probably not very accurate. It depends on the company. But that's a high number. So we have a couple of case studies here, too. One is a company with 30,000 employees. This is our dashboard. You're going to see it in a minute, in live. We always give our customer a current security score and a grade. You can see that this company went from an average score of 34. We gave that a grade F. That's definitely a failure. Up to 100 within four months. What you see here is what we call different scenarios. So the different lines, they mean different attack paths.

They're defined here on the left-hand side. And it's very generic in this case. It goes from workstations, to the database, to the domain controller, to the file server and terminal servers. And you see how all of them slowly go up by the customer just fixing things continuously. Or a second example, here, this is a cloud environment, mostly. And they have a DMZ. And we said the breach point is in DMZ. And we wanted to see, for ransomware purposes, how far can an attacker go? How much of your network can they compromise? And initially, we were at 89%.

And we realized they had a choke point on their internet-facing file server. There were two privileged credentials on that server. And if you could use those, then you could reach almost everything in their system. Incidentally, this customer had also forgotten to turn on their EDR tool. Which is a mistake, is an issue, too. But unfortunately, that happens quite a bit. So I have seen, myself, I've seen a few customers who had patched all their vulnerabilities. And we found them anyway, because they forgot to restart their machines or their servers.

And so the patch was there, but it didn't do anything. Now I admit, not every customer is going to be like this. Especially the bottom one is an exception.

Usually, we don't get such quick and easy wins. And even the four months, that's a company that really tried very hard to get there. And in the end, that's what it usually comes to. It's not just that we can show you stuff. But this is all about working together with the customer. The customer needs to want to resolve things. They need to have a good view, good standing in the management also. That they understand that they need to drive it together.

IT, security, it's a company effort. It's not just the security guy, the security analyst will fix all these things. But it can be done, as we can see here. So what we're trying to also do in our software then, is that we're trying to live this whole topic of Continuous Threat Exposure Management, the CTEM. There's not anything new, but we're trying to have almost everything included in the software. So we do the scoping first. We figure out with the customer, what scenarios do you want to set up? Where are your most likely breach points? Where are your critical assets?

Then we go and try to find the vulnerability in the system. We do the attack path simulations. We bring them all together. Then we can prioritize based on this. And we can identify the choke points that we have. And once we have those from the system, we can then issue IT tickets. And we can check the status of IT tickets, so that we can actually get those things remediated. And I think with this, we're coming to the demo. So I assume that in the meantime, I'm logged out, but we're going to have a look.

No, I'm still there. At least it shows that it's still working. Yep. So you saw the top you saw before, the top dashboard. I apologize for the Wi-Fi connection here. There we go. Here again, you see the different scenarios. You see that the scan or the attack path simulation is done daily. So we really have for every day, we get a score for the different scenarios that we have here.

Now, I'm going to get to all these reports on the bottom later. We're going to go step by step now through the CTEM approach.

So first, we have our scenarios. Here you have a bunch of these scenarios that are set up here. They're already there. But let me show you a little bit on how this can be done. So we'll set up one that goes from the partner portal to, let's say, the customer DB. And then you can select the scope. In this case, this is a hybrid scope. So I need the on-prem and I need cloud. But technically, you could decide I only want to have here something that I want to have an approach that only runs in the cloud. So I could select all of my cloud entities if I wanted to, AWS, Azure, or GCP.

We don't want to do this here. We do it hybrid. We take everything into the scope. Then we can define the breach points. That is where the attacker would come in.

So here, I can say we set the custom portal. So I can select here the computer, which is the partner portal.

Oh, typo. That's why it doesn't show up. Here it is. You could add more. We can work with several breach points. It doesn't need to be just one. It can be several of them. And then we can, on this side here, yeah? So how much of that can be auto-discovered? It's all auto-discovered. You can label stuff yourself if you want to. But if you've labeled everything in your network properly, it's all going to automatically pop up here into the system. Even the whole environment. So usually, that's not what we set up.

And you actually see here for when I go in the cloud and go to cloud entity, that all is auto-discovered here. We do the cloud entity. And we do customer database. I have a lot of typos today. And you take here one of those. You could also take them all. That's an easy two. And then you can exclude stuff. You can exclude methods. That's what we currently have. If you want to exclude certain methods, attack methods from this whole simulation, you can do this also here. And as I mentioned before, you could here set this to dynamic breach points.

If you have more than one breach point, you can say just you take a certain number of breach points every day. And then every day, it moves to another set of breach points. And so you get around, statistically, all your breach points within a certain time. But you don't want to overload it with too many breach points at the beginning. Because otherwise, it's going to have a hard time finishing in that one day. But it runs every day, as you see. It's automatic. You can also do it manually. You can run it here. It's not with multiple attack vectors. But you can enable that, too.

And that way, you can jump from one attack vector to the other so that you have them all in there. And when you did all this, then you end up with a scenario here. It's actually already on there. I think it was down here somewhere. Workstations to customer DB. Then you see over here, it's actually been pretty good. We do see a couple attack techniques still. It's CVEs mostly. But you can also see on a daily basis how good has it been lately. In this case, actually, 100% were compromised here. So it hasn't been quite as good as it looked before. But with this, we then build up our reports.

Now we have all these scenarios. And the scenarios give us all these attack paths. And that's how we end up with we can now build reports from the information that we have. So we know from the different paths what kind of attack techniques have been used. And that's what you see here. It's sorted by how many of your critical assets you're going to compromise using this attack technique. So that means that this attack technique just shows up on these attack paths towards these critical assets. And you see also that we make a recommendation for what you should fix first.

And the recommendation is always based on how many critical assets do you have that are at risk, but also how many choke points do you actually have to go fix and how complex is the path that you have there. And so in this case, you see you have log4j, 34 machines, 34 entities are affected with the log4j vulnerability. But only two of them are actually on the path to critical assets. So you see here also this ratio between how much you find and how much you actually have to go patch. And there are only two stations to patch here. That's rather easy to do.

And if you do this, you have a lot of critical assets that you can make much more secure. So if you click here on View Remediation, which is what I did a second ago, we'll first give you the explanation on how the technique actually works. I think the log4j is one that most people actually know, so I don't have to go more specifically into this. But you have links to the metroid technique alignment. You have references. You also see in the bottom the conditions that our software checks it for. So we don't just check, is the jar file there, the vulnerable jar file? But are the ports open?

Is there a process running on those ports? That we all check to make sure that this vulnerability is actually exploitable and it's not just the jar that is outdated. And you see down here, you see the two stations that we have that were, well, this is obviously a server here, the Linux server, that are the choke points. Those are the two where you go and have to go fix these things. And now we give you different options. Either you take one of these remediations, that's the band-aids. If you fix one of those, then this issue is gone.

For log4j, for CVEs, usually people pick that because usually there is a patch or something and then the remediation is done, it's gone. For Active Directory problems, sometimes the customer doesn't really want to go and follow the remediation because maybe one of the identities that wasn't so secure is actually the admin identity and they're like, no, but I want to use this more. So they might not go with the remediation. In that case, you have usually also hardening that we suggest to you.

Again, the hardening doesn't remediate anything. It just makes it harder for an attacker to get in. And even if this is even too difficult for you, then we even offer best practices. What else can you do to make your system safer?

But again, the issues don't go away. If you do want to do a specific remediation, you can click on it. It will tell you exactly what to do. And it will also tell you where exactly those files are, the jar files are, that you have to go and patch. And what you can do then is you can send it directly to your IT team if you have an integration through ServiceNow or through Jira. You can go in here and then we wait for the Wi-Fi. There we go. You select your project that you have in Jira, make an issue type, and then it automatically fills everything.

It fills for them what they're supposed to remediate. It will attach a file that tells them exactly what to do where. And then what I can do is I can actually create a task from here. We can also later on go have a look at the status of these tasks. So that's one way. To be honest, I think most of our customers use this report mostly because it gives them a nice overview. They can just start from the top. It gives them a recommendation.

And when I talk to medium-sized companies, that's usually good enough for them because medium-sized companies don't necessarily have a security analyst or anybody in security team. It's just the IT team that does security on the side. And then they have two, three hours of security work that they can do. They take this list and they fix two workstations that have a log4j issue. And with this, the most important thing has been taken care of. It gets a little trickier the further you get down. The more you work with it, the more you get deeper into AD and tiering and all those kinds of things.

And then it's not just a two-hour patch anymore. But in the beginning, most people can just work with the small, short patches that they have here. You get other reports. You get the report of which of your entities have actually been compromised. And you also get here the overview how easy it was to compromise them. We multiply each step by two. So if you have a number two here, that means it's usually one step from the breach point to reach it.

There, I think the interesting things that you usually look at is the critical assets. And actually, the diamond over here shows also if this is a critical asset or not. And then you see here a bunch of these critical assets that can be compromised very easily, actually. But that also depends a little bit on how do you define your breach points. Is the breach point really at the very beginning of your path, or do you decide my breach point could be somewhere near my admin already, and then all you have to breach is your domain admin and you're in?

The more interesting report is actually this one. This is the choke point report. Here we list all the entities by how many critical assets they actually helped to compromise. On how many paths to the critical assets are they. And so as usual, the top is usually a service account or an admin account that is somehow not safe enough. But you also have here a workstation, and I'll show you that person in a minute, that just has a Chrome Exploit. And that's rather easy to remediate. Yeah?

So to be clear, so are you saying, like that former report, is that, are you saying that those things actually have been breached or that you checked and it could be breached? No, in our case, it's all a could be breached. We're doing prevention. We're not actually. Correct. Correct. Yeah. We don't do detection and response. We can help a customer if they have somebody in the system and they found them. We can help with our simulations to tell them where could they move within the system because we know the attack paths. But there is no actual threat detection included in our software.

Yeah, because it almost looks like that. If you don't know that, you can't report it. No. It's all prevention that we have here. Right. And then you can also get a report for local credentials, for example. How many times did we find a local admin with the same password on different workstations? And there you have a hash here. Not the actual hash, but we double hash it again before we put it in our system. But we see, of course, the same hash on different workstations, so we know this is the same user. But there's also something kind of weird.

I mean, just because you see the same hash doesn't necessarily mean it's the same password. That's true. Yes. It could be. It looks funny. Correct. Correct. So we haven't really had that issue so far, usually when we found the same hash, it usually was the same password. Because you see the username, too. So it's username and password. And if you have them both together, and the hash is the same, it's very likely that it's the same password. Correct. But then you see also on which workstations or servers that this person has worked.

So you can also go there and make sure that the hash is at least not cached anymore, or we change the password. That's the better solution, actually. That the admin doesn't even go there anymore, or uses a different password for it. And you have the same with domain credentials. On service accounts, where you're using, not a password, but you can check the API key or something. The API secret that you have there? Yeah. If that's the same, if we can do it for service accounts, too. Is that something that just came up as we were talking? Yeah.

We do have API keys somewhere, too, but they're usually outside of the system. So you usually don't have it. You usually have them rather once they're in the system, then. Exactly. So this is rather than the breach that happens through this API from outside, because somebody is using their key from outside, and it's coming in. That's how we then try to separate the service, whatever the service account's using, from the rest of the network, so that they can't actually then go all the way in. So domain credentials is the same thing there.

You can also have these credentials, of course, cached on different devices. And we show that here. What I haven't shown you yet is that we can, of course, if we want to, we can also...

Oops, sorry. I want to stay here. I wanted to do this.

We can, of course, also look at the scenario itself, and how the attacker actually moved. So we can actually look at the paths. The path is unfortunately already there, so you already see it. But in the beginning, the system looks like this. You have up here on top left, you have the breach point. That's your partner portal. You have an internet entity up here, too. You then have AWS, you have your corporate network, and you have a secure zone down here. And what happens during the simulation now is that we're starting from the breach point. We're trying to see what can we first see.

We do the reconnaissance. What can we see from that breach point? Then we try to see what can we compromise, and then from there on, the simulation evolves. And so what do you see here as gray dots? Those are entities that have not even been seen yet by the attacker.

Blue, they have been seen. The reconnaissance has shown those stations. Red are the ones that are compromised. And of course, if you come in through the partner's portal, you're very likely to also have the internet entity already breached. And then when we go towards the end of the simulation, I'm not going to run through a simulation. It just shows a bunch of arrows, how they move around. But then at the end, you can click on a critical asset. In this case, I clicked here. I think that's the finance database, if I'm not mistaken.

Yes, that's the finance database. And it shows me how an attacker could go from the partner's portal to this finance database. And you see here are numbers. You see the different steps. You actually see it starts with 2 and 3. We're missing the number 1. Because number 1 actually happens here in the DMZ itself, in the partner's portal, where if the attacker gets in, the first thing they do is they set up a watering hole and they wait for somebody to come in. And that's number 2. This green arrow here, coming from, and you saw that person before, if I go here, it's in sales. It's this Olivia.

She showed up as a choke point. This Olivia is in sales and she has to work in a partner's portal. So she goes to the partner's portal and checks something out or puts some new content or whatever. And she steps into the watering hole.

We know, based on the green line, that she actually accesses the partner's portal. So it's not just randomly us coming up with somebody could be accessing the partner portal and then they get infected. But we know that this person does this on a regular basis. And because of this, we can then continue with the attack path and we see, and I mentioned that before, she actually has a Chrome that's not patched. And so then you can come in through the vulnerability. Then you go through local credentials where they find the same local admin password to move on to somebody who has access to the cloud.

You can steal from that person then the key to get into the cloud. And because they have read-write, you get all the way to the finance database. And so that's just one of them that you have here. But technically, you can now show all these different scenarios that you have. You can see how it moves. I think we had another. I don't really see the others. It's too small right now on this screen. Don't know where the other critical assets are. But you could check there, too, how the path works. To be honest, for the techies, that's always really nice.

So when I go somewhere and see only techies, then I show them only this, and they think that's amazing. For most people, that is not really the most important thing. I think the reports are what you then really have to go for because in the end, this is just a snapshot. This is just a single path. And we have hundreds of paths. And really bringing them together in one is the important thing.

Sometimes what I see is that an analyst, when they really try to figure out where did the issue come from, why do I have this problem, they might go here and try to really figure out what the paths mean and where the breach actually happened. But most of the time, we're in the reports. And so that's what I'm going to go back to. And I showed you before, or I showed you right now, this Olivia. And we have to sort here again. There she is. And so if I know that this Olivia is a problem, and she shows up as my number two choke point in the system, I can go on Olivia.

And the system then tells me, actually, well, we designed Olivia to have all kinds of flaws. Olivia has a bad Chrome. Olivia has Print Nightmare. Olivia has Blue Keep. Everything is happening on Olivia. And she has the local credential issue. You rarely have that, but it's a nice example. And then what you can do is you see here how somebody can then get from anywhere to Olivia. In this case, it's Print Nightmare. You can also here, you have all these different simulations that you can go through where Olivia was part of.

And you can also see how we then move from Olivia somewhere else to a critical asset. And as I said before, what you need to do is you need to make sure that your choke point is secure. So for your choke points, we give you all the remediations. And we also tell you for which attack technique this remediation is. Is it the local credential remediation? Is it the Print Nightmare remediation? And so on.

So far, so good? Yeah.

So far, good? Battleground, I showed you. What I wanted to show you also is the integration part. Because the system needs to be semi-integrated, we don't claim to be the best vulnerability management system in the world.

We don't, as I said before, we're not an EDR. So we need to have this input from somewhere else. And that's within our integrations. And so what we have is integrations, for example, for CrowdStrike or Microsoft Defender. As an EDR solution, that these two solutions give us the information which entities are critical in your system, which ones are most likely to be breached. And we can use those then in our scenarios as the breach point. So we can use those definitions from there as the breach point.

We can also, and this is an integration the other way around, we can deliver from our software then to Tenable, for example, we can deliver there the information, what are your choke points? So that when you go into Tenable, because you bought Tenable because you believe it's very good, and it is, then that you can go to Tenable, and when you look at the different patches that you have to apply, you will see which servers, which workstations, are actually considered choke points by us.

So you know that you can set a preference for those workstations or servers, rather than going through the list at all, in general. We do the same for SOAR, for example, for Cortex here, that we deliver them the information, what is a breach point, what isn't. And we do that also for SIEM, so Splunk and IBM QRadar, they also get the information from us.

GRI, I showed you, you also see up here always, is it actually active or is there an issue with it? ServiceNow apparently here in our environment has an issue, so it needs to be fixed and set up properly again. And very important, going back to APIs, we, of course, also have APIs so that you can actually read out the information from us, and so you have here, you get keys, and in Swagger you get documentation on how to take care of that.

And since it's right next to the tab that I just showed you, as I mentioned before, you can look at the GR tickets from in here, and you see the status right away, so that you know where you're currently at. And so with this system, we really believe that the customer has a much better chance to work on stuff and feel like they've accomplished something, because we can really give them a priority of their vulnerabilities, their exposures that they have. And we have it based on the actual data in the system. Questions to the demo and the software? Yeah? It's a combination.

So the question was, and I'm repeating it for the people who might watch it online, the question was, how do we get the information about whatever is in the system, the management of the devices. And so for on-prem systems, we have to deploy a sensor. There's no way around it because otherwise we don't, well, you can call it an agent sensor, whatever you want. We call it a sensor because we have a completely passive sensor. It only listens to what is happening and then brings that over to us so that we can do the simulation properly.

And so for on-prem, you then get the information through the sensor. It gets it from right there. For the cloud, all you have to do is integrate the cloud in the system. So we need an account for the cloud. And once we have that, then we also get the full information of what is in the cloud. And that's how we do the device management there. You also mentioned that you look into more complex things like tiering of active directories and such. Where do you get the necessary information for that from? The tiering we don't actually get. So we don't know if they're tiered or not.

The only thing we can tell you is that we saw a whole lot of local credentials or domain credentials cached in workstations or in servers or on the cloud. And so based on this, we can tell you we don't think you're tiering because we found the same credentials on the server as on somebody's workstation. So that's how we then start the discussion actually with the customer on that tiering would probably be the solution that they need to go through. But we can't tell if they have been trying to tier or not. I saw a lot of stuff there about AWS, for example, and IAM.

And it's one thing it'd be easy to figure out, okay, great, I'm going to set you up with my AWS, what the roles are and that sort of thing. But does it go deeper as well to understand what the S3 buckets are or anything like that, or where the databases sit on EC2? How far can you actually detect? To what level of depth, I guess, can you discover?

So, I mean, we get all the databases. We know what buckets you have, what kind of storage you have, what kind of VMs you have, all this stuff. As you might have seen before, we also get Kubernetes now, where we can add all the information on the different nodes that are in there. We don't try to get any information what is actually on there. So if you've labeled it wrong, we'll probably not figure it out. We have no idea. We just go by the labels that you have, and then we go by whatever activity you see there.

Because in the end, none of the information as in any of these entities will be moved to our sites for the simulation. We're not interested in this. And we also don't want to be responsible for it. Yeah. That's correct. Yes. Yes. We get from the different sensors, we get the information, what IPs has this workstation, for example, been in contact with, what credentials are on there, what users are on there.

We, of course, see what ports are open, things like this. That's the information that we move into our clouds to then do the simulation. And from there, then, we do the actual simulation, figure it out. Yes. That's a very good point. And I'm actually going to get there in the presentation as the next step.

No, no, no. It's a nice transition into my next few slides.

Because, yes, as you just saw, it's not trivial. If you have never seen anything about security, you don't know about how to set up your systems for it to be secure. You will not figure out what's going on there. And that's why we have the Customer Success Management team in all the regions worldwide that help the customer first to figure out, in some cases, what are they actually trying to protect. So that's where we start really from scratch. What is a critical asset?

I think, in the meantime, most bigger companies that have a real security team, they know what the critical assets are. But you still find lots of customers, especially medium-sized and smaller ones, who don't actually know what the critical assets are. So we start there. We discuss with them, what could your critical assets be? And then we define the scenarios. Where do you think your attacker could come in? Where do you think they might want to go?

And then, afterwards, we set up the whole system for them. We set up the first scenarios for them. And we help them with their first few issues that they find. And we give them the tips, and we tell them what we would recommend to remediate right now. You have recommendations in there.

Usually, to be honest, the recommendations don't necessarily have to be CVEs. But the very first thing we usually tell the customer is, do CVEs, because you can patch them so easily and so quickly. Do those first, and then continue on from there. And so we really try to help them, guide them through the software until they really figure it out themselves, until they can really use it themselves. We have online learning systems for this, so that they can also get a certificate and learn how to use it properly.

In the beginning, especially, we're high-touch to make sure that they understand what they're doing there. Because, yes, there are a lot of things that interfere with each other there, and you really need to understand what's going on. It's tricky, isn't it? Because what I really love about your approach is to say, okay, here's a way how to fix the, like, I don't know, 2, 5, 10 percent of vulnerabilities that count, which I think is especially appealing for mid-tier companies with any small and non-existent security.

But then there's this chicken-and-egg thing where, in order to come to that point where you can identify these things, you need to actually have a clue. Yeah, it's true.

And so, next slide is what we've realized. We've realized that we need to figure out with the customer how to set things up, how they resolve things, and so on. And we just came up with the Exposure Management Service now, I think a month ago.

Well, we didn't come up with it, but we established it a month ago. And that's exactly there. That's what we're trying to do. This DMS is more meant for large companies where the issue there is rather that you have a whole bunch of different divisions that have their own security teams, and then you have a bunch of different IT teams that do security somewhere else, or you potentially have a bunch of subsidiaries that do their IT separately.

Now, this one is not talking to this one, but that one is not talking to this one either, but these two are talking, and it's a big mess. And so, for these larger companies, we now have a few that have bought this. The point there is really that we have somebody on our side who gives all of these different teams a report on a very regular basis, sometimes on a daily basis in the beginning, sometimes on a weekly basis, whatever they want.

But that person is trying to align these different teams internally, because usually they don't have one that is just an XM Cyber alignment person, so that we have one person from our side who does the alignment between them, even talks to the IT team, and sends your tickets to the IT team, where we do the integration so that our person can send them tickets, and then they can follow up. They can check if it's actually been done.

So, for large companies, you have that issue too. It's a little different than what you just mentioned, because for the small and medium-sized businesses, we see the same problem too. They need somebody who can help them more because of what I said before, the 20 to 50 IT people who do IT admin and set up iPads for people, when they have their two to three hours to secure the network, they don't know where to start.

There, you also need somebody who can help them, who can quickly make a priority list for them, and tell them, look, give this to the IT team. Maybe we even write a report already for the management or the IT team to tell them, look, that's why you have to do it. For the smaller and medium-sized companies, we don't necessarily do the service ourselves.

There, we have partners who do it there, but you're right. The software itself is a visualization of an issue, but the next step, the company has to do themselves, and the best we can do is help them to make that step that they actually work on these topics. Just buying a vulnerability management system will not make you safer, unfortunately. And just a few words about XM Cyber. We've been around for seven years, have been bought by the Schwarz Group. If you're from Germany, that's the Lidl Group.

Actually, in the meantime, you can say that if you're from the US, you can also say it's the Lidl Group. Everybody knows Lidl. We belong to them now. Headquarters in Israel, that's where it comes from. But we also have people, most people here in Europe, but also a few in the US and a few in Asia. And then we have, of course, all the certifications that you need for security. That's all I have for you. It's not quite an hour. I hope you're not too disappointed that it's not another half an hour more. Do you have questions? This one? That's an XM Cyber person, correct.

The green one is the customer, but the EMS engineer is ours. Yes. Good.

Well, thanks for coming. I'm so glad I wasn't alone here. Enjoy the rest of Cyber Revolution and I hope to see you around. We have a big booth. If you want to come over, if you want to see more, just come over and we'll do some more demos. I have some colleagues there who can also show you more information. Thank you.