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:
Navigate to Posture Management → Rules & Policies → Rules → Cloud Security .
Select Create Rule → Identity.
In the Overview step, provide the following:
Enter a Rule Name and Description.
Select a Severity. Findings generated by this rule will inherit this severity.
(Optional) Add Labels.
(Optional) Enable Remediation using the toggle. In a later step, you'll enter the remediation instructions.
(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.
Click Next.
On the Rule Logic page, you can select options to build your rule. See more information below.
Once your logic is defined, click Search to view real-time results from your environment
Click Next to define Remediation instructions (if you had turned on Enable Remediation in the Overview step) or click Done.
(Optional) In the text field, define remediation actions or provide other information that will be included on issues created by this rule.
Click Done to save your rule.
Define identity rule logic
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:
Permission Source: The human or non-human identity (such as a VM or function) that performs the action.
Permission Destination: The specific cloud resource or wildcard pattern being acted upon.
Policy: The IAM document, role, or resource-based policy that grants the rights.
Granter: The entity connecting the source to the policy, such as an IAM group or the source itself in the case of inline policies.
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:
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.
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.
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).
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.