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 security 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 over attack paths in a specific environment? How can we assess the risk 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.
Understanding Attack Vector vs Attack Path in Your Security Risk Analysis
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.
What is an attack vector?
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 control of resources, sabotage systems 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 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.
What is an attack path?
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.
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 in a visual, intuitive, and easy-to-understand way.
Unlike signature-based attack analysis, the interesting and unique thing about attack paths is that they can uncover new and unknown risks, rather than those originating from known attack vectors. 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.
The attack path 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.
Quantizing Attack Path Security Risk
One of the biggest challenges in the cloud security field is to quantize the risk score of an attack path. 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.
In order 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 taken into account 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.
Stateful vs Stateless Graph Architecture
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 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.
Having a reliable security risk analysis system in place for attack paths in 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 ultimate goal of increasing the productivity of both risk reduction efforts and attack mitigation, leading cloud owners to better decision making overall.