🛠️Triaging Alerts and Remediation Actions
11/2023
Last updated
11/2023
Last updated
Cisco Identity Intelligence provides the ability to triage check failures and take action to remediate problems or identity security threats within your connected identity platforms, such as Okta, Azure, Google, or Duo.
This article provides an overview of each triage option and remediation action, its intended use cases, how to use it, and platform compatibility.
For more information, please see this short video:
Check failures can be triaged so that a given user will no longer fail a given check. Once a failing user has been triaged, they will no longer appear in the list of failing users for a given check.
The triage actions available are:
Triage Actions are accessed through check failures - either on the page of failing users for a given check or on the User 360 Checks tab. You may notice that not all checks contain all the triage actions listed above. That is because State based checks cannot be marked as interesting/normal.
No additional permissions or set up are required to utilize the Triage Actions.
Remediation actions are available for a wide variety of scenarios. Most remediation actions are typically utilized once an investigation into a given user's behavior has concluded to protect a user's account if it has been, or is suspected to be, compromised or is under attack. However, there are other remediation actions available that can be used to clean up an environment, to track an investigation, validate a user's identity, etc.
The remediation actions available are:
Remediation Actions can be found under the Action button, which is available across all tabs of a given user's User 360.
Additional permissions or set up are required to utilize all Remediation Actions. More information on what is needed for each data source can be found in the Technical Requirements section below.
Under the Actions button there are a few additional actions that are neither remediation actions nor triage actions. Those actions are:
Another action available, outside of the Actions button, is Update User Type. This action also requires additional permissions which you can read more about below.
All of the triage and remediation actions listed in this article are available to both full admin users and also help desk role users.
Actions reserved for full administrators, such as changing tenant settings, checks settings, or integration configuration, are discussed in the RBAC and Access Logs article.
To take Remediation Actions beyond simply read-only data collection in identity platforms, Identity Intelligence requires specific API or token write permissions/scopes within the data source platforms so that it can talk back to the source and execute the remediation action there.
The specific API or token permissions are outlined in the integration guide for the respective data source. Please see the following articles for more details:
For both event-based and state-based Checks, you can exclude a given user from that particular check. Excluding a user from a check can be customized to exclude for a specific timeframe, or made permanent with an indefinite timeframe.
Once you have identified a user to exclude from a particular check
Use the 3-dot menu at the end of the corresponding row and click Exclude from check.
Select the desired timeframe from the drop down - either Indefinitely, which will result in a permanent exclusion, or one of the default timeframes. If your desired timeframe is not available, you can use the Custom option in the drop down to set your own timeframe, up to 180 days.
Include a Reason for why this user will be excluded for this timeframe so that you and/or other members of the team can refer back to this historical context if needed. While entering a Reason is not required, it is highly recommended.
Once the user has been excluded, this particular check will move to the Resolved Checks section of the given user's User 360 Checks tab, with Result as Excluded. It will also include information on who excluded the user and display the Reason, if one was provided.
If needed, a user can be re-included in a Check by selecting Include in Check under 3-dot menu in the Resolved Checks section.
For event-based identity threat detections, after you have investigated a check failure, you should then triage the failed check or observation for that user with the Mark as interesting or Mark as normal behavior buttons so that they are no longer failing the check. These triage actions are available under the 3-dot menu of the failed check finding.
Mark as interesting should be used in cases where a check failure was accurate in some way such as behavior that could risky or concerning, a possible compromise, a confirmed compromise. etc.
Mark as normal behavior should be used in cases where a check failure was accurate but is expected behavior or is simply not risky or concerning behavior, or if the check failure was not accurate (false positive).
Marking a user's check failure or observation as either interesting or normal behavior will mitigate the failed check for that occurrence for that user and move it to the Resolved section of the given user's User 360 Checks tab. Additionally, when you triage a check failure or observation, you help the Identity Intelligence data science team gather data on ways to improve the check failure logic moving forward.
Note - All roles, including Read Only, can provide triage user check failures with these options.
You may not see all Remediation Actions available across all users in your tenant! Identity Intelligence only shows the remediation actions that are compatible with the data sources that have a record for a given user For ex: You have a given user with accounts in both Azure and Duo. You will not see the Quarantine action for this user, since this action is only compatible with Okta and this user does not have an Okta account
Supported platforms: Duo Security for end users only, Okta
In certain scenarios, such as verifying a user's identity when calling into the help desk or support team, it is extremely useful to be able to send the user a one-time push notification to their enrolled mobile device and have them confirm it as part of the identity verification process.
Specifically, the Okta service account for Identity Intelligence needs to have Help Desk Administrator role or a higher role.
The Send Push Notification action only works on Duo end users. It is not compatible with Duo Admin accounts.
To enable this functionality for Duo, requires the Duo Security Auth API security token to be configured in your Duo integration as mentioned in the Duo Security Integration article. As mentioned there, the Duo Auth API app name should be created with something the end user will recognize as having sent the push to them, such as "Company ABC IT Support Team".
Click the Actions button on any tab within a selected user's User360 and then select Send push notification
A verification dialog box will open. If there are both Duo Security and Okta integrations in your Identity Intelligence tenant, you'll be asked to select which one you want to use
Note - If a user has multiple devices enrolled for an integration, you will be given a choice to select the desired device. If a user has NO devices for an integration, you will see the message below
Click Confirm to send the push notification
A Remediation status bar will appear above the User Overview page
The API operation is asynchronous, so you may need to hit the refresh button within the remediation status bar to update the status
If the user receives and accepts the push, the status will be SUCCESS. Otherwise it will report FAILURE
These actions will also show up as events in the user's Activity tab
NOTE! - Because the push notification is sent from Identity Intelligence to the Identity provider via API and originates from a specific AWS region, then the geolocation details in the request will show it coming from an AWS region (AWS US East 2 in Columbus, Ohio for most Identity Intelligence customers).
Supported IDP: Azure AD
Microsoft 365 productivity applications like Teams, SharePoint, and OneDrive provide powerful mechanism for sharing resources, data, and chat functions outside of an organizations internal user base. However, this frequently leads to a build-up of guest accounts, especially ones that are inactive or never used, in Azure AD, which functions as the primary identity directory for many Microsoft 365 environments.
With the correct API permissions noted above, Identity Intelligence admin and help desk roles can delete these accounts directly from Identity Intelligence, cleaning up the environment and reducing identity attack surface, while reducing the need to pivot back to Azure to complete this task once a user has been identified for deletion.
There are two requirements -
The account must be of type guest in Azure AD
The account must be within the configured Protected Population within Identity Intelligence (not excluded from all Checks)
To identify delete guest accounts for deletion, you can use the Users table page and the filters to find external users. Some ways you can find external users are:
Filter on User Type only and select External
Filter on failing checks > Select the Inactive Guest User check and select an individual user to review
Filter on failing checks > Select the Never Logged In check > Find the User Type filter and select External and select an individual user to review
Once you have identified a user to delete:
Click on the desired guest user to open their User360 Overview tab
Click Actions -> Delete User
A Remediation status bar will be displayed with the status of the operation in Azure AD
If you delete a user and the status bar displays a Failed message, it may be an indicator that the necessary API permissions are not configured
If you do not see the Delete User remediation action, ensure that the user is a Guest user in Azure AD. If the user is not, this remediation action will not be visible.
Supported IDPs: Okta, Azure AD, Duo, Google
In certain scenarios, such as a lost phone or OTP soft token, you may need to reset a user's MFA factors in one or more IDP systems.
You can do this in Identity Intelligence via the Reset MFA action under the Actions button on any tab of a given user's User360.
Select Reset MFA. This will prompt you to confirm this action. Once you select Confirm, the reset is effective across ALL connected IDPs for the user. Note - The Reset MFA action only works on Duo end users. It is not compatible with Duo Admin accounts.
Supported IDPs: Okta, Azure AD, Google
In the event of a identity security threat, you may need to log a user out of any active sessions in one or more IDP systems.
You can do this in Identity Intelligence via the Log Out User action under the Actions button on any tab of a given user's User360.
As with other options, this remediation action will be effective on all platforms where a given user has an account. You will be prompted to confirm the action before it executes.
The status will be displayed in the remediation status bar in the Overview tab of the user360 for the selected user.
Supported IDPs: Okta
If suspicious or potentially malicious events have occurred with a user's account, you may want to place the account into a quarantine group within the IDP that severely restricts their access to data and applications until further investigation or incident response procedures can be performed.
To use this option, the following steps must be taken:
A group called Quarantine must exist in the primary IDP, Okta, for the user account. If a different group name is required, please coordinate with your Identity Intelligence technical representative
The group must be associated with polices and rules that take precedence over normal auth policies and restrict the user from accessing applications and data. Several use cases for this exist:
The user's account may be compromised, so the Quarantine group allows them to only access the user help desk portal and nothing else
The user has failed some other security policy or training, and so the account can only access the security training application until the issue is remediated
Under the Actions button for a given user, the Quarantine option will perform this action for the connected IDP(s).
Note - Once a user has been placed in the Quarantine group, they can only be removed from the Quarantine group through the IdP Platform, e.g. Okta
Supported platforms: ServiceNOW, Jira
Via integrations with ServiceNOW and Jira, Identity Intelligence is able to open tickets in those platforms in several scenarios. A ticketing service integration must be configured to use this action.
Click the Actions button on the top right of any tab of the given user's User 360 and select the Open Ticket action to pen a ticket for that user
Enter a Subject and click Confirm to open the ticket in your Ticketing System. Specify if it is a general issue or a request
Select Open ticket for check, which can be found under the 3-dot button on either the User360 Checks tab or on the list of users failing a given check, to open a ticket
Select the desired platform (if more than one is connected) and click Confirm.
Any tickets opened via Identity Intelligence and their status will be visible at the bottom of the User360 Overview tab.
Many scenarios exist where the same human user has access to multiple discrete users accounts, either within the same IDP or across different IDPs. In these cases, we recommend creating a link between these users to make account clean up and investigations easier and faster.
Under the Actions button on a given user's User360, there is an option to Link User. There are also other ways to link users. Click here to see our documentation about the Linked Users functionality, which includes information on when, why and how to use it.
Supported IDPs: Okta, Azure AD
Several primary IDP types provide an attribute of User Type, but this user account attribute may not be populated or properly sync'd with a source of truth, such as an HR system.
In this case, an admin or help desk role may want to manually set the user type attribute in the IDP from the Identity Intelligence console. This is especially true if the account is a service account or a 3rd party/external user, such as a contractor or consultant.
To do so, click Assign
Type in your desired value and click Save Changes
At the top of the User Overview page, you will see a Status bar noting that the action has been triggered. When complete, the status will update.
If there are any issues with the remediation action, you can see the details in the System Logs page under the tenant options menu in the top right corner.
Supported IDPs: Okta, Azure AD, Google, Duo, Salesforce
For most IDP connections, Identity Intelligence will pull changes to static user account information and activity once every 24 hours. (Note: If Okta or Azure AD event streaming are enabled, the events in the Activity tab will be processed and visible more frequently)
You can see the most recent full data collection for a user in the Activity tab by hovering over the Last data collection link in the middle right side, about the events table.
To obtain the latest data set for an individual user across all connected platforms, click Actions -> Refresh User Data
The status will be available in a bar at the top of the User Overview tab.
Because of a limitation on the Microsoft side, Identity Intelligence typically gets users' configured factor information on a monthly cycle. Use the Refresh User Data action to pull the current factor info for a given user if needed
To enable this functionality for Okta integrations, the Okta service account used to generate the API token in use by Identity Intelligence needs to be configured with the Okta Roles outlined in .
