Identity rules detect security gaps such as over-permissive access or unused permissions by calculating net effective permissions across AWS, Azure, and GCP.
Perform these steps to create a custom identity rule:
1. Navigate to **Posture Management** → **Rules & Policies** → **Rules** → **Cloud Security** .
2. Select **Create Rule** → **Identity**.
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. (Optional) Associate this rule with a **Compliance Control**. Click **Add**, select one or more custom compliance controls from the list, and then click **Assign**. Custom configuration rules can only be associated with custom compliance controls.
6. Click **Next**.
4. On the Rule Logic page, you can select options to build your rule. See more information below.
5. Once your logic is defined, click **Search** to view real-time results from your environment
6. Click **Next** to define Remediation instructions (if you had turned on **Enable Remediation** in the Overview step) or click **Done**.
7. (Optional) In the text field, define remediation actions or provide other information that will be included on issues created by this rule.
8. Click **Done** to save your rule.
### **Define identity rule logic**
When building identity rule logic, you define the criteria based on the five pillars of a permission. You choose an asset and apply filters to its attributes and its relationships to other assets. The five pillars are:
1. **Permission Source:** The human or non-human identity (such as a VM or function) that performs the action.
2. **Permission Destination:** The specific cloud resource or wildcard pattern being acted upon.
3. **Policy:** The IAM document, role, or resource-based policy that grants the rights.
4. **Granter:** The entity connecting the source to the policy, such as an IAM group or the source itself in the case of inline policies.
5. **Permission:** The actual action granted, including attributes like the **last used time** and **access level** (e.g., Administrative, Write, or Config).
To construct rule logic:
1. **Select the primary asset (pillar):** You begin by choosing one of the pillars to be the focus of the rule. The system will generate issues _only_ for the first entity type you select (the Source, Granter, or Destination).
For example, if you want to flag risky _users_, start by selecting the **Source** entity.
2. **Apply attribute filters:** Once an asset is selected, you add logical conditions based on its attributes.
For example, you can filter for a **Source** where Cloud Type = AWS and Identity Type = IAM User.
3. **Define relationships:** You then connect this asset to other pillars to describe the risky permission path.
For example, You can define a relationship where the **Source** (User) _has permission_ to access a specific **Destination** (e.g., Production DB) via a specific **Permission** (e.g., Delete).
4. **Validate with search:** After constructing the logic, click **Search** within the rule builder. This runs the query against your current environment to show real-time results, allowing you to verify that the logic correctly identifies the intended assets before you save the rule.
### **Example rule logic structure:**
A common custom rule might look for an **AWS IAM User** (Source) who has **Administrative** access (Permission) but has **MFA Disabled** (Source Attribute). The logic would be constructed by:
1\. Selecting **Source** (IAM User).
2\. Filtering for MFA Enabled = False.
3\. Connecting to **Permission** where Access Level = Administrative.