The Beginner’s Guide to Attack Paths
Description: Why the future of cloud security is about seeing like an attacker.
Table of Contents
- How the Threat Landscape is Evolving
- What is an Attack Path?
- The Attack Path vs. Security Findings
- The Anatomy of an Attack Path
How the Threat Landscape is Evolving
According to Gartner, worldwide security and risk management spend will reach $150 billion in 2021. In another report by Cybersecurity Ventures, cybersecurity spend could reach as high as $1.75 trillion. With all the tools and increased security spend, one would expect that security teams feel confident and secure in protecting their assets. Yet today’s security teams are overwhelmed with the volume of alerts, struggling with siloed security findings, and finding it near impossible to determine which findings are critical and require immediate remediation and which ones don’t.
Could today’s security teams be going about security all wrong?
The future of protecting multi-cloud environments with a variety of layers and with a whole host of attack vectors means that a future solution must also be multi-faceted. It should be contextual and relate findings across multiple layers. It should be intuitive and able to prioritize findings while also surfacing them in a visual way. It should be sophisticated in nature by anticipating the moves of a hacker rather than simply rehashing existing vulnerabilities.
What is an Attack Path?
An attack path is not the same as an attack vector. Often these terms are used interchangeably, but an attack vector is a single method used by an attack to compromise a cloud environment, while an attack path can be defined as the following:
- It’s like a map or recipe. An attack path is a visual representation of exploitable attack vectors. Think of it as a “map” or “recipe” that an attacker could use to compromise a cloud environment. The attack path gives emphasis on “connecting the dots” and looking at the entire context of an imposed risk.
- It’s contextual. This context incorporates elements from a variety of risk categories—starting 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 exploitation of sensitive data.
- It’s like looking through the lens of the attacker. Attack paths can uncover new and unknown risks, rather than those originating from known attack vectors. How can this be done? The answer is by analyzing your attack surface by looking at it through the lens of the attacker. Attackers map security findings by identifying them in a cloud environment and then they see how each aspect of a finding could potentially impact another if it were to be compromised. This is how critical attack paths are constructed and eventually prioritized – which assets could be compromised, how easily, what connected accounts / identities or permissions could an intruder access if they breach asset X? Where are there the most exploitable gaps in your cloud’s surface area? The ability to think like an attacker provides an edge – instead of reacting to breaches, it is possible to proactively determine in which areas your multi-cloud environment has the most “appealing” gaps.
This is why attack paths are important. It’s a new representation, a new metric that leads to real risk reduction.
The Attack Path vs. Security Findings
And yet, most security teams today focus on security findings.
An attack path is very different from security findings. While security findings are a good place to start to protect your cloud environment, singular findings can leave holes in the bigger picture. This approach of connecting the dots provides a more sophisticated view of vulnerabilities than a single security finding would. It includes the context and evaluates the combined risk along several different variables:
|
|
Attack Path |
Security Finding |
|
Findings |
Combines multiple findings |
Single finding |
|
Context |
Uses context |
No context, presented in silo |
|
View |
Big picture |
Narrow view |
|
Risk |
Presents real full risk |
Presents partial-risk – disconnected from other factors in given environment |
Relevant risk categories
Open CVEs, Risky over permissive roles, private IP’s exposed to the internet, malware risk… all of these facets are important factors to determine prioritization to time-strapped security and DevOps teams. But these are just a few, here’s a list of relevant risk categories:
- Public exposure
- Identity risk
- Account compromise
- Data at risk
- Credentials
- Config risk
- Asset at risk
The attack path is key to understanding the context of the risks imposed on a cloud environment as opposed to single security findings where relationships and connections to other nodes or security issues may not be readily apparent. Attack paths show you what to focus on first, giving you the real, exploitable risk.
The Anatomy of an Attack Path
Attack path analysis is the key to uncovering new and known risks. As the “map” or “recipe” that an attacker could use, the intuitive, and easy-to-understand visualization of these attack paths is a game-changer for security organizations. Let’s look at a couple of examples:
Example 1: Access Key Shared by Multiple EC2 Instances (Low)
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 comprehensive view on imposed risks and assets, and specifically those in concern or danger of attack. This view not only helps in mitigating current cases, but it also prevents attacks from taking place in the future.
Example 2: Usage of IMDSV1 (Low) and Highly permissive role attached to workload (Medium)
The following two Security Findings are presented in the panel:
- Usage of IMDSV1 (Low)
- Highly permissive role attached to workload (Medium)
Without any context, these two singular findings can be considered as unrelated. But what if we add some context? Let’s assume there is an EC2 instance in the AWS account which uses MDSV1 and has an “S3 read all” role attached.
Now we can understand the connection between these two otherwise seemingly unrelated security findings. We now can see that they are both related to the same EC2 instance. Now that we understand they are related, we need to better understand the real risk associated with them. Should these findings be marked as “Low Risk” or “Medium Risk?”
To answer this question and calculate the effective risk we need to look at the entire cloud environment. We need to answer some important questions including:
- Within which VPC this EC2 located?
- Is it private or publicly accessible?
- What are the effective permissions between the role and the buckets?
- and more…
Analyzing the identified security findings with context enables us to evaluate the real risk. In this scenario, if the EC2 is public to any IP and there is no deny from the bucket’s resource-based policy, the real risk should be denoted as “High.”
Why This Matters
Current attack vector analysis only focuses on a single method. Even attack surface tools focus on existing attack vectors. Neither approach sufficiently quantifies risk or helps security teams uncover problems in the cloud. So, what’s the answer?
Leveraging attack path technology. Using attack path analysis is a huge leap forward for cloud security. Having a reliable attack path analysis system in place allows for a contextual and well-informed overview to combat security blind spots, helps with both tracking and prioritizing threats, achieves the goal of increasing the productivity of both risk reduction efforts and attack mitigation, and leads to more intuitive and improved decision making.
“Lightspin’s graph-based cloud security platform clears the noise of the non-critical misconfiguration alerts and helps us to shine a light on the critical attack paths using their prioritization engine.”
Yossi Yeshua, CISO
Riskified
*** This is a Security Bloggers Network syndicated blog from Lightspin Blog authored by Kenneth Balibalos. Read the original post at: https://blog.lightspin.io/the-beginners-guide-to-attack-paths
