Thank you so much for coming to my talk today. I am super excited to be part of comfort two cloud native 2024. And today I'm going to be talking about synthesizing threat informed defense when cloud attack emulation meets detection engineering. All right, a few words about me. I'm the CTO and one of the founders at Mitigant. Mitigant is a cloud security company. These I breathe in Berlin. I have spent about twelve years in cybersecurity. Within these years I've held different positions. I've worked in academia doing academic research. During my research, I was one of the pioneers of the concept of security chaos engineering. But I also worked in the industry, in different startups and held different technical positions. And I am a member of the AWS community builder program. All right, so what are we going to be talking about today? We are going to be looking at a few topics. First we will look at trade informed defense and then the three pillars that constitute this concept. Then we will look at adversary emulation, and then we will go and look at cloud attack emulation, which is actually a subdomain under adversary emulation. Then after that we're going to be looking at a use case where we see how we can use cloud attack emulation to validate cloud trade detection. And I will give you a very brief demo of the mitigan cloud attack emulation platform. So let's get started. So, cybersecurity, the domain most of ours are, it's a very noisy domain. It's noisy in this sense because there are a lot of attacks, and we hear of attacks virtually every day on the news. We hear of different companies, we hear of different threat vectors, and it sometimes gets a little bit challenges to be able to sift these noise. To sift the signal from the noise. And what I mean here by signals is kind of how to know what part of this news that is more important to you, what part of it is relevant for you, relevant for your organization. And I compare it in a way to the needle in the haystack problem. So as you see in this picture here, you got a needle and the needle is very little. And if you drop a needle in these haystack, it's kind of challenging for you to kind of identify the needle. So it's kind of the problem we have in cybersecurity. Probably not as complex as defending needle, but you get what I'm saying. And the ability to be able to sift the signal from the noise is very important because the signals is what you want to be focused on the noise will eventually distract you and reduce your proactively, and if you're not careful, will be the very problem, or let's say, will be the very reason for which you might be attacked. So that leads straight to trade informed defense, which is by definition, these systematic application of a deep understanding of adversary tradecraft and technology to improve defenses. And this is the definition that has been provided by the mitre ingenuity, which is basically the center for trade informed Defense. It is a non for profit organization in the United States. And they came up with this idea which you can use as a strategy for your company to ensure that your security architecture is effective, it actually works and is able to toward attacks. So we're going to be looking deeper into what this means. We hear about it every now and then, and I took a look at what this informed defense means, and that's what we're going to be exploring. So there are these pillars of trade informed defense, as we see in the symbol in the last page. And the first one is defensive measures. So what is defensive measures? So basically, the moment you begin to talk about the defensive measures, you are basically looking at the security controls, the security tools, the security strategies that you're actually going to be implementing to help you to stay ahead of attacks. And one of the major reference points when it comes to defenses is the Mitre attack framework. And the Mitre attack framework itself, which is also another program by Mitre, which is also a US government agency or non for profit agency. It is basically a globally accessible knowledge base of adversary tactics and techniques that is based on real world observations. And here it's very important for you to take note of adversary tactics, which is basically the way attackers compromise systems. And also, it's important for you to take note of real world observations. So these are based on real attacks that are happening and not theory. So they try to kind of focus on real attacks rather than theoretical attacks, rather than attacks that people are thinking that will occur. These are actually based on different companies that are part of this program. They monitor devices, these monitor, they're being used by different companies and they're gathering this information. And they are basically kind of using this to understand how attackers compromise systems, how these compromise organizations, and they classify these under different tactics, and also under these tactics also have techniques. And we're going to be looking deeper into these in the next slides. So the Mitra attack framework itself is divided into, let's say, technological categories in the form of the enterprise matrix, which basically looks at most systems, whether web applications, cloud systems, software as a service systems and so forth. We also have the mobile matrix, rooks and mobile applications, mobile technologies, and we have the ICs, which is the industrial control systems. But today we are going to be focusing more on the enterprise matrix, which has us at version 14, which is the most recent version. It has 14 tactics and 234 techniques. That's a whole lot of, let's say it's a lot. And most companies cannot. Even if you use a tool that implements all of these techniques, it is very difficult for you as a company to focus on all of that. Right. It's going to be overcoming the idea. These, which I want to really state is the idea is not to cover the entire tactics and techniques, but to kind of select which of these that is more relevant to you. All right. And this is kind of a larger view for you to see. But ideally, you're not going to be covering every of these techniques. What you will do eventually is something like this. And this visualization is created by van Vlad. He wrote a very nice blog, which I will leave the link in the slides. And basically here you see out of 14 tactics, you have something around seven. And from there you see these clusters represent techniques which might be clustered. So under each tactic there are techniques and there could also be subtechs. And you also see this red line, which kind of shows how an attacker will navigate through an infrastructure. And this line most likely kind of determines for you what is relevant to you, what you have to really take care of what is important for you. And you can see that in the end, it really slings down the areas that a company should actually be really concerned about. All right. We just looked at the first pillar, which is kind of looking at what you do, but that's not. All right. The second pillar brings in more context. And the second pillar is basically cyber threat intelligence. And what is cyber threat intelligence is basically information that has been aggregated, transformed, analyzed, interpreted or enriched to provide the necessary context for decision making. And you have to understand here, we always say in cybersecurity, that context is king. Context is what differentiates you from other organizations. You got to know your context. And cyber threat intelligence helps you to kind of fine tune your context more. It helps you to further sift the signal from the noise. And again, the mitre actually also has a section here, as you see here, where they provide cyber trade intelligence, which is here they actually talk about different trade actors, and they describe who they are. They describe the campaigns that they've noticed these trade actors to be involved in, in real life and also talk about the map. They provide a mapping of these threat actors to the tactics and techniques that they have observed them using, and that narrows down your focus as a company. So, for example, scattered spider has been notorious in the last two years. They were behind the ransomware attack against the MGM resorts in the United States. And they're actually interested in a specific sector in not all verticals. I think they're interested in entertainment. They're interested in telecommunications. They're interested in technology companies. And this already gives a kind of definition of these sectors that should be interested in implementing defenses against scattered spider. Right. And this is actually the mitre attack navigator, and it's also free, and it helps you, as I said before, it creates a mapping of threat actors to tactics and techniques here. These orange colored techniques are actually the ones that scattered spider implements. And you must understand that I already kind of slimmed down this mitre attack. The techniques slimmed it down to the ones that are related to infrastructure as a service. And this is all possible. You can actually sift and just narrow down to the areas that are more relevant for you. And in the end, you have a very minimal techniques to be concerned about. Okay, so let's go to the third pillar, which is testing and evaluation. And this is a pillar that is mostly not talked about, right? Most of the time when people talk about the miter, when people talk about a threatinformed defense, they kind of talk about the defensive measures. These talk about cyber threat intelligence. Testing and evaluation is most of the time not discussed. And I'm going to be talking more about this aspect because you have to understand that these three pillars are complementary of themselves, and they work together as a feedback loop. So none of them is more important than the other. And if actually want to have a very robust and a very efficient security strategy, you have to implement the three pillars and you have to make sure that they work together in synchrony. So testing and evaluation, Basically, Mitre engineer recommends these use of adversary emulation for testing and evaluating your defenses. And why is that? We will see a bunch of questions in the next slide. But adversary emulation, simply put, allows you to mimic the behavior of real world threat actors in a safe and in a repeatable manner. This is very important because in cybersecurity, we have different kinds of security testing. We got penetration testing, we got vulnerability assessment. There's a lot of security testing methodologies. But when it comes to trade detection, trade incident response, you want a testing methodology that mimics the exact behavior of how attackers behave in the real world. You want something that is really close. It's a very close semblance of attackers behavior, and you want to do that in a safe way. And most importantly, you want to do that in a way that's repeatable, meaning that you can do it multiple times. And the reason for this repeatability is because when you go through this process, you want to test again your defenses and to be sure that after hardening, after improving, you see some progress. So that's the reason why it's important that these testing methodologies are repeatable. All right, now these five questions are actually questions from the Mitre ingenuity website. And I also left a link below here. And these questions are very important because they help you to kind of determine whether you need adversary emulation. It kind of also provides more context to the reason why adversary emulation is, is kind of recommended for testing trait detection and incident response. So the first question is, how do we build a resilient defense that is not static and is easily and easily evaded and indicators of compromise. So how do you have a defense that it's not static, it's dynamic in nature, and it cannot be easily evaded, and it gives you a very clear indicator of compromise. So indicators of compromise are events that are indicative of an actual attack. Adversary emulation helps you to kind of satisfy this requirement. These next one is how do we detect, mitigate, respond to, or prevent against threat actor X. Here you are talking, as we saw in the last slide, we were looking at a specific threat actor, scattered spider. And this is kind of the questions you ask yourself if you are trying to defend your company against specific threat actors, and there's a narrow focus here, and you want to prepare that either you can detect activities that indicate these threat actors, or you can mitigate, or you can respond to these activities, or you can actually prevent them from occurring in the first place. Right. So let's move forward to the next question. It says, are we collecting the right data and run the right queries to detect technique y. So we talked about techniques. Techniques are basically how threat actors behave, how they attack, the kind of tools they use, and the way most threat detection systems work is they collect data. These data are in the form of log events, and then they perform some kind of queries over this data. And from that they're able to conclude that these are kind of indicators of compromise. And oftentimes you might not have the right data, oftentimes your queries might actually not be correct. And for you to reduce problems like false positives or alert fatigue, you have to use the right data sets. You have to perform the right queries. Otherwise, so it's kind of, in the beginning, it's like try and error, and adversary emulation allows you to kind of get this right. And we will see later in the next slides, we're going to see much more, let's say much more good examples. So next question says, how do we build experience and skills on our team to defend against real world trades? So I like this part because you see these, that it's kind of moving from actual technology, the technological aspect of cybersecurity. It's moving to the people aspect. So the people, when you talk about people, you begin to talk about experience and skills. And this is really important because oftentimes it's not just about technology, right? We have this concept of people, processes and technology. And you always have to think not just about these technology, but the people, because the people are very important. Even if the technology, if you have the best kind of the best products, if the people are not able to know how to use them properly, it's still going to be challenging, it's still going to be attacked. And the last question says, how do we tune our tools and processes to maximize efficacy against real world threats? All right, so here we're talking again about tools and processes. Remember, I talked about processes. Processes are very important. Tools are also important, but they have to be tuned. Right in the beginning, we started talking about noise. And remember that one of the major reasons behind trading from defense is to allow us to be able to sift signals from noise. And even the tools and processes, they might become noisy, and you have to tune them, you have to customize them. And adversary emulation actually helps to go through this customization in a very efficient manner. Okay, let's look at an example. Now, this is a very interesting example of a company that uses adversary emulation. This is GitLab. And actually, this is all open. So in the link here, if you go to this link, you will see GitLab talking about their purple team and red team operations. And they actually call it stealth operations. So basically, they do this attack emulation without telling the company. So they do it in a clandestine manner. And just very few managers and very few people are aware. And what I wanted to point out here is just the process here. So you see, there are three main phases of this attack emulation, adversary emulation, attack emulation, actually the same thing. You got the attack planning, you get the attack emulation. Itself. And you got a conclusion and you see that it's color coded. So these purple colored circles represents activities that are shared between the red and the blue team, and the blue colored ones are the blue team. And then you have the red team owning these red colored circles. And so you see that there's brainstorming, there's logistics part, there's adversary profiling, which is actually where they are doing research to understand the kind of adversaries they should focus on. And they do some tabletop exercises, and then they develop capabilities. Then they emulate attacks in step six, so they don't just start emulating attacks right from the beginning. Step seven is validate detection and response, which is actually a function of detection engineering to a very large extent. We're going to talk more about that. And they write a report in the eight step. And finally, there is a retrospective where they come together and sit down and look at the learnings, what they've learned, and they actually discuss with the right team, could even be the DevOps. They talk about what they learned from this exercise, what are the takeaways, how can they improve? And things like that. All right, so now we're going to talk a little bit about cloud attack emulation. So cloud attack emulation, putting it in a very clear, straightforward way, is adversary emulation for the cloud. And at Mitigan, we actually, because our focus is cloud and cloud native technologies, and we basically have taken the whole idea, the concept of adversary emulation, and we apply directly to the cloud. And the reason why we do this is because the cloud comes with very specific attacks, very specific problems, very specific challenges. And the best way to tackle these challenges is by narrowing down your focus to cloud, which is actually a lot of things if you think about AWS and you begin to spread to other cloud service providers like Azure, like Google Cloud, and even Kubernetes. And so we have designed this whole concept to be really cloud specific. Now we're going to be talking about detection engineering. So what is detection engineering? So detection engineering is an aspect of cybersecurity that focuses on developing, fine tuning and maintaining systems designed to identify and alert organizations to potential security threats, breaches, malicious or suspicious activities. And it's a very new, let's say, division or subdomain of cybersecurity that appeared just two or three years ago. And basically, why do we have detection engineering? So, like, a decade ago, most of our cybersecurity tools were kind of focused on prevention. So we had firewalls, we have web application firewalls, conventional firewalls, identity and access management. And all of these were basically on the front door, more or less kind of trying to prevent attacks coming in, inspecting traffic and all of that stuff. But as technology improved or let's say, got more complicated and things like cloud technologies appear on the scene, attackers, these whole peripheral defense collapsed. And now we have the cloud that has an open API that is exposed. And all of this has led to a scenario we find ourselves where attackers just jump into our system straight off. And because of this, the idea of detection and response, which before used to be really not very, people weren't really putting so much effort in detection and response. But now it becomes more relevant because you can't focus completely on prevention. You also have to take care of things that happen when attackers are already in your environment. And you have products like SIMs, these have extended detection and response, network detection, response, cloud detection, response. All these products have appeared on the scene to take care of this specific issue of detecting and responding to attacks that kind of circumvent these preventive controls. Right? So what do detection engineers do? This is a detection development lifecycle, which is highly inspired by the software development lifecycle. And if you look at it and compare with the software development lifecycle, you will see a bunch of similarities. And basically detection engineers and we will see some examples later, they basically are doing a lot of things, including trying to understand these way that attackers compromise our systems, trying to see whether our detection tools are able to identify the correct attacker behavior and trying to see improving that on the fly, which actually in a lot of times requires some kind of software development or some kind of bash writing, scripting and things like that. And this is kind of the workflow which most detection engineering teams kind of follow this process where they develop detection logic or detection algorithm. They push these, deploy it and they test it. And it's basically very similar to software development. And here we see an example of a sigma rule, and this is actually written in Yaml. And most of the detection response systems are using some kind of, let's say, format, which sigma actually tries to make these various formats to be interoperable. And basically this very sigma rule is, if you see line 20, 21, 22, is basically it detects when cloud trail is either stopped, it's updated or deleted AWS cloud trail. And this can be an indicator of compromise. It can mean that attackers are in the system and are beginning to tamper with your detection with cloud trail. And this very rule basically detects it. So this is a very good example, actually. All right, so now let's look at an example. And in this example we're going to be looking at how to validate threat detections in the cloud. And we will go through these three pillars that we discussed in the previous slides, starting from the top right here under the cyber threat intelligence. Let's say you kind of received intelligence report or your threat intelligence provider kind of told you about scattered spider trade actor, which we already talked about before. And the next thing you do here is let's say you have implemented some threat detection algorithms or you have a system that takes care of, that basically tries to identify scattered spider techniques. And here we are looking at this technique which basically is about credential harvesting. And these, the next thing here, which is the third pillar is you're going to be emulating this technique specifically to be sure that your detection is able to capture it, is able to detect it. So that all of the three pillars are put into. So this is basically our use cases AWS. And this diagram shows, kind of gives a very clear high level, there's an illustration of what we're going to be looking at. So on the left here we have the emulation which is here pertaining or let's say mimicking the attacker. And you have the AWS secret manager which stores different kinds of secrets, which could be API keys, could be tokens, could be other kinds of secrets. And just for you to understand the implication of this attack, if it succeeds, if it's a real attacker, if they are able to compromise your AWS secret manager and they get the keys, these, and let's say the keys are not encrypted, it means these have access to all of this stuff which could be access to your databases like RDS, redshift document database, your other applications, maybe kubernetes clusters, it could be whatever you're using the keys here to protect. And on the other hand here down below here we see cloud trail. So usually this is the setup most threat detection systems have. They are basically fetching logs from cloudtrail and basically cloud trail, it kind of collects different kinds of logs from different AWS services and they're fetching these logs. And here we have just for example, for the sake of this demonstration, we're going to be using datadog cloud CM, which is actually kind of a threat detection system. And on other hand here we have, let's say the admin, maybe like the security engineer who is basically in charge of this system. So here we see that we are emulating the attack and this is a screenshot from the mitigant attack emulation. And there are actually two attacks that we are emulating here. The first one is basically a malicious secret retrieval, and this is an implementation of the technique we saw before. There are two implementations. The first implementation basically retrieves these secrets. It's kind of limited, it cannot retrieve a bulk secrets and bulk, so it has to do one after the other. And the second attack here actually is doing batch secret retriever. And this is a feature that was released by AWS just in November last year, which allows you to say, hey, give me 20 secrets, for example, or 100. And basically you can take it with just one API call and that's kind of bad. So here is the cloud trail record that corresponds to these attack emulation. We can see the name of this event and here we're focusing on the batch meets secret value, which is the attack where you are basically fetching a whole lot of secrets. And you can see here that this is the secret ID list. This is about ten secrets that were fetched by this API call and you have it registered in cloud trail. Then on the other hand, remember I talked about Datadog and cloud CM, and this is kind of the Datadog investigator. So it kind of has this nice user interface where it shows you on these left here you have the mitigant role which actually emulates these attacks. And basically you see here the secret manager, which is a service that is called, and then this service basically has, we have done different activities here. What we're interested here is two. So basically there are 30 get secret value API calls. So this basically gets basically single, as I said before, single secrets. Unfortunately, the get bad secret value, it's not detected by this system, so it's not able to detect that. Also, there were calls that allowed here the emulation to be able to collect a huge amount of secrets with just one API call. And this is exactly what we are trying to say here, that the threat detection systems might miss some detections, either because the cloud service provider kind of had new APIs or they released new features, or even MIT attack framework had some updates which have to be kind of integrated into the threat detection system. So this is a very good example of what could go wrong. And what is the solution here. Again, we have gone back to sigma rule, and although this is not exactly what they use at Datadog, but this is just for the sake of kind of an illustration. We talked before, if you remember when we were talking about looking at the questions why you should use attack emulation. We were talking about whether we're getting the right data sets or whether we are making the right queries. So you can see between line 96 to actually 100 here that actually these query is made against cloud trail. And that is how this event is actually more like identified. This event of getting secrets is identified and what you can see on this line 98 is here a query to fetch get secret value. And this is basically here again we see that there is just the old API that is put into consideration. The API that gets a batch amount of secrets is not considered here and definitely that event will be missed. So to correct this problem, this query has to be updated and the correct get batch secret value has to be added here. And as simple as that, once that is added, you basically will be able to identify their tracks where batch secrets are collected. All right, so we're coming to an end now. So these are the resources that I want to leave. Most of them are blogs. I have written about the whole topic of threat informed defense as well as Mitre tag cloud matrix as well as threat led emulation, which I will just give a quick demo right away. So I just want to give a very quick demonstration of mitigant cloud attack emulation. And I am going to log in into my own account using the Google SSO. All right, so the platform has different products, but let's go straight to the cloud attack emulation and switch to this cloud AWS account. So what you see here are different statistics about attacks that have run before. And you can see the attacks by different metrics, for example by status, by service AWS services. And here are these tactics that have executed against different AWS services. What's interesting here is if you scroll down, you will see that we currently support up to title attack actions and we also support different attack scenarios. So the attack actions are things as simple as for example, we got the very popular one which s three, let me search for it. So we have public s three bucket and this one is very popular. And basically what this does, it basically goes to the cloud, looks for buckets that are private, and out of these private buckets makes one of them public. And the aim is to see whether the threat detection system is basically able to identify that event and it's also mapped to the mitre attack framework. We can see the tactic here is discovery and the technique is cloud storage object discovery. But we also have the idea of attack scenarios. So for example, different attack scenarios. We have ransomware for example. We have also the s three object exfiltration and the ransomware attack to run an attack is pretty much simple. So you just hit the run attack there and then you can select, let's say once you just select the attacks, they're queuing up there. So we've selected new Im user, let's select another one, disable s three login, which is basically going to disable the login facility for an S three bucket. And let's choose also public s three bucket, the one we just talked about. And basically on the right here you can see these attacks that I just selected. And there's this slot for attack objectives. So we say testing threat, right? So that's going to be documented and you can see the attack steps here, just kind of giving very brief descriptions of what you expect to happen. And then you can basically hit these start attack button. And this happens really fast because we're connecting over the AWS API, we don't install agents at all. And that makes it super simple to onboard your account and to also execute this mean to execute attacks. And what you can see already is the new im user attack is already completed and you can begin to actually look at what occurred. So we kind of print out some of the steps. You see the name of the user that was created these and it created a user. It created also API keys for that user and it also created a policy for the user. In this case, the user has, a policy has been attached to grant a user full access to s three. And these are all kinds of activities that a very robust system might not even permit it to occur, or there's going to be some notification being streamed to the tools at this point in time. And we see the other attack also already completed, disable s these bucket login. And what does it do? Let's have a look. So basically that attack. So basically it goes into Aws s three. It acquires the targets, it finds the buckets. It looks whether there's any bucket that is exempted with tags. So you can actually exempt some resources from being attacked using tags. And then it selects a bucket that has the login feature enabled. It disables it, which is kind of malicious, which is what attackers will do. And then it basically finishes. So let's see the comprehensive attack report. So here we see the comprehensive attack report steps again, which we already looked at. And of course there's a remediation section that we basically describe what you should do as a defender. And the attack evidence is being collected. So we're going to be getting some evidence from Cloudtreel where you will see the exact cloud trail record that was created due to these attacks. And we're going to get it because cloud trail doesn't provide it in real time. So it's going to take something around ten minutes for that to come here. Interestingly, I want to talk to you about this pain and recovery. So the cleanup is going to be automated. So immediately, let's say about five minutes after this attack has occurred, there's going to be a rollback, which basically means, for example, this new im user is going to be deleted along with all the resources that were created during the process of the attack so that it's cleaned. It's kind of back to how it was before the attack. Same team, this bucket that had the login disabled will be re enabled, exactly how we saw it. And the public bucket will also be taken back to a private mode, exactly how it was before the attack. So on the right here, you can see we already had written our attack objective, and you can also enter your observations here. So in this case, you go to the cloud or you look at your threat detection system and observe, kind of look at whether it was able to detect these activities, if it detected it, whether what it told you, whatever will help you to make the system to become more secure. You can note it here and you can always come back to these reports. All right, so I will switch back to the slide, and I think we're almost at the end of the presentation already. So that's actually the last slide. So thank you very much for listening to me. Feel free to reach out to me. That's my email here. I'm also on Twitter, and I'm always open to talking to anyone who wants to ask questions. Yes, thank you so much for staying this long for my talk, and I wish you a very nice conference.