Why choose Panoptica?
Four reasons you need the industry’s leading cloud-native security solution.
Attack path analysis can be a complex beast. We’ve spoken in the past about how a graph-based approach to security risk analysis can elevate your cloud security posture overall. Check out this previous article to learn about the building blocks of a cloud environment, and how to gain continuous mapping for this kind of enhanced risk analysis. In this second part of the series, we will take a deeper look at the implementation and use of graph theory in the context of cloud security.
How can we use the complex topology we have built for better security risk analysis to complete attack path analysis - ie, to better view attack paths in a specific environment and learn how attackers could gain unauthorized access? How can we assess the risk, not only with attack vector analysis, but also resulting from the attack paths we have identified? And how can we prioritize intelligently between different attack paths?
We will try to answer these questions in this article.
First, it is important to understand the differences between the terms attack vector and attack path, which are often used interchangeably although they do not mean the same thing.
An attack vector is the method used by an attacker to take advantage of a security mishap existing in a system, or in our case, a cloud environment. The attacker’s goal is to gain unauthorized access, to take control of resources, access system vulnerabilities or steal valuable data. The attacker can be a malicious employee (this is known as an insider threat) or an external hacker operating from anywhere on the internet. Common attack vectors we can name from attack vector analysis include stealing or accessing sensitive credentials, elevating access to protected resources via privilege escalation, network misconfigurations that lead to undesired internet exposure, and poor encryption of assets. Attack vector analysis will analyze what security vulnerabilities and attack vectors you have and how attackers could use these to gain unauthorized access to your network, whether that’s through a brute force attack, malicious code, or any other approach.
Before we jump to explaining what an attack path is, let’s look at another term that you’re likely to hear used interchangeably - attack surface. Your attack surface is a much broader term that describes all the potential vulnerabilities that your environment is susceptible to.
Each attack vector, (whether it’s a common attack vector like a malicious link in an email which leads an attacker to privilege escalation, or a less common attack vector like a granular misconfiguration) could allow an attacker to gain unauthorized access. However, when you’re talking about your attack surface, you’re describing anywhere and everywhere that an attacker might be able to gain access, including known, unknown and potential threats. To reduce your attack surface - it’s not enough to use attack vectors analysis and go after single threats, you need to be able to visualize how these vectors are used in context. And that’s where attack path analysis comes in.
An attack path is not the same as an attack vector. An attack path is a visual representation of the ongoing flow that occurs during the exploitation of such vectors by an attacker. The attack path gives emphasis on “connecting the dots” and looking at the entire context of an imposed risk. This starts from the network exposure of the asset in question, continuing to the asset whose access privileges are elevated by risky roles and permissions attached, all the way to the “crown jewel” - the sensitive asset to be exploited or impacted if the attack is successfully executed by the attacker. Today, this crown jewel asset is often sensitive data, and many cybersecurity technologies will start from this sensitive data, and then segment, isolate or protect to close any attack paths from being used. However, on the cloud - attack path analysis is not so simple.
Think about all the context-related questions that need to be asked when discussing an imposed risk in a cloud environment. Let us take, for example, the network exposure question: Is the asset exposed by a public application load balancer? Are its ports open to the internet by a misconfigured security group? Is it detectable by a 3rd party internet search engine like Shodan? All of the answers to these essential contextual questions are presented in the attack path analysis in a visual, intuitive, and easy-to-understand way.
Unlike signature-based attack analysis, the interesting and unique thing about attack path analysis is that they can uncover new and unknown risks, rather than those originating from known attack vectors. That means it’s able to show you your attack surface in a much more helpful way.
Attack paths can find threats that are seen solely from the graph topology and the logical connections between the nodes within it. To take the simplest case, think of an access key shared by multiple EC2 instances, as seen in the diagram below. By running a degree centrality algorithm on all access keys that exist in the topology, we can detect attack paths that impose a serious risk and could potentially lead to attackers making lateral moves in the environment to reach sensitive data or any other payload.
The attack path analysis gives the cloud owner a broad granular view on imposed risks and assets, and specifically those in concern or danger of attack. This view not only helps in mitigating current cases, it also prevents attacks from taking place in the future. The insights you can gain from giving extra attention to the attack path and the contextual view are critical for the successful mitigation of imposed risks in any cloud environment. They go so much further than attack vector analysis can achieve.
The next stage is understanding which risks should be prioritized, and in short - what threat is the most important in your own specific business case. This is just as complicated as it sounds! One of the biggest challenges in the cloud security field is to quantize the risk score of an attack path, even with attack path analysis tools. We want to create granular, risk-specific prioritization between the attack paths so that cloud owners and CISO’s know where to put their focus and resources and ensure that attackers have the least chance of obtaining unauthorized access to your environment.
To qualify attack paths properly with the calculation of a comprehensive risk score, a set of rules defining the risk that certain entities can impose in different scenarios must be both present and validated. Each node and relationship included in the attack path needs to be considered with respect to the attack context: a global network exposure has a notable impact in a publicly exposed asset scenario, whereas outdated access keys would have a heavier weight in scenarios where neglected resources are looked for. In short - context is everything.
By using mathematical tools like Euclidean norms and weight functions, each attack path is automatically given a normalized risk score on a scale of 0 to 100 at the point of detection, with severity level of the attack derived from this score and marked as low, medium, high, or critical. The risk system also allows for multiple attack paths to be grouped in accordance with the type of risk they present and sorted by their level of severity, for better aggregative post-analysis.
Another key point when talking about attack paths is differentiating between stateful and stateless architectures in the context of a cloud environment graph.
While a stateless graph detects attack paths as a one-time “detect and forget”, a stateful graph constantly keeps track of changes regarding entities and connections in the environment, that is, it will “remember” the environment’s history.
In a stateful graph, every attack path ever found in the environment can be investigated over a timeline including causes of unauthorized access and ongoing mitigation, with each action’s impact on the risk of the attack path. The stateful graph can therefore yield real-time detection of when an attack path has been resolved, offering positive feedback, and can also help in reducing mitigation bias towards specific kinds of risks by viewing risk trends in the environment.
However, being stateful also introduces technical challenges that must be addressed. Assuming some of our attack paths are cross-platform (meaning, containing entities from multiple cloud and orchestration environments), we need to apply risk calculations to any graph data coming in from various sources simultaneously. This requires implementing a smart scheduling mechanism that on the one hand does not decrease data digestion rate, but on the other hand allows for accurate and holistic risk analysis of the attack path.
It’s clear that attack vector analysis alone doesn’t offer a contextual view of your security risk, instead focusing on purely a single method that a bad actor might use to compromise your environment. Even attack surface tools will only bring together any attack vectors that are a potential threat. Neither of these approaches allow you to quantize risk, or to uncover what actually needs actionable attention in your cloud. Using attack path analysis is a huge leap forward for cloud security, but you also need to ensure that you have a stateful view, not simply a one-time-only stateless approach where risks are seen and then forgotten.
Having a reliable attack path analysis system in place with a stateful cloud environment is the combo no cloud owner can resist – and that’s exactly what you get with graph-theory-based approach. When implemented right, it allows for a focused and well-informed look into security blind spots, helps with both tracking and prioritizing threats, and achieves the goal of increasing the productivity of both risk reduction efforts and attack mitigation, leading cloud owners to better decision making overall.