Continuous Exposure Management – XM Cyber

Welcome anyway, Eva for the 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 to ask questions. The motto of the presentation is Fix less, prevent more. That's XM cybers motto, you don't work and work and don't get anywhere. My name is Andreas Haldi. I am 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 EXIM Cyber for support of our customers. So the question I think that everybody is asking themselves here around today and 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? And so this is actually what you're gonna see later. Also in our, 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 ADMZ, 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 you definitely, everybody has an EDR somewhere because you don't want anybody to come in and you wanna somehow detect this and respond to it when an attacker comes in somewhere into your network. But it is unlikely that you're gonna catch a catch a hundred percent at one point.

There is gonna be somebody in your system and now they're trying to find their way to whatever you have as critical assets in your company and they're gonna 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's checks if the cloud's 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 somebody. You don't also, 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 gonna go and and and fix stuff you 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 'em and fix them 'cause 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, the vulnerabilities, the exposures is trying to make a list for it of what to do.

But of course they're struggling because they need to kind of, they need to mo motivate the IT team. They need to tell them 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, and the lists always get longer. They usually don't get shorter and it's things are just getting worse. So what do you usually have?

Most companies have some sort of vulnerability management system for CVS where they get a long list of cvs 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, you do get some that's true. But they're usually very focused. You target your red team on specific path. You want to tell you tell them this is where you come in, this is where you're gonna go. And that's what they're gonna do. It's not comprehensive. They also just don't do it. They do it like once a month or once every three months depending on how much money you wanna spend. But you don't get your security posture every day. This can be done with a a, an actual pen test team. And of course they do it on a live system. So you running the risk that something's gonna go down.

And also what we've seen quite a bit, you're running the risk of Leal leaving breadcrumbs in your system. So this is what we are 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 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? 'cause 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 where 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 to remediate a lot less. And what we are 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 that 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, little 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 reds, the red arrows are the attacks.

So you have here for example, these VMs that that can be compromised. And you know, let's say we actually found a high severity vulnerability. If you have a VM tool, it's gonna tell you, you gotta fix this. But why? Because once you're on this vm, nothing else is gonna happen. So unless there, 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 gonna 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, the tech 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 is still there. We gonna 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 a million dollars a year.

Again, it's an assumption, it's probably not very accurate, depends on the company, but that's a high number. So we have a couple case studies here too. One is a co company with 30,000 employees. This is our dashboard is, you're gonna see it in a in a minute in live we always give our customer a current security score and the grade. And 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 do 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, a cloud environment mostly. And they have ADMZ and we said the bridgepoint is in DMZ. And we wanted to see for ransomware purposes, how far can an attacker grow? 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, is a mistake. It's an issue too. But unfortunately that happens quite a bit. So I have seen myself, I have 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 is there, but it didn't do anything. Now I admit not every customer is going to be like this.

These are, especially the bottom one is an exception. You're, you usually don't, we don't get such such quick and easy wins. And even the four months is, that's, that's a company that really tried very hard to get there. And in the end that's what usually comes to it's, 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, 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, it's a company effort. It's not just the security guy. The security Analyst will, will fix all these things, but it can be done as we can see here. So what we're trying to also do in, in our software then is that we are trying to live this whole topic of continuous threat exposure management, the CE, there's not anything new, but we're trying to have almost everything including the software so that we do the scoping first we figure out with the customer what scenarios do you wanna set up? Where are your most like 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 locked out. But we're gonna 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 wifi connection here. There we go. Here again, you see the different scenarios. You see that the, the scan or the the, 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 gonna get to all these reports on the bottom later. We're gonna go step by step now through the CEM 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, on how this can be done. So we'll set up one that goes from the, the partner Porwal to let's say the customer db. And then you can select, select the scope. In this case, this is a a hybrid scope. So I need the on-prem and I need cloud. But technically you could decide I, I only want to have here something that, I wanna 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 or GCP. We don't wanna 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 customer Porwal. So I I can select here the computer, which is the partner Porwal. Oh type up. 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? Like It's all auto discovered.

You can label stuff yourself if you wanna, but if you've labeled everything in your network properly, it's all gonna automatically pop up here into the system, okay? 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 was auto discovered.

Here I do, it's a cloud and, and we do a customer database and I have a lot of typos today. And you know, you take your one of those, you could also take 'em all. That's an easy tool. 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 from this whole simulation, you can do this also here. And as I mentioned before, you can then you could here set this to dynamic breach points.

If you have more than one breach point, you can say just you, 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 wanna overload it with too many beach points at, at the beginning. 'cause otherwise it's, it's gonna have a hard time finishing in that one day.

But it, it runs every day. As you see it's automatic. You can also do it manually, you can run it here, it's not, 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 done here somewhere. Workstation's the 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 base, a daily basis. How good has it been lately in this case actually a hundred percent we're compromised here. So it hasn't been quite as good as it's as 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. 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 gonna 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 much do you act? Well 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 log four J 34 machines, 34 entities are affected with the log four J vulnerability. But only two of them are actually on the path, the 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, two issu, two, 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.

And 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 actually works. I think the log four J is one that most people actually know. So I don't have to go more specifically into this, but you have links to to the 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 exp 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 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 pa, the bandaids, if you fix one of those, then this issue is gone for log four J for CVEs usually people picked up because usually there is a patch or something and then the remediation's done, it's gone. For active directory problems, eh, sometimes customer doesn't really want to go and follow the remediation because maybe one of their, one of the, the, 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 wanna 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 wifi, there we go. You select your project that you have in Jira, make an issue type and then automatically fills everything it fills for them what they're supposed to remediate.

It will attach a 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, that's one way to be honest, I think most of our customers use this report mostly 'cause it gives them an 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. 'cause 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, you know, they have two, three hours of security work that they can do. They take this list and they fix two workstations that have a log four J 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 shore 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 bridge point to reach it There. I think the interesting thing is 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 bridge points. Is the bridge 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, your domain admin and your you're in. The more interesting report is actually this one, this is the, the choke point report here will list all the entities. Entities by how many critical assets they actually help 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 chromex load and that's rather easy to remediate. Quick question. Yeah. So to be clear, so are you saying like that former report? Yeah.

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 are doing prevention. We're not actually detection isn't really part of the Correct, correct.

Yeah, we don't do detection 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, move within the, within the system because we know the attack paths but there's no actual threat detection included in in our software. Yes.

Yeah, Because it it almost looks like that. And if if you don't know that Yeah, from that report sometimes.

No, it's, it's, it's all prevention that we have here. Right. And and then you can also get a report for local grid credentials. For example, how many times did we find a local admin with the same password on different workstations? And and there you have a hash here that's not the ha the actual hash, but we double hash it again before we put it in our system.

So, but we see of course the same hash on different station workstation. So we know this is the same user consulted Or something, right?

Is that, is that weird? Like, or I mean just because you see the same hash Yeah. Doesn't necessarily mean it's the same password, right? That that's true. Yes. It could be. It looks funny.

Correct, correct. I I don't think we've really had that issue so far that we usually when we found the same hash, it usually was the same password because it's still, it's still you, you see the username too. So it's username and password and if you have them both together and, and the hash is the same, it's very likely that it's the same password. Correct. But then you, you see also on which stations which worst stations or service that this person has worked. So you can also go there and and and make sure that the hash is as at least not cached anymore or we change the password.

That's the better solution actually that, that the admin doesn't even go there anymore or uses different password for it. And you have the same with domain credentials, password for On like service accounts where you're using like not, not a password but you, you could check like the API I key or something. Not the key but the, Whether that's the API secret that you have there. Yeah. If if that's the same, if we can do it for service accounts too, that really matters Per se.

But is that something that just, that just came up since you're Talking Yeah, you, 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 'em rather once they're in the system then. Exactly.

So it's, so it's this is rather than the breach that happens through this API from outside because somebody's using their key from outside and coming is coming in, right. So 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. But domain credentials is the same thing there. You can also have these, 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 wanna stay here. I wanted to do this. We can of course also look at the, the the, the scenario itself and and how the attacker actually moved. So we can actually look at the paths and paths are unfortunately already there. So you already see it. But in the beginning the system starts, looks like this. You have up here on top left, you have a breach point that's your partner Porwal, 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 nce, what can we see from that bridge point? Then we try to see what we can, what can we compromise. And then from there on the simulation evolves. And so what 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, the recognition has shown those stations red are the ones that are compromised.

And of course if you come in through the the partners Porwal, you're very likely to also have the internet entity already breached. And then when we go to towards the end of the simulation and we're not gonna 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.

Yeah, that's the finance database. And it shows me how an attacker could go from the partner's Porwal to this finance database. And you see here in numbers, you see the different steps. You actually see it starts with two and three we're missing the number one 'cause number one actually happens here on in the DMZ itself, in the partners Porwal where if the ta, 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 two, 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, this Olivia is in sales and she has to work in the partners Porwal. So she goes to the partner's Porwal and checks something out or puts some new content or whatever and she stepped into the watering hole. We know based on the green line that she actually accesses the partner's Porwal. So it's not just randomly us coming up with somebody could be accessing the partner Porwal 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 I mentioned that before, she actually has an A Chrome does 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 because they have ReadWrite, you get all the way to the finance database. And so that's just one of them that you have here.

But technically you have, you can, 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. Dunno where the other critical assets are. But you could check there too how the path works. To be honest, I, I mean for the techies, that's always really nice. So when I go somewhere and see only techies, then I show 'em only this and they, they think that's amazing. But for most people that this is not really the, the most important thing.

I think the reports are what you didn't 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 some 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 where the breach actually happened. But most of the time we're in the reports.

And so that's where I'm gonna go back to and I showed you before or I showed, 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, you rarely have that, but it's, it's a nice example. And then what you can do is you, you see here how somebody can then get from anywhere to Olivia. In this case it's a print nightmare. You can also hear, 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 good. Battleground I showed you. What I wanted to show you also is the integration part. Because the system, it 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 bridge point.

We can also, and this is a a, 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, 'cause he bought Tenable because you believe it's, 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 pre, you can set a preference for those workstations or service rather than going through the the list at all. Or in in general. We do the same for, 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 for us from US. Jira 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, coming 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 in, you get keys and you get in swagger, you get a 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 JR 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're accomplished something because we can really give them a priority of, of their vulnerabilities, the exposures that they have. And, and we have it based on the actual data in the system, Questions to the demo and the software. Yeah. I assume that the, the asset list you showed before come through an integration with an asset management system or, or or do you have your own? It's it's a combination.

So the question was, and I'm repeating it for the people who might watch it online, a question was how do we get the, the information about whatever is in, in, in the, in the system, the, 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 it's a, 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. If it gets it from right there for the cloud, all you have to do is integrate the cloud in the system. So we need, we need an account for the cloud. And once we have that, then we also get the full information on what is in the cloud. And that's how we do the, the device management there. Okay. You also mentioned that that that you look into more complex things like tiering of active directories and such like Yep. Where you get the necessary information for that from The tiering.

We don't actually get, so we don't know if, 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 service or in on, 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 starts the discussion actually with the customer on that tiering would probably the solution that they need to go through.

But we can't, we can't tell if they, they have been trying to tear or not. Okay. Yeah. Was just Wondering.

Yeah, I'm have a follow onto to that. Yeah. So I saw a lot of stuff there about AWS for example.

Im, yeah, And It's one thing to, I, it'd be easy to figure out, okay, great, I'm gonna set you up with my AWS and you can figure out what the roles are and that sort of thing. Yep. But does it go, does it go deeper as well to understand what the S three buckets are or anything like that?

Or is it, or where the databases sit on EC two or how, how far can you actually detect to what level of depth, I guess? Can you, can you discover? So I mean we get, we get all the databases, we know what buckets do 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 get 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 haven't, 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 we, there's no, none of the information is 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. Did I get that ride that you kind of, when you, when you do these attack scenarios, did they get that right? That you basically model all of these by yourself? That's correct. Yes. Yes.

We get from the different sensors, we get the information, what IPS has this, this workstation for example, been in contact with what, 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. But in order to meaningfully use this, then the customer would need someone who kind of is methodically able to, to model this, having knowledge about mitral pattern, stuff like that.

Yes, that's a very good point. And I'm, I'm actually gonna get there in, in the, in the presentation as the next step. Don't lemme preempt you.

No, no, no, no. It's, it's a, it's a nice transition into my next few slides because yes, as, as you just saw, this is, it's not trivial. It's not for, if you have never seen anything about security, you don't know about how to set up your systems to be, 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, in all the regions worldwide that help the customer first, first to figure out in some cases what, 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 their critical assets are, but you still find lots of customers, especially medium sized, the 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, 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 'em 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, and so we really try to help them, guide them through it, the software, until they really figure it out themselves. Until they can really use it themselves. We have online, online learning systems for this so that they can also get a certificate and learn how, how to use it properly.

But yeah, in the, in the beginning especially we're, we're high touch to make sure that they understand what they're doing there. 'cause yes, there, there are a lot of things that interfere with each other there. And you really need to understand what's going on. It's a bit, it's a bit 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, two, five, 10% Yeah.

Of, of vulnerabilities that count. Right? Which I think is especially appealing for mid-tier companies with a small and non-existent security team. Yep. But then there's this chicken and egg thing where in order to come to that point we can identify these things. You need to actually have a clue.

So Yeah, that's, it's, it's true. It's true. And so next slide is, is what we've realized. We've realized that too, 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 this, 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, that's what we're trying to do. It's act, 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, you potentially have a bunch of subsidiaries that do their IT separately. And now this one's 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, 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 them, 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 XEM cyber alignment person. Right?

So that we have one person from our side who does the alignment between them, even talks to the IT team and sends Jira 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.

We, they need somebody who can help them more because of what I said before, you know, the 20 to 50 IT people who do it admin and, and set up, I don't know, iPads for people when they have their two to three hours to secure the network, they don't know where to start. And 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 their 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, it's, it's a visualization of an issue. But the next step the company has to do themselves and we, the best we can do is help them to make that step that they actually work on, on these topics. Just buying a vulnerability management system will not make you safer, unfortunately.

And just a few words about XM cyber we're, we've been around for seven years, have been bought by the Schwartz group. If you're from Germany, that's the legal group actually in the, in the meantime you can say that if you're from the US that you can also say it's a lile group. Everybody knows Lile, we belong to them now and headquarters in Israel. That's where it comes from.

And, but we also have people, most people here in Europe, but also a few in the US and, and a few in Asia. And then we have of course all the 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. A little more. Do you have questions? I just wanted to clarify in that slide about the, if you can go back two slides, Two To the Right. This one. So Where I see the Eem EMS engineer.

Yeah, those blue thing. Those are all Your, that's an XM cyber person, correct? The green one is the the customer. Okay. But the EMS engineers ours. Yes. Good. Well thanks for coming. I'm so glad I wasn't alone here. Enjoy the rest of cyber revolution and hope to see you around. We have a big booth if you wanna come over, if you wanna 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. Very good.