An "Attack Path" refers to a sequence of steps or a series of vulnerabilities and misconfigurations that an attacker exploits to achieve their malicious objectives within a cloud environment.
Key components of an attack path in cloud security include identifying:
Initial Access: The attacker gains entry into the cloud environment. This could be through exploiting vulnerabilities in cloud resources, finding internet-exposed assets and exploiting them, or using stolen credentials. Prisma Cloud has OOTB policies for detecting all three of these use cases.
Privilege Escalation: After gaining initial access, the attacker seeks to increase their privileges. This could involve exploiting misconfigurations in identity and access management (IAM) policies, taking advantage of overly permissive roles, or finding ways to escalate their permissions within the cloud environment. You can leverage the CIEM module within Prisma Cloud to identify privilege escalation risks in your environment.
Lateral Movement: The attacker moves laterally within the cloud environment to identify and access additional resources. This could involve exploiting network configurations, insecure APIs, or misconfigured storage services.
Persistence: The attacker establishes a foothold to maintain access over an extended period. This could involve creating backdoors, manipulating cloud service configurations, or planting malware. One can leverage to create Audit event policies within Prisma Cloud to detect this.
Data Exfiltration or Impact: The attacker executes their final objective, which could be data theft, destruction, or ransom. This involves extracting sensitive data from cloud storage, databases, or other cloud services or disrupting the availability and integrity of cloud services. Our DSPM module is capable of detecting and mitigating these types of attacks.
Figure 1: High-level overview of a contextual graph generated by an attack path alert_PaloAltoNetworks
Prisma Cloud provides over 350 out-of-the-box (OOTB) attack path policies, addressing the most common and exploited attack path scenarios. These policies are regularly updated with each release. Additionally, we offer customers the capability to create custom attack path policies tailored to their specific security requirements. The rules for creating these custom policies will be discussed later in this article.
In Prisma Cloud console, ensure that you have enabled any new Critical and High-severity policies that get released by navigating to Settings > Enterprise Settings > Auto-Enable Default Policies.
Figure 2: Enterprise settings option to enable OOTB policies by default_PaloAltoNetworks
Under the ‘Governance’ tab, filter by Policy Type “Attack Path” and confirm that all Attack Path policies are enabled.
Figure 3: Governance tab with “attack path” filter as policy type_PaloAltoNetworks
Under the ‘Governance’ tab, filter by Policy label “Attack Path Rule” and ensure all those policies are enabled.
Figure 4: Governance tab with “attack path rule” as policy label_PaloAltoNetworks
To ensure comprehensive coverage and effective security management, it is imperative that the IAM security (CIEM) module is enabled when configuring Attack Path policies. Please verify that the CIEM module is activated to achieve the desired 100% coverage.
Figure 5: Identity visibility under the Runtime pillar as seen in the Adoption advisor_PaloAltoNetworks
Finding name: When creating attack path policies, a “finding name” means a saved policy within your Prisma Cloud environment.
Finding type: These are a set of findings with a specific security focus, such as botnet activity, data exfiltration, etc.
Using “contains all”: To ensure a resource violates all the selected conditions. The resource must satisfy all the specified "finding names" to be considered a match. Example: If the "finding names" are ["condition1", "condition2", "condition3"], the resource must violate condition1, condition2, and condition3.
Using “in”: To ensure a resource violates at least one of the selected conditions. The resource must satisfy at least one of the specified "finding names" to be considered a match. If the "finding names" are ["condition1", "condition2", "condition3"], the resource can violate either condition1, condition2, or condition3.
Limitations:
1. We only support Asset types for now. Only one asset type is supported at any time for an Attack path policy.
2. One or more Finding name/s is/are required to create an Attack path policy.
3. We only support up to ten finding names while creating an attack path policy.
Figure 6: Illustration of limitations_PaloAltoNetworks
Objective: Create an attack path policy that shows internet-exposed ec2 instances that can read and delete data from s3 buckets, have a critical vulnerability, can be exploited for log4j, and are not configured with Instance Metadata Service v2 (IMDSv2).
Analysis: This attack path policy can be broken down into the following components:
Network misconfiguration: Display internet-exposed ec2 instance
Identity misconfiguration: Display ec2 that can delete and read s3 buckets
Vulnerable: Exploitable and vulnerable for log4j
Asset misconfiguration: Display instances not configured with (IMDSv2)
Detailed Steps:
Navigate to the Investigate tab, and from the options, choose “Asset.”
Figure 7: Selecting Asset options_PaloAltoNetworks
Select “Type” as the next option, as we only support Asset type. Also, only one asset type can be selected. (We do not support Asset class or Asset Cloud Service)
Figure 8: Type selection_PaloAltoNetworks
Select EC2 instance as the type
Figure 9: Writing an attack path Policy for an AWS ec2 instance_PaloAltoNetworks
Select finding names (aka policies) as per the analysis done in the previous step
OR
(Note: Here, having separate finding names OR using contains all operator will give you the same result)
Figure 10: Showing all individual finding names_PaloAltoNetworks
Select Search and save as a new policy.
Figure 11: Saving new policy_PaloAltoNetworks
Verify the policy is created from the Governance tab and attach this policy to an alert rule.
Navigate to the alerts tab and filter by policy type - “Attack path.”
Select any policy and click on the corresponding alert ID
Figure 12: Policy selection_PaloAltoNetworks
Click on evidence, and you should be able to see the entire context across different finding names in the graph.
Figure 13: Illustration of multiple ways the instance can be exploited._PaloAltoNetworks
Fix the underlying asset on the cloud service provider based on the findings from Step 3, and the alert should be marked as resolved within the next 15-20 minutes automatically on Prisma Cloud.
In a rapidly evolving threat landscape where vulnerabilities can originate from myriad vectors, robust attack path analysis is crucial for proactive threat mitigation. Leveraging the advanced capabilities of Prisma Cloud’s attack path analysis and unified security environment, cybersecurity professionals can perform deep asset discovery and attach sophisticated attack path vectors to identify critical assets.
With a single comprehensive query, security architects can pinpoint assets exhibiting excessive permissions, harboring critical vulnerabilities, being internet exposed, and having certain anomaly configurations, thereby enabling immediate risk mitigation. This proactive approach, grounded in best practices and the latest cybersecurity frameworks, underscores the strategic importance of integrating advanced threat modeling and attack path analysis into an organization's security strategy.
Bishvesh Pachauli is a Cloud Security Architect (Customer Success Engineering) at Palo Alto Networks, dedicated to protecting organizations from cyber threats and ensuring the confidentiality, integrity, and availability of their information systems. With over eight years of experience and a Master's degree in Cybersecurity and Information Systems, Bishvesh has a robust background in threat modeling, vulnerability assessment, incident response, and security architecture design.
