 Hello, everyone, and thank you for joining this webinar. I'm Iska, I'm a software developer at R-Mode, and recently I've been working on a really interesting concept that I'd like to tell you about today called Attack Chains. I'll start with an overview of what an Attack Chain is and how we define them in R-Mode. Then we'll see a demo with real live Attack Chains. We'll talk about how we can break an Attack Chain and what added value we can get from this concept. An Attack Chain is a series of misconfigurations or vulnerabilities that a malicious actor can exploit to access and manipulate your environment. Now this is often referred to in the industry as Attack Paths, and I'll be using the terms Attack Chains and Attack Paths interchangeably throughout this webinar. But I really like the analogy of this concept as a chain, where each link represents some explotable risk you have in your system, and together they create a whole chain or a path. Each link on its own may seem like a harmless misconfiguration, but in the context of an Attack Chain, it's a vital link leading the attacker to your core resources. From the attacker's perspective, the chain is only as strong as its weakest link, so in order to break a chain, we would only need to fix the risks on a specific link in the chain. In R-Mode we've defined two types of Attack Paths. This first one describes a workload that is exposed through a service or an ingress, has critical vulnerabilities on its image, and has some sort of misconfiguration that can allow further impact in the environment, like secrets or credentials that are mounted to it, or the service account token, which can ultimately allow an attacker to manipulate other resources. The second Attack Path is a workload that's similarly exposed and has no resource limits set, thus creating a potential denial of service by an attacker monopolizing the resources. Now let's see an action on R-Mode Platform. In this cluster, we've identified two Attack Paths that correlate to the two types of Attack Paths we've just seen. In this first one, we see that our deployment is exposed through a load balancer, has critical vulnerabilities on its image, and has three different risks that can cause further impact, like the fact that no network policy is applied on it. Each of these links map to either a security control used by Cubescape misconfiguration scanner, or a CVE identified by its vulnerability scanner. You may already be aware of each of these misconfigurations and CVEs, but Attack Paths put them into context, allowing you to identify those that have the most impact. Now let's look at the second type. It describes a potential flooding of the node resources caused by missing limit configurations on this workload. If we look at the details, we can see again that this workload is exposed and has no limits applied to the memory and CPU resources. Now I want to break this chain. We're all well aware that for Grafana to bring value, it has to be exposed, so this is a risk we should be willing to accept. But for the other link, we may have been willing to accept this misconfiguration of no limit set, or at least it wouldn't have been our top priority to fix, but seeing it in the context of an Attack Path highlights the urgency and makes fixing it a priority. So let's... We can use this fix button to help us quickly identify where and how to fix it. These lines are what we need to add in order to remediate this problem. We can just copy this YAML or download it as a file. Now let's open our favorite text editor, paste, change these values. I'm just going to use the same values of the requests for the limits and apply. Now let's navigate back to our Attack Path page, click scan again, and see the effect that this simple change has had on our environment. Amazing. There we are, that simple fix fixing one control for one resource broke an attack chain. Just goes to show that an attack chain is as strong as its weakest link. So now that we've learned about and understood this cool new concept, what can we do with it? Now we know how it is trying to maintain a secure environment. The amount of work is overwhelming. The idea of attack chains is not to introduce new threats and more things to worry about. It's to add a way to prioritize existing threats based on the risk they pose, so we can work on what has the most impact on our security posture. What do I mean by that? Our misconfiguration scans and our image scans, they skew out thousands of issues we need to take care of, and we just don't have the time to fix them all. So we use tools and information like the severity of each risk to prioritize our work, and that's great. But attack chains or attack paths, take this a step further, because we won't be fixing all our issues, but by fixing the right issue, a small change can have a big impact. If you remember in our demo, fixing just one single control for a single deployment broke a serious attack chain. After seeing these risks in the context of an attack path, we get information about how exploitable they are and what impact they have on our environment, and we're able to prioritize fixing misconfigurations that can cause serious harm, and with our limited and precious time, invest our efforts to get the most impact on our security posture. So what did we learn today? An attack chain is a series of risks that an attacker can exploit in order to access and manipulate your environment. Attack chains can provide context to our CVEs and our misconfigurations that we may have known about previously and didn't know we should prioritize. And an attack chain is only as strong as its weakest link. Thank you all so much for joining. I hope this helps you prioritize your efforts and harden your security.