 Welcome to Cloud Native Live. Thanks for joining us today. Here we dive into the code behind Cloud Native. I'm your host today. My name is Whitney Lee. I'm a developer advocate at VMware Tanzu by Broadcom. Every week, we bring new presenters to showcase how to work with Cloud Native technologies. So we'll build things, we'll break things, and we'll answer your questions. So today, we have Rafiq Haravi with us to talk about how to use Cloud Native application threat modeling and adversary emulation. So I'm super psyched for that. But I got to go through this code of conduct thing. This is an official live stream of the CNCF, and as such, it's subject to the CNCF code of conduct. So that basically means be nice to each other. Don't add anything to the chat, that would be in violation of the code of conduct. Be nice to your fellow chatmates, be nice to me, be nice to Rafiq, and we'll return the favor. It's gonna be great. Friends who are joining us live, please do say hi in the chat and tell us where you're tuning in from. I love that this is a global stream. And if you have any questions during the presentation, go ahead and post them to chat. We're gonna try to make this more conversational and we'll interrupt and dig into your questions as we move through the presentation today. So with that, I'm gonna hand it over to Rafiq to kick off today's presentation. Hello, Rafiq. Hello, Whitney. Thank you very much for the presentation. So my name is Arfiq Karabi. I've been in the IT world for almost 15 years right now, and I've been spending my last three years and a half with CISD, working mainly with customer in Europe and Middle East, helping them to securely move to cloud, mainly containers, Kubernetes and cloud services. Before that, I've been working in consulting mainly with the concentrated company like Deloitte and Entity Data, moving on-prem or close to cloud. And for those who don't know, CISD is a cloud-native security and observability company. We are offering a cloud-native application protection platform. And also we are the company behind Falco, which is the CNCF project for trade detection and response for containers, Kubernetes and cloud. You can get here my LinkedIn profile, my Twitter profile as well. Please feel free to reach me and contact me. With that said, let me move to the agenda today. So we have a pocket agenda for today. We'll start talking around the cloud-native application building blocks, all the different components that are part of the cloud-native application. Then we go through the multitude of cloud attack surface and the different challenges that come with it. We follow that by trade modeling techniques for the purpose of cloud-native application, then going with the adversary emulation. And finally, we'll be finishing by tooling. I will be only mentioning open source tooling, nothing property, no worries about that, and some takeaways as well. So with that said, I'll be just making a small introduction here on certain time, maybe not like so far, we've been deploying and delivering application like for virtual machines or maybe physical machines. And it was a little bit much or less easier to protect them. You can't put a kind of firewall or endpoint detection and response system in the front, kind of someone here on the bridge, and you'll be supporting those intrusion coming to your system or your environment. So it was kind of strange for what projection system, but this is no longer the case when you come to cloud. For the simple reason that cloud provider are public, they own external connection, and they are exposed to outside world, and they are bid with different services that you can't consume on the shelf. So you need to control access to services, give access both to those services and to the users or the team that are using the services, and you need to give the right access to the right team, to the right service at the right moment. So this has generated as well a lot of logs. So detecting a new activity become more and more hard. So let's see how this is in cloud native application. So usually you have your workload that is favorably working as containers. Maybe if you are more advanced in your cloud native journey with GoPort services, or just like moving workloads from on-prem to cloud, as is like just bringing one VM, put it as an instance on top of Google, AWS, Azure. So this is the workload. And on the most of the cases, this is running on top of Kubernetes, whatever is managed by a cloud provider, or you are building by yourself on-prem or on top of cloud provider, plus container as a service. So we have this, let's say, the business intelligence or the business value of your application. And here around, we have a set of like other capabilities or other services that are always referred to as satellite services, something like identity and management, network and security, load balancing, for example, management service, like logging and monitoring. This is something that you need to distribute the system for sure, otherwise you are lost. And finally, you get those data. Like the data is valuable for you. So you use different type of data source, like database, object source, web source, and so on. So this is like a typical cloud native application which is running on a cloud infrastructure, or maybe on-prem of Kubernetes. So we see here that we have like four layer of security. We refer to this for 4C. The first one, we start building a code. This is your code that you put it in a container. You have the first layer of abstraction there. And then we deploy the two Kubernetes. So you'll be deploying this in a code. This is the second layer of abstraction in the name space. You make sure that there is an abstraction or like a containerized escape space, sorry. And finally, you have the cloud provider. On the cloud provider, you have military account, you have folders, organization, and so on. So you have this four layer of abstraction. The challenges that come with this, that those cloud native application are really dynamic. What I mean by that today, you have your developer, DevOps teams that they have a list of services offered by those cloud providers. And they can use it on the fly. It's no longer like the old enterprise architecture world when someone defined the architecture and it revisited its six months, one year to make sure it's aligned. Today, the application team or the service team can move from one service to another or change the architecture to align with the business with the business requirement and to be challenged on type for market. So you need to be agile. That means that you need to pick the right service. And this is make the application dynamic by consequence making also the service attack dynamic. The second thing which is quite interesting that those trade actors, those bad actors, they are using the same tool. So if you are using Terraform, for example, or CloudFormation to automate your deployed and accelerate your different, they are using the same tool. If you are using, for example, GPT, chat GPT or other like GPT solution to search for solution, they are using them for searching for manuals and so on. So they are using the same tools and they are like going with the same speed as you if not like much, much, much speed than you. The second thing, when it comes to having one monolithic system that would be distributed, this is a lot of interaction. And by the way, this is a lot by default, the attack service. We have also all these loads that are generated. So like comparing to one to one system or three system, three higher system that we know from the legacy world, this is a big graph. Also, you have lack of visibility because of the system running on different boundaries. And finally, this big issue, let's say on the culture or agility when you have the Cloud delivery team that is trying to promise time to market versus the security team that maybe they are using the same old process method origin and tools. So in a nutshell, this is the main challenges. Before digging into the thread modeling, I would like to mention something here really important was reading an article from John Lambert, which is from Microsoft security research team. And here I'm quoting what he's saying. He's saying defender thing, at least attacker thing in graphs. As long as this is true, attackers means. And this is mean that as a security team or as developed this team or even other dev team today, you are just struggling to make your application either non-vernable or complaint with some regulation. If you are in financial services with PCI, with others and you are just having some check is to check and make sure that I'm not looking at the world picture but I'm just trying to have my check is done and go to production. But the attackers, they are trying to connect the dots from one piece to another and try to find the path from initial access to your system and to gaining a full access and extraction standard. So please keep this in mind that this is something that when you start doing thread modeling and adversity emulation, it's really, really interesting to understand how those guys things. So a couple of definition for those guys that are not coming from security background. We know that there is like this big movement of DevSecOps. So a lot of people coming from them to security and other coming from security to Dev. So let's make sure that we are all in line. Thread modeling is the exercise to be identifying the different building blocks of your system, the communication between them in order to spot any thread and protect something valuable. And this is really interesting. I will give you an example. Today, if you have like an history bucket that is hosting your like images or files that you are using in your public website. It doesn't make sense if it's public or private but because those documents or those images are public, there is no value from there. So it doesn't make sense. We need always to think this is something valuable, confidential, IP or like personal information or stuff like that for the company and then start to protect them. So the goal of thread modeling is to identify the threads, the actors and then start thinking about providing mitigation. On the other side, the adversary emulation will be simulating the tactics, techniques and procedures that is coming from real world thread actors to test an organization's results. So you are putting your choose, you are putting your feet in the choose of an attacker and then you start thinking the same way using the same tactics, techniques and you test your resume. And the idea is that you can and assess your resume plus provide mitigation. I like this a lot. For one thing, I think one of the things I've taken away from your presentation so far is just like the sheer complexity of systems and then how difficult it must be to secure. And I'm very interested to hear your solutions which must be coming up. But then this is the first I've heard of the term adversary emulation and to me, it reminds me of chaos engineering where you break your system on purpose so you can expose the flaws before an actual event happens. So that's the question in the end. Is it the same? Do you think those things are similar? Yeah, I would say it should be chaos engineering for security. I mean, because chaos engineering is concerning everything like scalability of the system higher the availability, resiliency and stuff like this. Let's say that the adversary emulation is the chaos engineering for security. Be prepared to be attacked, to be leaked and see how you provide the different procedures and the different mitigation to avoid that attack will limit it. Awesome, I love it. There is a lot of similarity between the two words because in the two words you are trying to break the system from security point of view for adversary emulation and from resiliency, scalability and so on availability for the chaos engineering. I love it. Thank you. Thank you. So within that, let's go to the trade modeling. There is a lot of methodology or techniques for trade modeling. The most famous one is Stride which is created by Microsoft and defining six categories we'll look after. Later, the second one is the attack tree. The attack tree consists in defining a multi-level diagram which is with one root, different leaves and children and wherever all these children are satisfied the root is satisfied and that means that an attack can be possible. The third one is Dataflow which is defining a graphical presentation of your system with different component interaction of them and then help you make something conceptualize it and try to find some threads. So the pillar for that are system architecture. You need to define your system architecture to make sure that it is reflecting the reward of your current system defining other good actors and bad actors because even good actors if they are compromised they become bad actors defining the list of thread or finding the list of thread and providing indication. So this is like the four pillars of trade modeling. I have a question about methodologies. Is it common for a company to choose one methodology and that's their methodology or are you meant to do all of these things as a way to promote it? I would say it's a mix of the three. There is other methods of course but it's a mix of the three. You cannot just use one because depending on your system for example, attack tree is very famous for example to define like interaction between the system and support like the highly risky assets that the flow let's say help you to define like different entry points. So it should be always a mix of three. I rarely see a company just using one methodology and there is others I'm just not saying those top three I would say. Thank you. So the stride approach. So stride is like categorizing those three in six category at the spoofing, tempering, repudiation and promotion disclosure, deny of service and elevation of privilege. And let's say that we have this example of digital bank example. So what we are doing here we define the different building blocks then we define the different interaction between them. And when we define the different interaction we define also the trusted boundary and the trusted boundary is the kind of those services that they can talk together. So we can say that for example here the payment gateway can talk to the notification service to say someone that he just we just process your payment. So this is kind of like the high level of stride approach and then you start sporting the thread and put it in the category. So the idea here that you have to decompose the system into different component models is defining the relationship between them. This is the first step. And then I would like to spot here the different persona for thread modeling. This is really interesting to engage all the people. The business owner will be always evoked in balancing they doing some balance or like some some studies around the business requirement on one hand and mitigation to address those things. So we need to go fast for example, time too much but we need to make sure that we are not harming our business. So the business owner is owning the risk and validating that we can do it of course with the validation of security. The app or the service developer will be facilitating brainstorming the application architecture and finally he will implement or they will implement the mitigation. On the adversary side we have this adversity that can be someone from the company, someone hired that's considering and stuff like this we will be assimilating another user fly to brexit system and find potential threats the defender will be defining security control to mitigate the threats and you will be working closely with security architect will provide the guidance which is like industry based practices like CES benchmarks or let's say Compliance Framework if you are a regulated company. So for that let's start with the threat modeling for the cloud native. I will do this example for containers, Kubernetes and cloud because this is like the most big company that defined today like a cloud native environment. So for container I'm just putting here the Docker thread and you can see from this diagram you have the front thread some of them coming from like legacy world dose attack compromised secrets and stuff like this and some come with a specific architecture of container like container outbreak and so on. So just keep in mind that this is like a big picture of the different threads. So we use the data flow diagram for containers to see the life cycle of containers and then they spot the different break point of the thread that can come. First of all we have the developer who is developing business code using any programming language but he will also deliver container manifest, Kubernetes manifest and so on. We are focusing on container now pushing this to your source repository and then you have your CI pipeline with the building and pushing the container image to container registry from there the image will be available to be deployed so we will be pulling around the container image this is we go to the container host which is having the kernel from the container engine, the container we talk to the kernel to execute some action the container socket can talk to container engine as well we have the container engine which is talking to the kernel and we have this container which is talking to container. This is something that can be normal if you have a micro service A which is talking to micro service B or can be malicious configuration if we don't have the right solution so it can be malicious or not so if you would like to go here and spot the thread picture I will start I'm just mentioning the most common but the picture is quite big then what I'm spotting here just for your knowledge so the first thing that you have a vulnerable operating system or container engine that is vulnerable with a non vulnerability that can be exploitable the second thing which is coming from the legacy world it's the vulnerable container or application that is vulnerable so you have this application for example that is exposing your forgy you can do or it will cause execution for example exposed container engine without for example TLS, without any protection authentication and so on this is a thread that someone can hook on the container engine and then bootstrap a new container a malicious container, change the configurations we have the unseeker image registry with someone can hook into, tamper and image, create a new type for example or just pushing your vulnerable image that you can pull later in your host or your cluster privileged container that they have access to the kernel and they can we can use it to do lateral movement for malicious activity and misconfigured container as well and finally as I mentioned this escalation on the host so this is like the most common one but the list is wider than what I mentioned here and finally I missed this last one which is a sufficient network oscillation between container container A for example which is a front-end container can access to the database container and maybe get the password the second step will be after you define all these threads, possible thread you just start categorizing those threads in the side methodology for example this pool thing, someone who is like modifying the source code modifying the container manifest for the tampering, someone who is tampering the application code directly in the source code or using the CI CD and so on so I'm making here like some example just to let you know that when you spot all the threads that like make sense in your environment with the technology architecture that you are using then you start categorizing the third step will be mitigation and we will talk later about mitigation in the cloud path so let's move now after seeing how we do thread modeling for container and introduction, let's move for Kubernetes thread modeling and I'm spotting here the different boundaries that come with Kubernetes so we have a container that is included or part of the code this is the first layer of protection in space, we have the node this is like physical separation and finally we have the cluster this is the default security boundaries but we see that this is not enough for Kubernetes so here I would like to spot the Kubernetes attack surface I'm using this example that have been done by the CNCF financial user group two or three years ago which is a good example showing how we do the modeling for Kubernetes you can see that we have the different building blocks here all the components are part of my counter plane all the components they are part of my worker node and finally the components that are part of the image resistance and you can see here we define data flow from one component to another the trusted boundary that we called earlier the machine security negation this is like presenting a process of component and this is presenting the system so let's start with defining the different machine segregation so you can see here maybe most of you are familiar with that we have the control plane, we have the worker node and we have the image registry and here I start like doing the trust boundary the API server can talk to the TCD the controller has its own trust boundary and the scheduler as well on the other yes is the trust boundary the same as a threat boundary a little question let me think a little bit about when you define trust boundary I mean that you are supposed those components are supposed to talk to each other so it's not the same it's not the same trust boundary that you assume that the API server is fine to talk to the TCD so it's but if something go from outside here this is breaking the trust boundary so if you would like for example to the API server to work to the scheduler on the contrary you need to define this but you are not controlling what is happening into the trust boundary because you are you still gathering like logs and like evidence and stuff like this but at least from architecture point of view API server talking to the TCD that's normal and for example image repository getting an image that's normal so yeah but if something break into that will be that will be a threat got it thank you thank you so I just say for the worker node everything around QBlade and situating the container container D, image class and RAC will be a trust boundary the QBlade will be talking to all these components similar for QProxy who is responsible for modifying the API table this is another trust boundary and finally we have the code and we finish the image registry when the image repository will get the image data the next step will be to define the data flow here so let's assume that we have we would like to deploy something we would like to deploy sample applications so the user here we just apply deploy it will come to the API server and here we will check if this is a new application deployed with the mutation of an existing client so we do a couple of check with the controller to define the data set and so on like the number of replicas and so on and finally if the application never been deployed we schedule the application using the schedule and when this is done what will happen the QBlade will pull the new code if we try to see to hit the dot program oh yeah and then it will try to see if the image is available in the cache if the image is available in the cache no need to bring it from the image repository in the other case what we do we get the image the image will be loaded and send it back to the container which will be sending to run C++ so we finish this instantiation and the second part will be defining the endpoint and configure the API type to export the application so if you can see here that this is quite complex there is a lot of interaction and each interaction and each endpoint can be a potential asset so you need to assist all of them for the purpose of the presentation I just make it like more simple more condescated here I'm just voting the most common one so you can see here the first thing that we are seeing is access to Kubernetes API server or an ETCD server most of this happened because people forgot to secure their endpoint and this is like very very common today if you use any like discovery service you find an internet that there is a lot of KPI, Kubernetes API server and ETCD API and ETCD servers are exposed through the API the second thing if you are deploying Kubernetes with the dashboard maybe in this configuration the dashboard can be used by a malicious user to go into the platform and be deployed and it's much simpler than looking at the system or a host next one which is malicious container image in the registry that be deployed to the cluster and then expose to the cluster the window application that with exploitable vulnerability also if you are not well defining your secret or you just mounting your secret in your code someone who access the code can get the secret and then do extra lateral movement and finally a document that is misconfigurated low the attacker to gain access to the host and do a lot of work. So this is like the top common Kubernetes misconfiguration that the threat actors will use and you can see that we start spotting the different the different witness point and we need to provide mitigation so let's move to the cloud trade modeling here I'll be just showing an example using Google cloud storage you can see here that we have different layers that come by default cloud platform you will have your account and you have your organization different folder and stuff like this. This is like a first layer of abstraction inside the project you will have the Google cloud storage instance yeah this is an example I take it from the NCS group they have been doing research around this and this is quite it's a quite explainable that's why I put it here. So here I'm doing I'm putting the cloud storage and then I'm defining the different boundaries you can see that we are defining the different boundaries the different services that are working with cloud storage and also we are defining the different actors here you can have admins or user any GCP and other GCP project access to this specific storage, extender user and other GCP services as well so what I'll be doing here I'll be defining one interaction here someone an admin user who wanted to access the backup so how it's working he will be accessing either through the cloud console or cloud API then he will get to the organization policy doing some very well-organization policy we define whatever owner he has access we got this policy with cloud storage and if he has access we get to the backup step number four here and if you are enabling logging and monitoring you will write something to the logging service and monitoring service so this is one just one flow one flow and if we dive to do it for each user and each interaction this will be more complex and if you end up by something like this so just to give you the example the link here I will share the presentation later so you can go into this so the idea here that we start like sporting which is valuable that's really interesting and really important just focus which is valuable for the company so for me it will be in this case all the authentication token that can be compromised or leaked plus the data that are inside the packet and also the log data that can be valuable because we are exposing some sensitive information IP addresses all of that can use it for further action so we have three we spotted three valuable data that we should protect and then the next step of starting defining the different actors it could be an internal attacker or an internal malicious user they are trying to do something that is not allowed or permitted also compromising internal use someone who got leaking on his laptop someone access to his laptop and get those information compromising external user a partner or someone who is working in a new environment also an internal attacker who find a way to access to your environment of an instrument cloud provider infrastructure engineer this is like not it is still a thread and when I'm defining all these threads I will work on one of these so let's say that I would like to see if someone with testing credentials or access token how he can access my environment so here we can see that we are defining this attacker who will be testing the credential we define the different type of attackers like an internal one internal malicious user or external attacker and they are all doing the same the same action and we can define the workflow until we get to the cloud storage either through the console or the API to finally to get to the back storage so the assets we protect here is the bucket and the impact if the user has just the right permission they will just get the data but if they have a permission they can even modify the data and export all that stuff so this is really important and then we start categorizing this we put this as a categorize of spoofing escalation of privilege and finally I'll be giving an example here for example I define all my thread it is a person that start thinking about enabling different actions or providing different methodology to provide to protect like enabling MFA putting strong restrictions VPC access putting like the token that expire in while and they are refreshing often and stuff like this so this is like the third step of thread modeling which is after the technique is there providing allocation so within that let's move to the cloud native adversary and the cloud native adversary as I mentioned earlier it's to put yourself in the shoes of the adversary there is a one known organization called it metering that been providing common language and understanding of adversity behavior and they are getting all this behavior and those all these techniques techniques and procedure from real world cyber attack so the idea is they provide this to the companies government public organization sector that provide you help to define your adversity emulation strategy so the well known the most known framework is metering attack and we stick within this framework during the presentation so how it's how it's defining we define set of tactics you can see that is starting from just having an initial access doing some execution escalation and so on depends invasion until getting the latest step which is ex filtration and apartment organization so this is the first slide and then for each tactic we have different techniques so here we define different techniques and for each techniques we could have one or more sub techniques which is the case here for valid accounts and for each techniques we have the procedure we executed the mitigation a way to mitigate this like for your team and finally a detection I would like to be able to take this how can I enable my logs put some rules and so on to be able to detect such kind of of procedure we have the metering attack provide one matrix that is available for container this is all the the techniques tactics techniques and producer that are for container we just have those techniques that are let's say make sense in the world of container Microsoft has developed the one for Kubernetes that is quite similar we are focusing on Kubernetes and finally we have a matrix which is dedicated to cloud it is covering today the top cloud provider AWS, Google, GCP and Azure plus the services so just keep in mind whatever you start working on adversary omination you have these three matrix that you can start looking into so how is working the workflow for cloud accumulation first of all you have to choose the metering attack technique that you will be using then you choose a test form for this technique you execute the test for the procedure you analyze what you find the detection and finally you do implementation and it's an iterative process so you have to do it for different scenario you have to like to replay whatever the infrastructure change whatever new services coming or stuff like this so make sure that this is an iterative process the same way today that you are doing an iterative like workflow you have to do the security the same way so the last part of the presentation will be focusing on the tools we start with the atomic rate tool which is an opus framework that is providing libraries of test for the different miters attacks the procedures that we saw earlier so and this is covered maybe top three cloud provider plus Kubernetes plus container so it's a very good start and I'm just putting here an example they will provide you an example like this when you are trying to create the key or trying to get the credential and finally trying to extract the key from the credential so this is give you an example if something could happen like this could happen in your infrastructure and we see later how there is some tool that will help you to automate this this attacks so on the Kubernetes for those who are beginner for Kubernetes I found this matrix which is provided by a company called ready work what I like from here that they are just giving a very simple example for each attack for example here for part door container you can see that you're providing a very simple attack with an example so you can play it around your infrastructure and start learning this is really really very simple but really interesting Caldera is an automated adversary emulation tool so you can enable a market to attack techniques you can use the the techniques that are like provided in atomic routine and then you automate this whatever you want to run it on weekly basis on monthly basis you make sure that this is running and you get the result and you can improve your poster attack workbench is a kind of knowledge base but you can use it internally to customize my three attack your organization to create some some additional information annotation and knowledge internally my three detect is not an official my three my three project but it's helped you to spot the different gap in your infrastructure let's say I will give you an example if you would like to be able to detect if someone is creating cluster law or Kubernetes for example you need to activate the Kubernetes so the my three detect will spot you this part and telling you hey in order to be able to detect this level please activate those logs for example and be a threat detection on top of that there is one tool from AWS that I like because it's a high level tool when you give in entry the application with the data you describe just your application you give assumption yes any question we have a question that I think is a wonderful question because so you did a great job of convincing me at least probably everyone watching that it's a very complex world out there and there's a lot of attack surfaces and a lot and it's kind of overwhelming maybe by design and now you're providing okay here are tools and frameworks that work in all these different contexts which is like a relief for me because I'm just like okay good like I'm glad people figured this out and I can follow the matrices but I think now people are wanting to know how to make how to capture all this information to be able to go to these resources later especially the ones that are applicable to them so as as the host I maybe I don't know where I'm let me say I'm just the host I didn't organize this session so I don't know where you it will live within the CNCF space I'll do my best to make sure in the YouTube video replay that we put a link to your presentation there but how do you feel about putting a link to your presentation in your Twitter or say it publicly otherwise I'll be running this on the especially a place where we can get to these links where they're a clickable link and not these long links that we can't okay I see what you mean okay we share the presentation like the slides so they can play with the animation okay will you share the slides to your Twitter handle yeah I'll do it let me write just write this down here when someone's saying maybe share him here in the chat but I think do you have a link to your it's not quite that easy I think yeah I'll make a copy read only copy yeah later when we finish make a read only copy and then I will share it on the chat yeah okay okay great cool yeah awesome so here this AWS thread composer it's a high level tool that we give you put your application metadata you make some assumption and then you will get the threads and the mitigation and this is like an interactive way you get the model document you can even put an architecture diagram and byte it and you will get something like this so if you spot you the different thread that you are exposed to you get the category or the priority of each thread and finally you can see here on the right of the screen that you have the different the thread map it to the slide five more steps different six categories so this is something that maybe you can start playing around it can hit the link here so you will see that it's provided by default here you go to this red model I think that we have one example there we go thread composer and here you can see the example and you can see that you are putting the application info in some of your application the architecture you can even put your your graph defining the data flow if you want to making the assumption and byte and you can see that we are making a lot of assumption here that TRS one two is a great etc do you mean to be sharing your browser screen right now? oh sorry because I was okay it's okay I thought okay I shared the slide so no worries you find the link later okay and then you got the threads here you can see that you got the list of threads that are created and start prioritizing different threads another tool which is Threat to Threat Seam and it comes a set of libraries similar that map to my tree attack and they cover AWS, GCP, Azure and Kubernetes as of today and you have different techniques that you donate you play it like this and then you get the results so this is very straightforward tool that can give you a list that you can see here that we've been able to execute to attacks finally I would like to get you a couple of offensive toolkit that you can learn and reuse it like for the learning purpose package which is an AWS exportation framework that is designed for a person security cloud goat which is an application that is vulnerable by design so you can deploy the Kubernetes cluster deploy any security tool you can start spotting the misconfiguration and learn from for Azure we have Microburst and Pausier which is quite good tools and for Google Cloud I'm putting here the Google Cloud Platform Security Controller mapping we've done we've come to the take away first of all I would like to mention that this is really important to Threat to security to save my utility of the box workflow so it could be automated it could be managed as a code and should be you have this policy driven security in place use the cloud native tools observability and tracing tools are really like they will get you inside in your environment just to understand how these blocks are communicating and spotting this configuration so let's say if you are using an observability tool or a tracing tool you either transport the different objects of your Kubernetes cluster and just start making mapping the communication between them it should be really helpful to spot if you are related with the architect or not last thing the next one is try to translate this policy into consistent effective and action work tasks whatever something happened the security engineer or the self they would have a list of actions to check and then a list of actions to execute to isolate the workload and finally the most important thing at least to make sure that they are just trying to connect the load and find a way to enter the environment where some other just trying to make sure that they are compliant I put the list of some further things that are quite interesting here if you can share it with me with the audience and I will make sure to share the slide later with my Twitter I am putting the links in the chat now but I think based on my side of the interface it might only be going to the YouTube stream and not the okay anyway tonight I will be sharing tonight the slides everyone who has my Twitter account it may go back just to spot my Twitter account it is on your handle we can see it underscore Refic Aids underscore just stay ProfiKarabi on Twitter we find yes excellent this has been so valuable thank you so much for your time today thank you very much for your presence any question I am happy to answer I I have been asking the questions as we go so we don't have any right now but we can give it a minute so to be clear what is going to happen you are going to give me a link to your presentation and I will see about getting it into the description on the YouTube video meanwhile you are also going to post that link to your own personal Twitter so people can find it there too okay cool alright I think no questions have come in so I am going to go ahead and say the ending script thank you thank you thanks everyone who shared their attention valuable time and attention with us thanks for Feek for teaching us about cloud native application threat modeling which is vast but there are wonderful tools I really loved the idea of adversary emulation and to me and you agreed it is like chaos engineering but for security where you try to think like an attacker and all the great frameworks and tools that are out there to do that so thank you so here at cloud native live we bring you the latest in cloud native we dive into the code every Wednesday at noon US eastern so at the same time thanks again for joining us today and we will see you again soon thank you goodbye