Cloud Native Computing Foundation Cloud Native Security Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Kubernetes Risk Assessment: Time to go one level deeper - Ariel Shuper, Cisco

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Lightning Talk: Kubernetes Risk Assessment: Time to go one level deeper - Ariel Shuper, Cisco

At present, the common Kubernetes risk assessment framework is based on the popular CIS benchmarks for Kubernetes. This framework consists of a comprehensive set of tests covering all the Kubernetes elements' configuration. But the framework doesn't go deeper than the security configurations of the various elements. Real attacks can start by multiple elements expanding beyond security misconfigurations. Moreover, in the popular managed Kubernetes services (e.g., EKS, AKS or GKE), running these tests can be challenging. Hence, there's a need for an additional risk-assessment framework that can go deeper than the Kubernetes configurations, verifying that all other attack methods, steps, and stages are covered. This talk will show a new industry-driven framework led by MITRE crafting an ATT&CK matrix for containers/Kubernetes, which consist of tactics and techniques used in real attacks

A

Hello and welcome to the cloud native security day. Actually it's probably the last session. So it's about me to go.

A

um My name is ariel shuper and I'm trying to convince you about kubernetes risk assessment and one the reason why there is a need to go one level deeper than what we have today or what is uh commonly used today. So thank you for joining my session.

A

uh Who am I and why am I trying to convince you to do that? So my name is ariel. uh I'm a principal product manager at cisco, I joined cisco following the acquisition of support shift where I led the product, uh the product strategy, the product design uh in the product. You know development. I was the product manager, the vp product management, the product manager uh in port shift.

A

uh Porsche was focusing on kubernetes and easter security uh period to port shifter was head of serverless security at the aqua security uh before that a checkpoint and working in cloud security uh for many years, uh open source contribution with qb, which is the open source tool we create. We develop and maintain in port shift, focusing on a unique way of scanning.

A

uh Runtime environments participate in istio security, working groups and few others, so why do we need risk assessment? What worries us- and I think you know it's not secret- definitely not today- that kubernetes contain multiple elements. A lot of elements on the mastered.

A

A lot of elements on the worker know a lot of elements around the container, and you know the pod themselves and each one of those elements adds some security complexity, more elements, more, more complexity, more items to break now when we early days attacks, you know 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 a text which just stemmed from simple misconfiguration in tesla or white torches.

A

No one thought they need to configure, uh or at least to create some login or credentials which required authentication for people trying to access the log, the dashboard, because they thought ubuntu's dashboard is inside the cluster. So what can what? What? What can happen from that right and a lot of those simple attacks came from just you know, simple misconfiguration, no one!

A

You know configure it properly uh and for this purpose- and I think you know one of the main reasons why uh we added it- was to create some risk assessment frameworks, something that allows you to address the ecosystem. To make sure you configure everything correctly, you did everything properly and you're, not left exposed by yourself.

A

Now, if you ask yourself what is like the common one, so the common and probably the to standard today is the cis benchmark. So the center of internet 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 cortisol elements. There is a hundred and plus last time I checked uh master node security configuration every component from the api server that you need. The controller manager.

A

The scheduler are looking into authentication authorization, put security profiles, network policies, everything which can govern and control uh your kubernetes cluster and 30 plus checks. You know on the worker, node checking for different configuration different. You know: security, configuration of the of the cubelet of the file system, of the access to the host, etc, etc.

A

Now all this is really great, and I think it's very you know important part, but one of the challenges that you know we see when we look at uh how we secure kubernetes is there 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 know if you have a chance to see it, things can happen.

A

Even if you configure your, you know cluster perfectly fine, but because you just use the tool which is unsecure uh in the example which is quoted by a nice research from in teaser, it's about with scope.

A

It's because someone crafted like a vulnerable image and planted, or someone created like a campaign or an attack or is really targeting your environment, even if everything is really configured properly. Even those ports which are needed or those images which you use uh can be uh and reason for that, even if the entire cluster is configured uh properly.

A

So this leads me to at least trying to think that we need something else. We need a framework that addresses the entire spectrum of kubernetes. First, not just based configuration we're the 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 of farm other reasons, someone did manage to access, so we want to detect it. We want to stop it.

A

We want to minimize and contain this entrance. So it's just just like the misconfiguration. We need to make sure that the entire uh 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, 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.

A

There is a problem, but how do I fix it? Maybe there's an alternative, so I mean this one will remain as this, but I can find an alternative that can mitigate um this risk. So if I would try to create a comprehensive tool that would I would do um I didn't create it. I found it, and this is beautiful work uh which was down by the mitral attack uh and I'm proud to be a contributor for that, as well and in the mitral tech.

A

What they did is they took the entire attack kill chain 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 privileged escalation, and all the steps that attacker will do in order uh to get his hands on the data or in order to abuse the resources on the cluster, whatever it doesn't matter. But we need to make sure that we don't just you know, stop at the gate.

A

We keep following it and checking afterwards and for each of it they interpreted it. They took like the relevant things for containers, so, for example, if we examine the privilege escalation, which is you know how you can escape to the host, there are the techniques which attackers were used in order uh 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.

A

So it is important, those type of first, because not 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 there I'm exposed in this escalation, I would perhaps can address it by placing using pod security profiles and making sure that you cannot uh run as a route or making sure that you cannot read uh anything to the host file system.

A

You can't use those network and there is many other capabilities which I can use if I want uh to trade like error. So the idea here, which I think makes the mitra attack uh as a good candidate for risk assessment in kubernetes environment, is the idea that we can look at the entire spectrum.

A

Okay, entire spectrum of potential attacks, so not just misconfiguration, but also any you know any option uh to penetrate your cluster. It also doesn't stop okay, it doesn't stop on. uh It doesn't stop on the items that are just you know, just uh the entrance. It goes entire uh life cycle of the attack. Every different stage has its own uh techniques and for every single you know step. There is something else that you can do, and there is a list of it.

A

So for you, as a user there, 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. You know from real attacks incidents, not theoretical ones. So this is just an example of why you know we need something which is slightly lever deeper and goes deeper than cs benchmark, something that you know give me tools to allow me to mitigate and cover uh the entire spectrum.

A

So everything is available on the mitra attack on the mitre org framework. There is an attack metrics, which will be published soon, and thank you very much for joining my session today.