Attack Paths

Why are attack paths important?

While security findings are a good place to start to protect your cloud environment, singular findings can leave holes in the bigger picture. To better secure your cloud stack, attack paths are vital. To see how the attack path approach works, let's look at the following example:

The following two Security Findings are presented in the panel:

1. Usage of IMDSV1 (Low)
2. Strong 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 that uses MDSV1 and has an "S3 read all" role attached.

We can now understand the connection between these two otherwise seemingly unrelated security findings. We can see that they are both related to the same EC2 instance, and so 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 is this EC2 located?
• Is it privately 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."

What is the difference between an attack path and a single finding?

We define an attack path as a combination of single findings. There are also certain properties in the environment that answer specific terms for graph queries generated by our algorithm. For example, a pod that has a “list all secrets” permission is defined as an attack path since it can escalate its privileges and gain access on the entire cluster. A privileged pod, on the other hand, is a single finding. A possible attack path for such a scenario would be a privileged pod also exposed as a service.

What are critical attack paths?

An attack path presents possible lateral movements in the cloud. These lateral movements could be inside the account, cross-account, cross-provider, or even cross-platform.

An attack path combines multiple singular findings into a path on top of the cloud environment topology. This approach exposes the real risk of these security findings, as each attack path reflects the probable chain of attack that a nefarious actor would likely leverage in a specific environment. The attack path is the flow of interconnected assets/accounts/identities/permissions that an attacker would use to exploit a cloud environment.

In the Panoptica platform, attack paths aggregate security findings and are presented as such in the dashboard. Instead of seeing a list of thousands of alerts, users are presented with attack path groupings and can remediate multiple attack paths with overlapping root causes in a single action.

What is Panoptica's attack path differentiator?

Most CSPM and legacy cloud solution providers offer users thousands of security findings and alerts, but offer them in silo. This means that security and compliance teams are missing the critical connective tissue and context between different types of alerts or vulnerabilities, that would help to create a more holistic picture, and context around whether such an alert is critical or does not require immediate remediation.

Panoptica flips the typical approach to CSPM and cloud security management on its head, looking at findings in aggregate and making the right connections between these otherwise disparate findings to create prioritized attack paths. The attack paths are therefore defined as a combination of these single findings and properties in the environment that answer specific terms for graph queries generated by our algorithm.

For example, a pod that has a “list all secrets” permission is defined as an attack path since it can escalate its privileges and gain access on the entire cluster. A privileged pod on the other hand, is a single finding, a possible attack path for such scenario will be a privileged pod also exposed as a service.

The Results
By looking at attack paths rather than disparate security findings, Panoptica easily prioritizes findings to only the critical alerts that require remediation.

Beyond providing the visualization and prioritization of the attack paths present in the environment, Panoptica also offers the ready-made remediation businesses need to easily take care of the vulnerabilities across their cloud stack.

Why does Panoptica classify attack paths for assets with only private network access as a High or Critical severity, if the attacker has no network access to the pod/account?

If there is no public access, then the attack vector is internal. Panoptica presents both internal and external risks.

If the attack is an “attacker from the inside”, there are several possibilities:
(1) The attacker used some type of vulnerability (such as a publicly exposed access key in a GitHub repo), to get a first foothold into the environment. This can be any vulnerability that enabled them to get in (application vulnerability/phishing attack/Log4Shell).
(2) The internal attacker may be an authorized employee that decided to do damage to the company.
In this case, the internal attack vector is still an important attack vector, because it exposes the potential lateral movements inside the environment.