Learn how to review and improve your Identity Security posture with the provided use case examples.
Notice
This feature is included with a Cortex XSIAM Premium license. It is also included with any other Cortex XSIAM license that has the Cloud Posture Management or Cloud Runtime Security add-on.
Cortex Cloud Identity Security provides tools to monitor and manage identity permissions across Cloud and IdPs, maintaining an inventory of human and machine identities and identifying security risks such as inactive accounts, excessive permissions, and role-chaining configurations. To improve your security posture, Cortex Cloud Identity Security offers remediation workflows to remove unused permissions and mitigate identified risks.
The Cortex Cloud Identity Security dashboard provides an overview of various aspects of identity posture, which you can use to quickly assess your identity posture and the main identity security gaps. Each widget on the dashboard provides you with a specific context that you can use to learn about your environment, understand the most pressing issues, accessing the relevant pages in the product so you can remediate them.
Identity inventory summary widgets
The row of identity inventory widgets across the top of the dashboard shows you how many assets have been discovered, according to each asset category:
Unified Human Identities: Displays all cloud identities, SaaS identities, and on-premises identities.
Non-Human Identities: Can assume permissions and conduct cloud IAM actions. This includes, for example, VMs and functions.
Cloud Service Accounts: A category unifying AWS roles, Azure service principals and managed identities, and GCP service accounts, and OCI service accounts.
Groups: Displays the number of IAM groups and issues.
Policies: Permission documents. AWS and OCI policies, and Azure and GCP roles.
Top Critical Issues to Address area
Displays a refined list of the most important identity issues to take note of in your environment. Issues are prioritized based on the severity of detection rules, the number of violating assets, and their association with MITRE tactics and techniques. Use this view to quickly focus on the most critical security gaps and strengthen your security posture.
Identity Security Findings
Use the Identity Security Findings widget to find common misconfigurations in your environment:
The Inactive Identities section shows the total number of users that have not logged in to the cloud environment for at least 90 days per cloud provider.
The Identities with Unused Permissions section shows identities that have been granted permissions but have never accessed those permission.
The Identities with Excessive Policies section shows identities such as users, machines, groups, and cloud service accounts with excessive policies attached. The definition of excessive policy includes:
Amazon AWS: A policy is considered excessive if it includes a full wildcard (resource and scope are:
*), or a service-level action wildcard (such as AmazonS3:*) , or a full wildcard in resource (meaning an action can be performed on all the resources of a service).Microsoft Azure: When a role contains a wildcard and is bound to an entity on a management group scope, or grants an action wildcard and is bound to an identity at the subscription level.
GCP infrastructure platform: When binding a specific predefined role on the organization, folder, or project level.
Oracle Cloud Infrastructure (OCI): When a policy grants the
manageverb forall-resourcesat the tenancy level, granting unrestricted administrative control over every service and resource in the environment.
Admins Summary
The Admins Summary widget provides you with valuable insight regarding the identities that are granted administrative permissions, in any way possible, in your environment. Admins are not necessarily found only in your administrators group, because identities can be granted administrative permissions in numerous ways, both intentionally or unintentionally. Use this widget to analyze how many administrators there are in your environment, and on which level they are granted administrative permissions.
Top Identities at Risk
In the Top Identities at Risk widget, you can view identities with the highest amount and severity of risks, in order to identify the riskiest identities in your environment.
You can find your identity issues in one of the following ways:
By filtering the issues page according to issues detected by Cortex Cloud Identity Security.
By following the identity issues link under the Cortex Cloud Identity Security module menu.
When opening each identity security issue, you are provided with relevant evidence, such as an explanation about the issue, what's causing it, why it is important and what you can do to fix it. Additionally, you are provided with detailed information about the risky permissions, misconfigurations, or any other detail relevant to understanding and solving the issue. For more information, see Issues.
You can review an identity's access by using the access table, which is found on the Access tab of an asset, and appears for the following assets:
Identities (human and non-human)
Cloud service accounts
Groups
Cloud destinations (assets on which IAM actions can be performed)
Since each asset plays a different role in a permission (a human identity performs actions, while a group grants permissions), each asset is therefore associated with a slightly different table, showing relevant information about the permission relevant to the asset.
Note that some assets can have more than one role in permissions. For example, a non-human identity can be both a source and a destination. For that reason, such assets get two tables. For example, a cloud service account has the following two tables:
What can this Cloud Service account do, and to whom does it grant permissions?
Who can access this asset?
For each row, which represents a direct relationship between a source, a destination and a granter, the access table shows additional information about the relevant permission, such as:
Which access levels are granted.
How many unused and excessive permissions are granted. Clicking on the number of unused or excessive permissions opens a new window, showing a detailed list of all these permissions.
What is the account access type?
Which sensitive data labels are found on the permissions destination (where relevant)?
Additionally, the destination assets overview page shows a list of identities that can access them. This table displays the top 100 most permissive identities for the asset, ordered according to the latest access that was performed on this asset.
To achieve the principle of Least Privilege Access (LPA), you can use the Review Unused Permissions feature to analyze audit logs and detect inactive permissions for AWS and Azure identities. Based on actual usage over a customizable timeframe, the system recommends specific actions and generates optimized, downloadable policy files in formats such as JSON, Terraform, or CloudFormation to help reduce your attack surface.
For more information about LPA, see Achieve the principle of least privilege access.Achieve the principle of least privilege access
Note
Least Privilege Access (LPA) is not supported in OCI.
For various reasons, you may choose to grant access to your account to a third-party vendor. However, are you monitoring for over-privileged third-party vendors? Are you removing unused permissions granted to third-party vendors?
Access tables: Filter a destinations access table on the third-party vendor account access to view all third-party vendors that can access the destination. You can now see what each vendor can do with the asset, whether each vendor has been granted excessive access, and if there are any unused permissions that can be removed.
Role chaining overview
Role chaining is an Identity Security concept that describes a configuration where one role is granted the permission to assume another role. This relationship creates a transitive link, meaning that any identity (user, service, or other role) that is able to assume the first role (Role A) can then leverage those permissions to assume the second role (Role B), as a result inheriting all the permissions and entitlements granted to Role B.
This configuration presents a significant security risk, as it can be exploited for lateral movement across the cloud environment and privilege escalation for the original identity, leading to unintended and potentially excessive access.
Detection
Cortex Cloud Identity Security provides capabilities to detect and monitor instances of role chaining, specifically focusing on configurations that enable potential lateral movement or privilege escalation.
Detection mechanism: Cortex Cloud Identity Security is delivered with out-of-the-box rules to specifically identify scenarios where Role A has permission to perform the
AssumeRoleaction on Role B (Role A to Role B).Visibility tools: Detection can be confirmed using permission exploration tools such as the advanced access table and XQL queries.
From Role A's perspective: The tools reveal the permissions granted to Role A that allow it to assume Role B.
From Role B's perspective: The tools reveal that Role A is configured as a principal authorized to assume Role B using Role B's trust policy.
Custom rules: In addition to built-in rules, security teams can create custom detection rules targeting role chaining scenarios, specifying an AWS IAM role as the permission source and another IAM role as the destination.
Remediation
To mitigate the security risk associated with role chaining, you must remove the permissions that allow the role assumption. The actual remediation steps depend on how the permission was originally granted, such as in these scenarios:
Removing
AssumeRolepermissions from Role A:Policy modification: Remove the specific
AssumeRolepermission targeting Role B from the policies attached to Role A. This applies whether the permission is granted using a custom policy, a managed policy, or an inline policy directly embedded within Role A.Modifying Role B's trust policy:
Deny assumption: Edit role B's trust policy to explicitly remove or deny Role A as a trusted entity authorized to assume the role.
NHI posture overview
NHI (nonhuman identities) represents the majority of entities in modern cloud environments. These identities include service accounts, access keys, and tokens used by automated workloads. Because they are often created automatically by CI/CD pipelines, they can lead to identity sprawl, where unused or over-privileged credentials create significant security gaps.
By regularly reviewing your NHI posture, you can reduce your attack surface, ensure compliance with data residency requirements, and enforce the principle of least privilege for automated workloads.
Audit NHI by cloud provider
The platform provides a unified view of machine identities while maintaining the specific terminology used by each cloud provider. Use the table below to identify equivalent assets across your environment.
Provider | Machine entity equivalent | Posture focus |
|---|---|---|
AWS | IAM Users (Access Keys), Pod Identities, SAML/OIDC Providers. | Audit Last Used dates for access keys; monitor SAML provider private keys. |
Azure | Service Principals, Managed Identities, Key Vault Certificates. | Monitor Key Rotation Policies; identify expired Key Vault certificates. |
GCP | Service Accounts, OAuth Clients/Brands. | Map Service Account to Key relationships; audit IAP (Identity-Aware Proxy) configurations |
OCI | Compute, Functions, Kubernetes Cluster, Autonomous DB, API Gateway | Audit Matching Rules for Dynamic Groups, Map Resource-to-Group Inheritance, API key usage. |
Key posture improvement workflows
Eliminate dormant credentials
The most common NHI risk is the "orphaned" or dormant credential. Use the Non-Human Identities and Secrets inventories to identify credentials that are no longer in use.
Action: Navigate to Modules → Identity Security → All Identity Assets.
Action: Filter for Non-Human Identities or Secrets where the Last Used attribute is greater than 90 days.
Result: Deactivating these credentials in your cloud console reduces the risk of a compromised shadow identity.
Review secret replication and compliance
For organizations with strict data residency requirements, secrets must not exist in unauthorized regions.
Action: In the Secrets inventory, review the Region or Location attributes.
Action: For AWS Secrets Manager, specifically identify Replica secrets.
Result: You ensure that sensitive credentials, such as Bedrock API keys, are only stored in approved geographic jurisdictions.
Analyze the Identity access chain
Attackers often use compromised machine identities to move laterally. You can visualize how an identity reaches a resource using the relationship graph.
Action: Open an Asset Card for a User or Service Account.
Action: Select the Identity tab and navigate to the Relationships subtab.
Result: You can see every identity–human or non-human, that has permission to Read or Get a specific secret. If an identity does not require this access for a production workload, you should revoke the permission.
Common NHI misconfigurations to remediate
Prioritize the remediation of these common risks found within your inventories:
Stale Access Keys: Access keys that have not been rotated within your organization's compliance window (typically 90 days).
Dormant Identities: Non-human identities with no recorded activity in 30 days or more.
Excessive Secret Access: A single non-human identity with Read or List permissions for an entire managed vault rather than specific secrets.
Non-Compliant Secret Residency: Secrets replicated to cloud regions that fall outside of authorized geographic boundaries.
Unprotected OAuth Clients: GCP OAuth brands or Azure identity providers that lack a designated owner.
Tip
Reducing the number of non-human entities that are either dormant or have administrative privileges is the most effective way to improve your security score.