> ## Documentation Index
> Fetch the complete documentation index at: https://tonelloandco.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Users
> The Users page provides numerous ways to quickly sort, filter, and rank the detected user information to remediate identity risks associated with individual accounts and their permissions.
**Upcoming Changes to Sysdig Product Line**
The legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new **Identity Overview** and **Findings** pages to become familiar with the updated experience.
## Users
The **Users** page provides numerous ways to sort, filter, and rank the detected user information to quickly remediate identity risks associated with individual accounts and their permissions.
## Filter and Sort Accounts
Use the sortable columns to organize and filter user accounts for assessing identity risks. You can sort user accounts based on the following criteria:
#### Unused Permission Criticality
Unused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. Unused Permission Criticality is designed to help you achieve Least Permissive access.
Values: **Critical, High, Medium, Low**
#### Risk
This is a calculation of risk based on all permissions. See [Understanding Risk Scoring](https://docs.sysdig.com/en/docs/sysdig-secure/identity/#understanding-risk-scoring) for more information.
Values: **Critical, High, Medium, Low**
#### % of Unused Permissions
This shows the number of unused permissions per total permissions for the user, shown as a percentage graph.
When remediating, immediately target the users with the greatest exposure and refine them according to the suggestions.
#### Highest Access
Highest Access offers a quick way to filter by **Access Category**. It shows this identity entity’s highest level of access according to all of its permissions. For more information, see [Understand Highest Access](https://docs.sysdig.com/en/docs/sysdig-secure/identity/#understand-highest-access).
Values:
* **Admin:** Admin access granted
* **Write:** Write access granted
* **Read:** Read access granted
* **Empty Access:** No permissions are granted at all
#### Findings
A finding in Cloud Infrastructure Entitlement Management (CIEM) indicates poor security hygiene, either due to misconfiguration or inadequate identity security practices. The findings on User pages include:
* `No MFA`
* `Admin`
**AWS-Specific**
* `Access Key Not Rotated`
* `Multiple Access Keys Active`
* `Root User`
* `Inactive`
**GCP-Specific**
* `Editor Role Applied`
* `Owner Role Applied`
### Available Filters
* **Search:** Free text search on terms in the resource name
* **Unused Permission Criticality:** By severity
* **Cloud Accounts:** Account name or account number by cloud provider. For example, `AWS`
* **Access Categories:** `Admin`, `Write`, `Read`, or `Empty Access`
* **Policy Types:** `AWS-Managed`, `Customer`, `Inline`
* **Findings:** See [Findings](https://docs.sysdig.com/en/docs/sysdig-secure/identity/users/#findings)
## Next Steps
To reduce the entitlements for a particular user, click on the user name to open the detail drawer and subtabs.
* [Optimize AWS User Entitlements](https://docs.sysdig.com/en/ciem-opt-aws-user)
* [Optimize GCP User Entitlements](https://docs.sysdig.com/en/ciem-opt-gcp-user)
* [Optimize Azure User Entitlements](https://docs.sysdig.com/en/ciem-opt-azure-user)
## Optimize AWS User Entitlements
You can examine and remediate identity risks associated with specific IAM accounts and their permissions by using the detailed drawers. Simply click on individual rows on the Users page to open the detailed drawer for further analysis.
## Manage User Entitlements with Detail Drawers
The Users page organizes everything around the individual user account.
* **Overview:** Displays the critical permissions issues detected for this user account, sorted by Permission Criticality and Unused Permission Criticality.
* **Attached IAM Policies:** Displays the policies this user account is connected to, sorted by unused permissions and total permissions included in the policy.
* **Attached Groups:** Displays the groups this user account is connected to, sorted by unused permissions and permissions count.
* **User Details:** Displays a summary of total granted permissions, group associations, activity, user ARN ID, and findings associated with the selected user account.
To reduce a user's entitlements, click on the user name to open the detail drawer and sub-tabs. The following examples provide various remediation options.
## Understand User Permissions
* **Total Permissions** are the total number of permissions granted to a user from all the policies the user is associated with.
* **Unused Permissions/Permissions Unused** are the total number of unused permissions from all the user’s policies.
* **Permissions Given** are the permissions granted to a user per policy.
Investigate the **Attached IAM Policies** tab in a user’s detail drawer to see how the permission totals are divided and how to handle the surfaced risks.
For example, this user has been granted 15521 permissions, divided between multiple policies, all of which are unused.
To remediate the permissions in this example, you might:
* Delete an unused policy: In the example above, the policy with 103 permissions given has not been used by any IAM entity. Sysdig recommends removing this policy from your AWS environment.
* Optimize the Policy Globally.
For more information, see [Create an Optimized User Policy](https://docs.sysdig.com/en/docs/sysdig-secure/identity/iam-policies/#optimize-a-policy-globally).
* Create an Optimized User Policy.
See [Understanding the Suggested Policy Changes](https://docs.sysdig.com/en/docs/sysdig-secure/identity/#understanding-the-suggested-policy-changes) for more information.
## Apply Remediation Strategies
Sysdig suggests the following remediation possibilities.
### Create an Optimized User Policy
On the **Connected IAM Resources** tab, select the policy you want to optimize. Open the Details tab of the policy, select **Remediation Strategies**, and click **Optimize this IAM Policy with a subset of only used permissions**. You can then download the suggested policy, upload it to your AWS Console, and associate it with this user. This option creates a new, user-specific policy that considers all the policies with which the user is associated.
You can also note the user’s policy associations listed in the **Attached IAM Policies** subtab and remove those associations in AWS.
### Delete an Inactive User
Sometimes, a user may be associated with multiple policies and groups and have a very high cumulative number of permissions granted, but Sysdig detects no user activity in the environment for over 400 days. In this case, removing the user from your cloud environment is recommended.
In the example above, this would eliminate all 15,521 permissions granted and remove this identified Critical risk.
### Optimized for Potential Compromise
Sysdig tracks all the permissions used by a user after they are flagged as potentially compromised. By default, these permissions are excluded from policy optimizations. This careful scrutiny helps maintain the integrity of security policies by granting only legitimate permissions and reducing the risk of privilege escalation and lateral movement by threat actors. This proactive approach helps ensure that policy optimizations remain secure against malicious actions.
## Use Case: Potentially Compromised User
Overly permissive credentials can lead to lateral movement and privilege escalation, resulting in cloud breaches. Sysdig helps prevent attacks by strengthening your identity posture by detecting anomalous or suspicious user actions and enabling real-time incident response. Sysdig offers the following findings to help correlate identity behavior with events, enabling detection and response to compromised user identities.
* **Potentially Compromised User**: Misconfigured identities and secrets, combined with certain operation patterns, often indicate a breach. Sysdig Threat Detection rules can identify suspicious account activity, such as privilege escalation and multiple account creations, and flags these as **Potentially Compromised,** helping you start investigating promptly.
Potentially Compromised is the finding that is triggered when Sysdig detects anomalous or suspicious user actions. It indicates that you should investigate this user.
* **Compromised User**: You have the capability to flag a user as Confirmed Compromised and it serves as a clear signal that the incident has been thoroughly triaged and is not a false positive. You can then take appropriate actions, such as deleting access keys, or deactivating or deleting the user.
Sysdig provides recommendations for each option, guiding you through the necessary steps to address the compromise. You see these recommendations when a user is flagged as **Potentially Compromised**, and they remain the same even if you mark the user as Compromised.
Additionally, you can also view findings related to potentially compromised users in the [Risk](https://docs.sysdig.com/en/sysdig-secure/risks/#use-case-compromised-user) module.
### Correlate Events to Identities
The Sysdig **Events** page displays the policy rule that triggered each event along with the associated user details, and it allows filtering. For example, you could filter by the **Advanced Cloud Behavioral Analytics** policy to find if any user has been identified as **Potentially Compromised**. These events, essentially, indicate that an identity breach has occurred.
### Triage the Event
You can then triage the event as follows:
1. Click one of the events to open the Events Details panel.
2. Click **Investigate**.
You will be directed to the **Identity Investigation** page, where you can see the cloud account, IP address, AWS region, user in question, and the user activities.
3. Click the user to:
* **Summary**: View a summary of unused permissions, total permissions, criticality of permissions and unused permissions. The criticality is determined by the excessive permission granted to the user through the roles attached to the User. The details panel also shows when the user was last active, User ARN, and account ID.
The Summary tab also shows if the user is **Compromised** or **Potentially Compromised**.
Sysdig does not mark a user as **Compromised**. You should manually check the Potentially Compromised User, triage the activities, and mark it appropriately.
* **Respond**: Mark as **Compromised** if you think the user is compromised.
* Mark as **Compromise Resolved** if you have already taken remediation actions.
* **Remediation Strategies**: Provides two high level strategies to mitigate the risk.
* **Contain Compromise**: You can address the compromise in the following ways:
* Add Restrictive Policy for IP
* Deactivate User
* Delete User
* Force Password Reset
* Delete & Create New Access Keys
* **Consolidate and Reduce Permissions**: Create a new custom IAM Policy for the User with a subset of only used permissions.
4. Select a strategy you prefer.
For example, if you decide to delete the user, mouse over **Delete User** and click **View Remediation**.
1. View the remediation instructions for both **AWS Management Console** and **AWS CLI**.
2. Click **Open in Console** to open the AWS Management Console to perform the actions given in the remediation instructions.
Optionally, you can perform the operations using the AWS CLI.
5. If you want to consolidate and reduce the permissions assigned to the user, click **View Remediation** button next to the **Create a new custom IAM Policy for this User with a subset of only used permissions** option.
Sysdig offers smart policy optimization that excludes permissions used after a user is flagged as **Potentially Compromised**.
1. Review the IAM policies and instructions to create a new IAM policy.
2. Click **Open in Console** to open the AWS Management Console to perform the actions given in the remediation instructions.
6. Return to Sysdig Secure UI and mark the AWS IAM user as **Compromise Resolved**, as given in step 3.
### Remediation Strategies to Contain Compromise
The following are the remediations strategies to address a Compromised AWS user. See the [AWS Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html) for the up-to-date information.
You can use either AWS Management console or the AWS CLI to perform the operations.
#### Deactivate User
##### AWS Management Console
1. Sign in to the AWS and open the [IAM Console](https://console.aws.amazon.com/iam/).
2. On the navigation pane, select **Users**.
3. Choose the user you want to deactivate.
4. Open the **Permissions** tab.
5. Click **Add inline policy**.
6. In the JSON tab, paste the following policy to deny all the actions:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
```
7. Review the policy and click **Create policy**.
##### AWS CLI
1. Open your terminal or the command prompt.
2. Create a JSON file, for example `deny_all_policy.json`, with the following content.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
```
3. Run the following command to attach the policy to the user:
```
aws iam put-user-policy --user-name --policy-name DenyAllPolicy --policy-document file://deny_all_policy.json
```
Replace with the actual username.
#### Delete User
##### AWS Management Console
1. Sign in to the AWS and open the [IAM Console](https://console.aws.amazon.com/iam/).
2. On the navigation pane, select **Users**.
3. Select the user name that you want to delete.
4. At the top of the page, choose **Delete**.
5. In the confirmation dialog box, enter the username in the text input field and confirm the deletion of the user.
6. Click **Delete**.
##### AWS CLI
1. Delete the user password:
```
aws iam delete-login-profile
```
2. Delete the user access keys:
```
aws iam list-access-keys
# list the access keys
aws iam delete-access-key
# delete the access key
```
3. Delete the user signing certificate:
```
aws iam list-signing-certificates
# list the user's signing certificates
aws iam delete-signing-certificate
# delete signing certificate
```
Note that when you delete a security credential, it cannot be retrieved.
4. Delete the user’s SSH public key:
```
aws iam list-ssh-public-keys
# list the user's SSH public keys
aws iam delete-ssh-public-key
# delete SSH public key
```
5. Delete the user’s Git credentials.
```
aws iam list-service-specific-credentials
# list the user's git credentials
aws iam delete-service-specific-credential
```
6. Deactivate the user’s multi-factor authentication (MFA) device, if the user has one.
```
aws iam list-mfa-devices
# list the user's MFA devices
aws iam deactivate-mfa-device
# deactivate the device
aws iam delete-virtual-mfa-device
# permanently delete a virtual MFA device
```
7. Delete the user inline policies.
```
aws iam list-user-policies
# list the inline policies for the user
aws iam delete-user-policy
# delete the policy
```
8. Detach any managed policies that are attached to the user.
```
aws iam list-attached-user-policies
# list the managed policies attached to the user
aws iam detach-user-policy
# detach the policy
```
9. Remove the user from any user groups.
```
aws iam list-groups-for-user
# list the user groups to which the user belongs
aws iam remove-user-from-group
```
10. Delete the user.
```
aws iam delete-user
```
#### Add Restrictive Policy for IP
Create an identity-based policy that denies access to all AWS operations in the account if the request originates from principals outside the specified IP ranges. This policy is useful when the IP addresses of your organization fall within the specified ranges. In this example, access will be denied unless the request comes from the CIDR ranges 192.0.2.0/24 or 203.0.113.0/24.
##### AWS Management Console
1. Sign in to the AWS and open the [IAM Console](https://console.aws.amazon.com/iam/).
2. On the navigation pane, select **Users**.
3. Choose the user you want to deactivate.
4. Select the **Permissions** tab and click **Add inline policy**.
5. In the JSON tab, enter the following policy to deny all actions:
```
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
}
}
}
}
```
6. Review the policy and click **Create policy**.
##### AWS CLI
1. Open the terminal or a command prompt.
2. Create a JSON file, for example `deny_all_source_policy.json`, with the following content:
```
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]
}
}
}
}
```
3. Run the following command to attach the policy to the IAM user:
```
aws iam put-user-policy --user-name --policy-name DenyAllSourcePolicy --policy-document file://deny_all_source_policy.json
```
Replace with the actual username.
#### Force Password Reset
##### AWS Management Console
1. Sign in to the AWS and open the [IAM Console](https://console.aws.amazon.com/iam/).
2. On the navigation pane, select **Users**.
3. Choose the user you want to force password reset.
4. Select the **Security credentials** tab.
5. Click **Manage console access** and select **Reset password**.
6. Select **User must create new password at next sign-in**.
7. Click **Reset password**.
##### AWS CLI
1. Open the terminal or a command prompt.
2. Run the following command to require a password reset:
```
aws iam update-login-profile --user-name --password-reset-required
```
Replace with the actual username.
#### Delete and Create New Access Keys
##### AWS Management Console
1. Sign in to the AWS and open the [IAM Console](https://console.aws.amazon.com/iam/).
2. On the navigation pane, select **Users**.
3. Choose the user you want to force password reset.
4. Select the **Security credentials** tab and locate the **Access keys** section.
5. Select **Delete** from the **Actions** drop-down.
6. Click on **Deactivate**.
7. To confirm deletion, enter the access key ID in the text input field, and select **Delete**.
8. Select the **User must create new password at next sign-in**.
9. Click **Reset password**.
To create a new access key:
1. Click **Create access key**.
2. Click **Download .csv file** or **Show** to save the new access key securely.
Make sure that you store the new access key and secret access key in a secure place, as you will not be able to view the secret access key again.
##### AWS CLI
1. Open your terminal or command prompt.
2. List the current access keys for the user to identify which keys exist:
```
aws iam list-access-keys --user-name
```
Replace `` with the actual username.
3. Delete an existing access key:
```
aws iam delete-access-key --user-name --access-key-id
```
Replace with the actual username and with the ID of the access key you want to delete.
4. Create a new access key:
```
aws iam create-access-key --user-name
```
Replace with the actual username.
## Optimize Azure User Entitlements
You can analyze and address identity risks associated with individual Microsoft Azure accounts and their permissions by using the detailed drawers. Simply click on individual rows on the Users page to open the detailed drawer for further analysis.
## Manage User Entitlements with Detail Drawers
To reduce the entitlements for a particular user, click on the account name to open the detail drawer and sub-tabs.
The Users page organizes everything around the individual user.
* **Summary**: Displays the critical permissions issues detected for this user, sorted by Permission Criticality and Unused Permission Criticality.
* **Remediation Strategies**: Summarizes all potential strategies to reduce the permissions for this user.
If Sysdig has been profiling a user for less than 90 days, you will see the following message:
*We recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions*.
## Understand User Permissions
Hover over the **% Unused Permissions** column to see the permissions granted to a user:
* **Total Permissions**: The total number of permissions granted to a user from all the roles the user is connected to.
* **Unused Permissions**: The total number of unused permissions from all the roles that connected to a user.
## Remediation Strategies
### Detach Role from this User
* All the roles that are totally unused by this user will get this recommendation.
* If there are multiple detach recommendations, they are sorted based on the largest reduction in unused permissions.
### Consolidate Permissions
Create a new custom role for the user with only a subset of used permissions.
This mechanism considers all actions taken by this user across all its roles and consolidates them into one user-specific custom role. There will only be one custom role suggestion per user.
### Reduce Permissions with Existing Roles
Replace the existing role with a different role.
Sysdig recommends replacing a connected role with an existing role that contains all the permissions used by the current role but has fewer total permissions overall.
### Enable No MFA Findings
The **No MFA** finding is not enabled by default for Azure accounts. If you want to capture those findings do the following on your Azure account:
1. Log in to [https://portal.azure.com/](https://portal.azure.com/).
2. Select the appropriate Directory or Tenant.
3. Search for **Enterprise Application**.
4. Click **Enterprise Application** and click **View**.
5. On the **All Applications** page, search for **Sysdig**.
6. Select the application with the name *sysdig-secure-ENV\_NAME*.
7. On the left navigation pane, click **Permissions**.
8. If you do not see **UserAuthenticationMethod.Read.All**, click the **Grant admin consent for** button.
Once you complete these settings, wait for the next scan to display the **No MFA** finding for users that have no MFA set.
## Optimize GCP User Entitlements
You can analyze and address identity risks associated with individual GCP accounts and their permissions by using the detailed drawers. Simply click on individual rows on the Users page to open the detailed drawer for further analysis.
Review the permissions that you can grant to the Sysdig service account by enabling [domain-wide delegation](https://docs.sysdig.com/en/gcp-domain-wide-delegation).
## Guidelines
While you can grant roles to users at the organization, folder, or project level in Google Cloud, the resource collection workflow currently only considers users defined at the project level. This means that only users explicitly specified in the policy bindings document are collected during the scan, evaluated during processing, and displayed on the **Identity** > **Users page**. Policy inheritance is not currently supported.
## Manage User Entitlements with Detail Drawers
To reduce the entitlements for a particular user, click on the account name to open the detail drawer and sub-tabs.
The Users page organizes everything around the individual user.
* **Summary**: Displays the critical permissions issues detected for this user, sorted by Permission Criticality and Unused Permission Criticality.
* **Remediation Strategies**: Summarizes all the potential strategies to reduce the permissions for this user.
* **Connected IAM Resources**: Shows all the IAM resources that are associated with the selected user. Select a resource, such as a role, group, or policy, to take further remediation actions, or view a summary of permission criticality.
If Sysdig has been profiling a user for less than 90 days, you will see the following message:
*We recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions*.
## Understand User Permissions
Hover over the **% Unused Permissions** column to see the permissions granted to a user:
* **Total Permissions**: The total number of permissions granted to a user from all the roles the user is bound to.
* **Unused Permissions**: The total number of unused permissions from all the roles that bound to a user.
## Remediation Strategies
### Detach Role from this User
* All the roles that are totally unused by this user will get this recommendation.
* If there are multiple detach recommendations, they are sorted based on the largest reduction in unused permissions.
### Consolidate Permissions
Create a new custom role for the user with only a subset of used permissions.
This mechanism considers all the actions taken by this user across all its roles and consolidates them into one user-specific custom role. There will only be one custom role suggestion per user.
### Reduce Permissions with Existing Roles
Replace the existing role with a different role.
Sysdig recommends replacing a bound role with an existing role that contains all the permissions used by the current role but has fewer total permissions overall.