Using Identity Posture

Apps Overview

The Apps Overview page enables you to monitor the health of all connected cloud service user applications, both out-of-the-box and custom. The Platform assigns an identity posture score to every application to help you understand the app’s state of compliance with best-practice configuration settings. For more information, see Checks. From the Apps Overview page, you can use this score to easily find those applications that are most vulnerable, and then drill down to see exactly which issues need to be managed.

To display the Apps Overview page, choose Identity Posture > Apps Overview from the main menu.

Every app is represented by a tile.

The app tiles are sorted by posture score (ascending), from 0% (greatest risk) to 100% (least risk). The app with the lowest posture score, that is, the greatest risk, is displayed first. You can filter the page to show one app type at a time.

The app is represented by two sections:

• Visibility: the number of cloud service accounts, groups, and assets

• Posture: the number of checks performed and failed, and the severities of the failed checks. For more information, see Checks.

When you click any field, you are shown the supporting data in the platform. For example, when you click the app title, the Checks page displays, filtered by that application. You can easily drill down for further explanation of the app status.

To focus on relevant apps, you can filter the page by application type, or type search terms into the search field.

Checks

The Checks page gives a structured security view for IAM/IT and security teams of how your company complies with best-practice configuration recommendations (“checks”) relating to identity misconfiguration, stale access, and over privileging.

For example, the Enable MFA (Multi-factor Authentication) for All Users check shows the level of MFA enrollment within the organization.

To see the Checks page, choose Identity Posture > Checks from the main menu.

The Checks page shows these parts:

• Overview: shows the company-wide posture-related data

• Table: shows data specific to each check

Each row in the table represents a different check the platform runs. These checks are based on instances of applications that are integrated with the platform.

By default, the page is sorted by descending check severity. You can change the sort order by clicking a column heading.

The checks are divided into these categories to streamline management:

• Authentication: mechanisms used to verify the identity of cloud service users, systems, or processes

• Privileged access: management of access rights for cloud service users with elevated permissions

• Stale access: management of outdated or unused access rights

• Security baseline: base configurations of the application

• Key management: management of keys

In addition to basic information about the check, the table shows the compliance frameworks relevant to each check, and how many entities failed the check ("affected entities").

The Checks side panel

The Checks side panel displays more details about the check and affected entities, which you can explore to remediate the issues.

To open the side panel, click a row in the table.

The Checks side panel shows more information about the check, including the security motivation for remediating the failed entities. You can also do the following:

• Disable the check so it no longer runs. Some organizations are unable to follow the best-practice recommendations and they are willing to accept the risk of a misconfiguration. At the same time, they don't want their overall posture score to decrease. Disabling a check will affect the identity posture score.

• Change the severity of the check. From the Affected Entities tab, you can view and manage the affected entities.

• See why each specific entity failed the check and get a recommendation on how to fix that.

• Exclude specific entities from being included in this check. This could change the status of the check; for example, if one excludes all the entities, the check will now pass.

• From the Remediation Steps tab, you can view remediation steps.

To disable or change the severity of a check:

1. Open a check’s side panel.

2. To disable the check, click Disable.

3. To change the severity of the check, select a severity from the drop-down.

To see and manage affected entities:

1. Open the side panel to look for a check that is in failed status.

2. All affected entities that are included are listed in the Affected Entities tab.

3. To see more information about why a specific entity failed and how to fix it, click the drop-down next to the entity name.

4. To exclude a specific entity from this check, click Exclude on that row.

5. Excluded entities are moved to the Excluded list:
   
   

6. To include an excluded entity, click Include.

7. To see general remediation steps for this check, click Remediation Steps.

AWS Shadow Admin

Our Shadow Admin engine discovers “Shadow Admin” cloud service users in IaaS providers who can perform privilege escalation but can’t manage the whole IAM model. This discovery can be performed by configuring authentication and authorization resources and by assigning roles to others.

An AWS shadow admin is a user (cloud identity) who can perform one of more of the following actions in one of the policies attached to it:

Actions

Action	Enables a cloud service user to...
CreateAccessKey	Create an access key for another IAM user.
CreateLoginProfile	Create another IAM user.
UpdateLoginProfile	Reset their user password.
AttachUserPolicy / AttachGroupPolicy / AttachRolePolicy	Attach a different existing policy to an identity, which provides an easy way to escalate privileges.
PutUserPolicy / PutGroupPolicy / PutRolePolicy	Add or update the inline policy attached to the corresponding identity.
CreatePolicy	Create new policies including an inline policy attached directly to an identity.
AddUserToGroup	Add a user to existing groups, which grants the user all privileges for the group.
UpdateAssumeRolePolicy	Chain roles, allowing a non-privileged role to assume a privileged one.
CreatePolicyVersion and SetDefaultPolicyVersion	Update policy versions to escalate privileges.
PassRole and (CreateInstanceProfile / AddRoleToInstanceProfile)	An instance profile is a role that can be attached to an EC2 instance to allow the code on it to call other services. Creating an instance profile and assigning it to instances can be used to escalate privileges.
iam:PassRole and lambda:CreateFunction and lambda:InvokeFunction	This combination of privileges allows a user to assign a role to a newly created Lambda function and invoke it. This technique can be used to hide escalated privileges and exfiltrate information.
iam:PassRole and lambda:CreateFunction and lambda:CreateEventSourceMapping	The event source is the origin of event data. This combination of roles allows an identity to sniff incoming data.
iam:PassRole and glue:CreateDevEndpoint	Creating new development endpoints in glue and assigning a role to them provides a new environment with all privileges granted by this role.
iam:PassRole and cloudformation:CreateStack	Cloud formation allows users to create AWS assets even if the user doesn’t have full privileges to create all other resources.
iam:PassRole and datapipeline:CreatePipeline and datapipeline:PutPipelineDefinition	By creating new pipelines or updating roles assigned to existing ones, the attacker can control or "spy" on your organization’s data in different data sources.
SetDefaultPolicyVersion	The policy version defines the AWS internal version language that the policy supports. By downgrading the version, a user can ignore fields and gain privileges that were bound to specific variables.
lambda:UpdateFunctionCode	Functions can call other AWS resources based on different trust policies in the account. By updating the code of a function, a user can escalate privileges and exfiltrate information.
glue:UpdateDevEndpoint	Glue endpoints define the environment the code will run on. Changing the glue endpoint can push code to protected environments or break your infrastructure logic.

Azure Permissions

Azure permission(s)	Description
Microsoft.Authorization/elevateAccess/action	Enables a cloud service user/attacker to elevate their privileges to become admins.
Microsoft.Authorization/roleDefinitions/write	Enables an attacker to update roles and escalate to administrative privileges.
Microsoft.Authorization/roleAssignments/write	Enables the user to assign other users to roles, meaning a user entitled to this role can make other admins.
microsoft.directory/users/password/update	Enables the user to reset another user’s password, which can help them gain control over accounts.
microsoft.directory/users/authenticationMethods/delete	Enables removal of a user authentication method like MFA, helping an attacker to steal an account.
Microsoft.Authorization/*/Write	Enables the user to assign any role to an application and elevate its privileges.
microsoft.directory/servicePrincipals/policies/update	Enables the user to update the role assigned to a service principle, which can lead to escalated privileges.
microsoft.directory/servicePrincipals/permissions/update
microsoft.directory/servicePrincipals/enable	Enables the user to re-enable a disabled service principle, so an attacker can find a disabled service principal with the right privileges and enable it.
microsoft.directory/groups/members/update	Enables the user to update cloud service group members, which allows the user to escalate privileges by adding the account to more privileged groups.
Microsoft.ManagedIdentity/userAssignedIdentities/write	Managed identities are like access keys; they limit the need to manage credentials and allow applications to access resources.
microsoft.directory/users/create	Enables the user to create new local users in active directory/Azure.
microsoft.directory/users/password/update
Microsoft.Authorization/classicAdministrators/write	Enables the user to add other users as administrators.