> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/cloud-security-rules-and-policies/create-and-manage-cloud-security-rules/create-an-attack-path-rule.md).

# Create an attack path rule

Attack path rules identify critical risks arising from combinations of individual risk signals—such as overly permissive identities, network exposures, and exploitable vulnerabilities—that together form a potential breach path to high-value assets.

Perform these steps to create a custom attack path rule:

1. Navigate to **Posture Management** → **Rules & Policies** → **Rules** → **Cloud Security**.
2. Select **Create Rule** → **Attack Path (Legacy).**
3. In the **Overview** step, provide the following:
   1. Enter a **Rule Name and Description.**
   2. Select a **Severity.** Findings generated by this rule will inherit this severity.
   3. (Optional) Add **Labels**.
   4. (Optional) Enable **Remediation** using the toggle. In a later step, you'll enter the remediation instructions.
   5. Click **Next**.
4. On the Rule Logic page, you can select options to build your rule. The core logic for an attack path rule is built by selecting a primary asset and attaching **Finding** or **Vulnerability** conditions to it. See more information below.
5. Click **Next** to define Remediation instructions (if you had turned on **Enable Remediation** in the Overview step) or click **Done**.
6. (Optional) In the text field, define remediation actions or provide other information that will be included on issues created by this rule.
7. Click **Done** to save your rule.

## **Define attack path rule logic**

On the Rule Logic page, you can select options to build your rule. The core logic for an attack path rule is built by selecting a primary asset and attaching **Finding(s)** and **Vulnerability** conditions to it. The system logic checks for the *intersection* of any these findings AND the vulnerability on the asset; It is not required that all the selected findings are available on the asset.

1. **Select the asset:** In the **"Find"** field of the query editor, select the asset category (e.g., **Compute**) and the specific asset type (e.g., EC2 Instance).
2. **Add risk conditions:** Use the **+ (plus)** icon in the editor to add conditions. You can select one of the following:
   1. **Finding:** To correlate with existing misconfigurations or security findings.
   2. **Vulnerability:** To correlate with CVEs detected on the asset.
3. **Define finding logic:** If selecting **Finding**, you must provide the **Finding Name**. This name corresponds to the detection rule that generates the specific security signal (e.g., "AWS Security Group allows internet traffic").
4. **Define vulnerability logic** (if applicable). You can filter vulnerabilities by **CVE ID** (e.g., searching for a specific Log4j CVE), **Vulnerability Severity** (e.g., Vulnerability Severity > Medium) or by **CVSS Score** (e.g., Score >= 9.0).
5. Once the logic is defined, click **Search** to test the rule against your current environment and view potential findings.

## **Example rule logic structure**

A common attack path rule logic might look like this in the builder:

**FIND** EC2 Instance **WHERE** Finding = "Public Internet Exposure" **AND** Finding = "Overly Permissive IAM Role" **AND** Vulnerability = "Critical Severity"


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-posture-management/cloud-security-rules-and-policies/create-and-manage-cloud-security-rules/create-an-attack-path-rule.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.