 Well, thank you for joining me this afternoon for this talk entitled Cloud Native Thread Modeling and Adversary Immunization, Picnic Sanctuos. My name is Rafiq Harabi. I've been the IT ward for almost 15 years, and I've been with Cystic for three and a half right now, working mainly with the customer in Europe and Middle East on Cloud Native Security advocacy and moving them security to the cloud. Before that, I've been working on consulting, go-to-cloud programs, mainly with consulting companies like Deloitte and entity data. So there is my LinkedIn profile, my Twitter, please feel free to reach me. So what we'll be talking about today, we start by talking about the Cloud Native application building blocks, how it's different from the legacy world. Then we'll get into the multitude of cloud attack surface and the different challenges that it come with. Then we'll get into the thread modeling, the different techniques that we use for the thread modeling, following by the Adversary Immunization for Cloud Native application. And finally, you finish by listing the tool that will help you to do this stuff plus takeaways. So let's start. On open time, it was quite simple to protect monolithic application. They are deployed in a kind of VM or physical services. And what you need to do is just putting a kind of firewall or EDM in front of it to detect any intrusion. But this is a little bit different or totally different when it comes to the cloud. First, because the cloud services are public, they are exposed to the outside world, you have different services. They are living together in your cloud account, your cloud project organization. And you need to define the right control access for each team or each service. Also, this complexity of multiple services together generate a lot of logs, and it will be really hard to detect unusual activity. Let's see how the cloud native application is built. So we have the cloud infrastructure. Then we have the workload that can be containers, serverless. Maybe some workloads coming from on-prem, just shift and lift. And all this stuff is working on top of Kubernetes, whatever is managed by your teams or you're taking one manager service from the cloud provider or container as a service. And we have a batch of, let's say, satellite services that you need for your application, mainly everything around identity and access, a network like load balancing and so on, managing the services like logging and monitoring, and finally everything around data like databases and objects and storage. So this is bringing different layers. So we can see in the middle you have your code. This is your business application that is delivered. Then you get this layer of abstraction or separation that is the container, then another layer, which is Kubernetes. We can imagine that you are deploying your application in specific namespace, so it gives you another layer of abstraction. And finally, we have the cloud provider. So we have these four C layers. And the challenges that is coming with the challenges that you have, first dynamic surface attack. For the simple reason that your developer team or your services team, we need to go back to a kind of central or enterprise architecture and ask for modification. They have a panel of services that are provided on the cloud, and they can't pick and trade the architecture depending on the business requirement. The second thing that those bad actors that are trying to get into your environment and steer, for example, some sensitive document, they are using the same tool. So if you are using Terraform to accelerate your cloud deployment, they may use Terraform to deploy any malicious stuff. So they are using the same tool, and they are moving to the same speed as you, which is not the same in DIGA CO2. Distributed and microservice, distributed system and microservice, they bring a lot of intercommunication that will bring more and more cores generated. And by the way, it will be really hard to detect any unusual activity, plus the lack of visibility when it comes to 100 of microservices talking together. And finally, your security team need to follow the same step as you, which is a little bit challenging in the enterprise world. So before going into thread modeling and adverse elimination, I'd like to mention this phrase from John Lambert. He's from Microsoft's security team. And I like this phrase because it's describing the way that attacker think and the way that defender think. So what he's saying, he's saying defenders think in lists. So usually you have a list of compliance, or you have a list of stuff that you need to report to your management, or you need to report to the authority because you have some regulation to comply with. But attacker, they are thinking totally different. They're trying to move from one step to another until they get access to your system and get what they want to get. So this is really important to keep in mind that you don't have to think about leases and just the kind of check leases to say, hey, I'm compliant. But you need to think in a way how the attacker is going in order to be able to protect your environment and your enterprise. So let's go with a couple of definitions for the guys that are not coming from security background. Thread modeling is the exercise to identify the different building blocks of your system. Then you didn't find the threat and the mitigation for this potential threat. And it's always concerning valuable assets. Let's say if you have, I would say, images that you are using in your public website and they are exposed in a three bucket, you don't never mind if someone access and get them. So it's always depending if the data is valuable or not, or the asset is valuable or not. The adversary emulation on the other side is the exercise to use the same tactics, techniques, and producer coming with those bad actors to mimic these tactics and be able to see and to test your system resiliency against that. So here we are taking the choice of a bad actor trying to mimic the same activities and make sure that our system is resilient against those attacks. We have different methodology for thread modeling or different techniques. The most known is tried from Microsoft. They've been developed by Microsoft. And here we split the thread in six categories. We have also known other known methodology or techniques like attack tree, where we are dispatching the system in a kind of a route and different lives and children. And when everything is true, the different children, we can identify an attack that is possible. And finally, Dataflow, which is a kind of graphical representation of the user or the end user or any other user on the system. And it can define the different interaction between the different blocks and can spot the risky configuration. So the pillars are the system architecture. You need to make sure that you're defining your system architecture. And you need to make sure that you have a bunch of actors identified, either like the people that are working on the system, or the people that are on the other side, but actors, then listing the different threads depending on the interaction on the system, and finally defining mitigation. The slide approach is coming with six categories, as I mentioned, spoofing, tempering, refrigeration, information disclosure, those, and escalation of privilege. And how it's going? Let's say that we have this example of a digital bank. We define the different blocks, then we define the different interaction between these blocks. And finally, we define the kind of trust boundary when those services or these blocks can make it together to lately identify any weak point and potential threat. Yes. So let's define a little bit the person that I've been talking about, the business owner who need to balance between the business requirement and the security requirement, the application developer who is helping identifying the architecture of the application, and also implementing the mitigation. The adversary who is trying to put his element in the shoes of attacker and try to mimic the same tactics. The defender who will be thinking about implementing mitigation. And finally, the security architect who will be advising around the different best practices and regulations that the company need to be compliant with. So let's deep into the dread modeling for cloud data application. I'll be going from containers, Kubernetes to the cloud, giving some examples how we do that. So just I'm spotting here the thread, container thread, from OWASP. So we have a kind of thread that is coming from Legacy World, although they're already related to specific architecture of containers. So let's, first of all, define a kind of data flow diagram. So we have a developer who is writing code, writing the container manifest, maybe a Dockerfile or other technology. Then he's pushing these to a repository. And from there, we have the bead and the push of the container image to a kind of container registry here. The next step will be pulling into the container host whatever is Kubernetes or not. And then we have different communication. Either a container has a privilege to access to the OS and the kernel, or the container will go to the Docker engine for some activities, and finally it goes to the kernel. So this is the different, and we have also containers to container communication. This is coming, for example, if you have the different package services that they can't communicate together, or maybe they don't have to communicate by there is a misconfiguration. So if I'd like to spot the thread vectors here, first of all, it would be a vulnerable OS on container engines that someone can hook into. That's like the most common threads. Vulnerable application, this is like the same as legacy world. Exposed container engine, we are not protecting your circuit on the container. And secure image registry, when someone can push an image or alter or temper an image and do some malicious activities. And privileged containers that can access to the host, plus misconfigured container. And also host escalation, plus finally having this unsubmitted network between the different container when I can hook from container A to B, and extract, for example, one database password through the secret or something similar, and be able to execute some lateral movement. So this is like the top seven or eight container thread vector. So I'm not listing everything here, but I'm giving some examples of the most popular ones. So the next step will be to define the container thread categorization of these threads. So you can see here that we are trying to put this together, for example, for this boot thing, someone who is accessing on the source repository, or someone who will be accessing on the container registry and trying to temper a container image. Also, for example, for the reputation, someone who is disabling the logs or modifying the log data for the naive service that can be on different layers, network, or storage, or so on. So the idea here that we start categorizing the threads that are in your context, and the next step will be to be able to do a mitigation or assessment first, and then mitigation for those threads. So this is something that we talk about later in the adversary emulation. Let's move now to the Kubernetes thread modeling. So similar to the container, we have a different layer of abstraction that's coming with Kubernetes by default. First of all, we have the cluster, the node, and the namespace, and the hub depot. So this is like a kind of different protection that it comes by default with Kubernetes, but are not sufficient. So let's see how we can identify that surface of Kubernetes. So here I'm putting the different components that are part of Kubernetes, worker nodes, master work, control pane, the registry. I'm taking this example from the CNCF financial user group that I've been doing an exercise about Kubernetes thread modeling a few years ago. So it's so talkative. So here's the idea that we start identifying the different boundaries. First of all, we have the machine segregation. We can see that we have three big compartments, the control pane, the worker host, and the image registry. Then we start defining the different boundaries. Here you can see, for example, for the control pane, we are defining one boundary for each component, API server, scheduler, and controller. And we are also defining another boundary for the API server and the ETCD server, because they are working together. Similar exercise for the worker node, when everything around kubelet and container registration could be defined as a trusted boundary. Same for kubuproxy, which is modifying the AP tables to make communication. And finally, the pods. On the other side, we can define another trusted boundary for the image repository when this is talking together, like getting the image, and so on. So let's say we have this different trust boundary. The next step in the exercise will be defining the data flow, how the data flow is going from one component to another. So let's assume that we would like to deploy one application, a sample application. So the user will be applying a deployment. So what will happen, they either kind of apply or mutate deployment, depending if the deployment exists or not. This is go to the controller. We send some data, and we get some data. And then we have the scheduler. If the deployment doesn't exist in the cluster, the scheduler will try to schedule the deployment. And he'll be talking to the kubelet, telling them, please pull me this pod. The kubelet will be talking to the container D, trying to double check if the image existing in the container, in the cache. If it's not the case, it will be pulled from the image repository. So we have this communication. And then what will happen, it will send back the image to the container D to have the run C running the container. And finally, we'll be defining the service end points. So we'll be pulling the service end point information. And the key proxy will be defining the API communication to be able to redirect every request to this specific pod. So you can see this is like one simple example that is like, you can see it's a little bit complex. So from that, you can start spotting and identifying the different threads. So for the purpose of the presentation, I just tried to summarize everything here, like removing a lot of blocks. That's just some common threads or attack victor that are for the kubelet. First of all, you have this access to the API server or ETCD. They are not protected by default in kubelet outside of the managed service, of course. So the idea that, hey, the first thread here that someone can hook in my API server, can hook on my ETCD, make some configuration, deploy some new workloads. The second thread, if you are deploying a dashboard, dashboard can be misconfigured. It can be an entry point for altering some stuff on the cluster. And we have also the same as the container. We have an access to the registry. And we can do some activity on that. So it's a malicious container that's coming from the registry. We also have the same, which is an application that with vulnerability, such as log for G when someone can use this vulnerability to do a kind of remote code execution. So it's still valid in case of Kubernetes. And then we have the gain access to the secret when someone can just get the secret. For example, connection to an external system or a database, because we are not defining the secret inside Kubernetes. And finally, we have the Docker daemon misconfiguration when someone can hook into the Docker daemon from Kubernetes. So let's move now to the cloud thread modeling. Using the same methodology, which is tried, you can see by default that we have these three layers, which is the cloud account, the organization, and the protection. Here I'm talking in the case of Google. I'm taking an example of Google Cloud Storage. And we try to define the different thread model that is coming with the service. So on the next slide here, what I'm doing, I'm putting Google Cloud Storage. But I'm putting also all the next services that are working with. So you can see that we need to define all this communication. Cannot take just the service, but all the communication to be able to see the big picture. So we see the big picture, and we try to slice and dice and define each thread. So I'm taking just one example here, which is an admin user who will be applying to access to one packet. So the first thing, either he will go to the Google Cloud Console or maybe going to the cloud API, and then we check the organization policy. And depending on that, we give him access to the cloud storage service. And finally, access to the bucket. And of course, if I'm enabling logging and monitoring, I would get one entry in my logs and one alert going to the event if there is an alert defining. So this is like a simple example. How it's focused for just one access. But here, I'm putting another example, which is putting everything together, like the different actors and the different communication. You see that it's become very, very complex. That's why it's usually an iterative exercise when you start from one scenario, one thread, and then adding another thread and try to mitigate. So here, first of all, what I'll be doing, I'll be doing the different assets that I would like to protect. So I have a different user that's accessing my storage. They have tokens. So I would like to protect those tokens. I also have the content of the bucket. This is an asset that is valuable for me. And of course, I have the log data that may be valuable as well if it contains some high-sensitive information. So this is the three assets that I would like to protect. And here, I will be starting to find a different malicious user that can appear. So first of all, we can have an internal attacker or an internal malicious user that you want to get some of the issue for him or for any other reason. So this is like one thread or like one thread after that I have to spot. Also, compromise it on the user who someone just access to his laptop or his workstation. Compromise it external user that's coming through external integration, external attack that gain access over internet and do some misconfiguration. Yeah, Google Cloud infrastructure agencies. It can happen. So I have to spot that as well. And after defining all the actors, I will try to see if there is any thread for each actor. So here, I'm taking the example of someone trying to access a bucket through one of these, either he's an admin user, he's a storage user, or he's like coming from another DCP project. So here, you can see that the potential thread is chef of credential or access token that can be used for malicious activity. And I'm defining three actors. He's defining the internal actor, the malicious user, internal malicious user, and the external attacker over internet. So this is like the three types. And then I'm trying to see how he can get to the asset. So here, I can see that there's a different path. And once this happened, back that if he's like a normal user, he can get access to read write to the asset and get some data. And if he's an admin user, he can alter or modify the security sitting for the bucket. So this is the impact. And here, I'm doing my category. So I'm telling that this is coming in this specific category. So the next step will be trying to mitigate these. So here, I'm putting a kind of example just for the case of the demo. But yeah, you can define one or multiple mitigation for that. So let's go to the next step. So the first step is thread modeling here. I'm defining my system. I'm spotting my threats. And I'm trying to define all the threats and define mitigation. But this is a very time-wasting and very penny exercise. So the idea here that we need some tools or some adversary methodology to be able to run this in iterative ways. So the most common framework for that is Mitre attack. It's a framework that defines common language plus different adversary behavior to define the security poster of different layer of IT infrastructure, including cloud provider, SaaS, and so on. And it's coming from the Mitre organization, which is a non-profit organization. So here we define the Mitre matrix, which is defining different tactics. You can see that the tactics goes from left to right. This is just from the initial access until gaining access into the system. So then we're defining the different techniques. So each tactics come with different techniques. So you can see that I have different techniques to have an initial access to environment. And each technique will be defining one or more sub-techniques. And within the sub-techniques, we get the procedure. This is the example how you can do it, depending on the different thread after defining the real ones. Then the mitigation. How can I mitigate this thread? And finally, defining the detection. So I would like to detect, if this has happened for me, what should I do in order to be able to detect this kind of thread? So this is already useful to start doing adversary mitigation. We have this for container. So we can see that on this view, we have all the different techniques, tactics, techniques, and procedure for container. And similarly, we have one made by Microsoft for Kubernetes. So it's concentrated around Kubernetes. You have the different tactics, techniques, and procedure. We have also another one for cloud providers. So we can get this for the top three cloud provider, AWS, Google, and Azure. And you can see the same way you have the different procedure depending on each cloud provider. How would the cloud attack emulation work for work? First of all, I have to choose one by three attack techniques. So I have to choose to test one by one, like the atomic elementary. And secondly, and then I would take the test one technique. Then I will execute the procedure, get the result from the procedure, analyze the result, see if I have thread or read thread or not. And from there, I will implement mitigation and go to the next step. And you can see it's an iterative process that's go over and over and over. It never stopped because behind the senior developer, we develop new servers, change existing services, and changing the tech surface and the stuff behind. So we need to have this idea in mind set that this is an iterative workflow the same way you are doing continuous delivery or continuous deployment. Yeah, the last part of the presentation, I'll be talking about different open source tooling that will help you doing thread modeling and adversary omidation. The first one is atomic red team from Red Canary. It's open source. They offer coverage for cloud infrastructure, AWS, Azure, and GCP, beside the Kubernetes and containers. And they have a library of tests mapped to the Mitre attack framework that I showed previously. So I'm putting here one example of a procedure. Here you can see that we are trying here to create a key, a new access key in IEWS IAM. Secondly, I'm trying to save this key to a file called AWSSecret.credential.credits. And then I'll be trying to extract the AWSSecret. So here you can see that we start thinking about automation so we can do it in an iterative way. And each time I have a new application or I have a new environment, I can apply the same paradigm. A second example that I find really interesting for someone who just started doing thread modeling. This is from a company called Redquart. And what is good, their example, they are quite simple. So they give you a very simple example. Like here you can see that we have a Kubernetes manifest that you can deploy and you can mimic the attack. So this is something really interesting for someone who will be starting learning adversary immigration for Kubernetes. Caldera is a complementary tool for automated teams. So they're offering this kind of automation around adversary immigration. So they have a building behavior, map it to attack imagery. So you can choose one of the scenario or multiple scenario. And you can't run this scenario in an automated way, gathering the logs and spot what is missing for your system. So this is really interesting when you wanted to start automating the adversary omidation. You have attack workbench. It's a kind of workbench when you start documenting, exploring, creating your own knowledge base around what's happening in your environment. So it's an overextension for the military attack. So you can just building your own something that is oriented and customized for the real purpose of your environment and your enterprise or your company. We have also the Maitre detect. This is not an official tool from Maitre. But they give an interesting idea about spotting the different, let's say, gaps in detection and coverage. So let me give you an example. They can tell you, for example, if you wanted to do detection around Kubernetes, someone who alter something, a cluster load, create a cluster load inside Kubernetes or something similar. And you don't have Kubernetes load activated. They can spot you and tell you, hey, in order to be covering this part of your system, you need to have Kubernetes load activated. So it's ingesting and defining, prioritizing which kind of logs and ingesting you need to have outside of seams, including seamstress and other tools. AWS Thread Composer, quite interesting. So you define your application flow. You define your application metadata and assumption. You can even upload one diagram for the application. And then this will help AWS to list the threads and provide you the mitigation flow. By the end, you will get something like this, which is defining the different thread that you have on your system. If they are high, if they are medium, if they are low. And then you have the different category related to the stride framework. So here you can see the different categories. So it's really interesting because it offers a high level definition of thread that is in your application. Stratosthread team, quite interesting. They offer coverage for AWS, GCP, Azure, and Kubernetes. And here, the idea that you have a list of procedures of attack scenarios that are ready to use. So all that you have to do is just select one of these attacks, run again infrastructure, and by the end you get the list of the results depending on the configuration of your infrastructure or the configuration of your environment. And what is good, as I mentioned, they offer like 43 major cloud providers plus Kubernetes. I'm listing here also a couple of offensive tool kits regarding to the major three cloud provider. We have two tools from Reno Security. They are quite interesting. The first one is called Paco, which is an exploitation framework for AWS. And this is coming with another tool or another application that you can use for learning, which is called Cloud Goat. And this is a learnable by design application based on AWS. So this is the kind of the tool that you can use to start learning about adversary emulation. For Microsoft, we have two tools that you can use using, Microburst and PowerZeeve. And for Google, you have the Google Cloud Platform security control mapping to Mitre attack. So this is the most popular, I would say, tools or toolkits that you can use to start learning about it. So what we can take back from this talk, first, security need to be automated, especially in cloud area, because you have to follow up your DevOps team, your DevOps team. So you start thinking about doing the same way as infrastructure as a course, having policy as a code, and having a policy-driven security. Another thing that you can use, the cloud-native monitoring observability tool or logging tools to get all the ingestion and start building some detection around that. And just keep in mind that you need to be really agile when you come to the policy, because it changes from one environment to another from one data to another in cloud. And finally, as I mentioned earlier in this talk, I think in graphs, not lists. I put a couple of further reading here. That's quite interesting that you can take your time and read when you are back home. I think that's all from you today. Thank you very much. Don't forget to rate the session. You have the QR code, and any question is welcome. Thank you. Go ahead, please. So thank you for presentation. Very interesting. So it seems like dealing with cloud-native application security is very challenging. And so I'm wondering if there is an enterprise-lave application to deal with this. You mean for enterprise, right? Yes, enterprise-lave. OK. Gartner defined recently what we call it CNAAP, cloud-native application posture management, that define for blocks. These main four blocks are CWPP, which stands for Cloud Workload Protection Platform. So everything around the protecting workloads, such as containers and hostages. We have the CSPM, the second capability in CNAAP, which is Cloud Security Poster Management, everything around cloud configuration and inventory. And the third building block is CIM, or CIM, which is standing for Cloud Entitlement Management, Infrastructure Entitlement Management. And this is everything around AAM access. So you need to make sure that the right person or the right service have the right access to the right service or the site asset at the right time. So if someone coming just to do some debugging production, you give him one token that takes two or three hours. And the final block, which is cloud detection and reference, everything that is trying to spot any attack real time based on system activities plus ingesting load from cloud provider. So there is a bunch of vendors, but yeah. But if you wanted to do it with open source tools, you can do it. But you need to do a lot of integration. But yeah, for each piece you have an open source tool. But yeah, you have to do a lot of integration. So now that I have done thread modeling, I have enumerated my threads. How do I go about ranking threads in a risk-based way and communicate the priorities? Very nice question. So yeah, first of all, you need to do context-based. And let's take an example of vulnerability management. Let's say that you have a container that is running and you have 300 vulnerable. First step, you say how from this 300, which one are high-end critical? So let's say from 300, you get 100, they are high-end critical. The second step is saying which one are really running in production. So there is some techniques to detect this. So you have, let's say, from 100, you get 80 running in production. The third one, you say which one they have exploit? Public exploit on the internet. Because if there is a public exploit, anyone can get the public exploit and try to run the vulnerability. And fourth is having fix. So let's say that from 80, 40 they have public exploit and 30 they have a fix. So for your developer team or DevOps team or infrastructure team, there is no excuse to go and fix it immediately. Because you know that this library or this dependency they have a fix. So this is like the kind of prioritization for, okay, the kind of presentation for vulnerability management on the cloud side. You need to think on the other side, for example, a bucket that is public, encrypted, private, have access to internet and stuff like this. So it's a little bit different from the cloud configuration. Thank you very much. Thank you all. You can join me on Cystic Booth later. If you have any question, if you want to see a demo or stuff like this, I'll be here today, tomorrow, and on Thursday on Cystic Booth, yeah, please come and have a great discussion. Thank you very much.