 Hello, and welcome to the Cloud Native Security Day. Actually, it's probably the last session, so it's about to go. My name is Ariel Schupper, and I'm trying to convince you about Kubernetes risk assessment, and why there is a need to go one level deeper than what we have today or what is commonly used today. So thank you for joining my session. Who am I, and why am I trying to convince you to do that? So my name is Ariel. I'm a principal product manager at Cisco. I joined Cisco following the acquisition at Portshift, where I led the product strategy, the product design, and the product development. I was the VP Product Manager in Portshift. Portshift was focusing on Kubernetes and Istio security. Period to Portshift, I was head of serverless security at Aqua Security before the checkpoint. And working in cloud security for many years, open source contribution with QB, which is the open source tool we develop and maintain in Portshift, focusing on a unique way of scanning runtime environments, participate in Istio security working groups, and a few others. So why do we need risk assessment towards us? And I think it's not secret, definitely not today, that Kubernetes contained multiple elements, a lot of elements on the master node, a lot of elements on the worker node, a lot of elements around the container and the pod themselves, and each one of those elements had some security complexity, more elements, more complexity, more items to break. Now, when we, early days attacks were the first, let the Tesla famous attack or the Weight Watchers, or around 2018, where the world was early in the usage of Kubernetes, there was a lot of attacks which just stemmed from simple misconfiguration. In Tesla, weight watchers, no one thought they need to configure or at least need to create some login or credentials which required authentication for people trying to access the log dashboard, because they thought Kubernetes dashboard is inside the cluster. So what can happen from that, right? And a lot of those simple attacks came from just simple misconfiguration, no one can configure it properly. And for this purpose, and I think one of the main reasons why we added it was to create some risk assessment frameworks, something that allow you to address the ecosystem, to make sure you configure everything correctly, you did everything properly, and you're not left exposed by yourself. Now, if you ask yourself what is the common one, so the common and probably the defect to standard today is the CAS benchmark. So the center of feature and security, create benchmarks for a lot of environments and Kubernetes, one of them, there's a comprehensive set of security checks addressing all the configuration of Kubernetes elements. There is a hundred and plus, last time I checked, master nodes, security configuration, every component from the API server, this is the controller manager, the scheduler, looking into authentication authorization, put security profiles, network policies, everything which can govern and control your Kubernetes cluster and study plus checks on the worker node, checking for different configuration, different security configuration of the Kubelet, of the file system, of the access to the host, et cetera, et cetera. Now, all of this is really great and I think it's very important part, but one of the challenges that we see when we look at how we secure Kubernetes it's true that misconfiguration are fundamental risks in Kubernetes environment, but misconfigurations are not alone. There are more elements which can impact you, there are more attack vectors, there are more penetration options. If we analyze the recent attacks like the one shown on my screen, I don't know if you have a chance to see it, things can happen even if you configure your cluster perfectly fine, but because you just use the tool which is unsecure in the example which is quoted by a nice research from Intesir, it's about with scope. It's because someone crafted like a vulnerable image and planted or someone created like a campaign or an attack or is very targeting your environment even if everything is really configured properly, even those ports which are needed or those images which you use, can be and reason for that even if the entire cluster is configured properly. So this lead me to place trying to think that we need something else. We need a framework that addresses the entire spectrum of Kubernetes fruits, not just misconfiguration. We need a framework that addresses also the various stages of the cyber attack. So meaning if misconfiguration or security configuration are there in order to avoid someone from entering the cluster, we need also to have tools that detect if by chance or not by chance or from other reasons someone did manage to access or we want to detect it. We want to stop it. We want to minimize and contain these entrants. So it's just like the misconfiguration, we need to make sure that the entire life cycle of an attack can be covered. And I think what is really important and might be missing is when something is not configured properly and I know that I need to configure it but maybe I don't, I can't. Maybe this is something that I must change or I cannot change. I must leave it as is. What is the impact? What's, okay, so I have a challenge. I have a problem. I need to, there is a problem but how do I fix it? Maybe there's an alternative. So maybe this one will remain as is but I can find an alternative that can mitigate this risk. So if I would try to create a comprehensive tool, that would I would do. I didn't create it. I found it and this is beautiful work which was done by the Mitra attack. And I'm proud to be a contributor for that as well. And in the Mitra attack, they took the entire attack kilting or the entire life cycle of an attack from the initial access to the exploitation execution, to the different stages whether it's creating persistency or privilege escalation and all the steps that attacker would do in order to get his hands on the data or in order to abuse the resources in the cluster doesn't matter. But we need to make sure that we don't just stop at the gate. We keep following it and checking afterwards. And for each of it, they interpreted, they took like the relevant things for containers. So for example, if we examine the privilege escalation which is how you can escape to the host, there are the techniques which attackers were used in order to gain access or in order to break out from the container. And if you break out how you can elevate your privileges and reach the host or take control of the system. So it is important those type of first because that just explaining what was done and how you can do it, but also to explain or for you in order what you can do in order to mitigate it. So if I know that I'm exposed in this project escalation I would perhaps can address it by placing using pod security profiles and making sure that you cannot run as a route or making sure that you cannot read anything to the host file system. You can't use those networks. And there's many other capabilities which I can use if I want to break that error. So the idea here, which I think makes the Mitra attack as a good candidate for risk assessment in Kubernetes environment is the idea that we can look at the entire spectrum. Okay, entire spectrum of potential attacks so not just misconfiguration but also any option to penetrate your cluster. It also doesn't stop, okay. It doesn't stop on the items that are just the entrance. It goes entire lifecycle of the attack. Every different stage has its own techniques and for every single step there is something else that you can do and there is a list of it. So for you as a user, you get understanding of what's the impact of this project. And then you can see if you have an alternative plan you have like a backup plan. And what I really find interesting about it that it's based on information collected from real attacks, incidents, not theoretical ones. So this is just an example of why we need something which is slightly lever deeper and goes deeper than CIS benchmark. Something that give me tools to allow me to mitigate and cover the entire spectrum. So everything is available on the Mitra attack on the Mitra org framework. The reason attack metrics, which will be published soon. And thank you very much for joining my session today.