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:
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.
Under the Actions button there are a few additional actions that are neither remediation actions nor triage actions. Those actions are:
All of the triage and remediation actions listed in this article are available to both full admin users and also help desk role users.
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:
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. We highly recommend NOT ignoring users from checks indefinitely whenever possible and would instead recommend setting up a longer exclusion timeframe.
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 for record keeping purposes
If needed, a user can be re-included in a Check by selecting Include in Check under the 3-dot menu in the Resolved Checks section.
These triage actions are available under the 3-dot menu in two places
As mentioned above, when using either Mark as Suspicious or Mark as Normal, the given user's observation(s) that was triaged is then "snoozed" for 30 days. As Identity Intelligence continuously analyzes user data, if a new observation is noted for the same user with the same context as the "snoozed" observation, then it will NOT log a new observation and will not trigger a check failure for that user; however, if a new observation is noted for the same user with different context than the "snoozed" observation, then it WILL log a new observation and will trigger a check failure for that user.
Context is usually information that can be found in the failing check's explainability, such as IP address info, device info, factor info, etc and will vary by check based on what is relevant to that check. For example, for the Personal VPN Usage check, the context is the VPN service used. For the Rare Browser Activity check, it is the browser user, etc.
If needed, feedback options can be reset by selecting Reset Feedback under the 3-dot menu in the Resolved Checks section for a given user.
Exclude from Check should be used in cases where you are certain a user does not need to be evaluated against this check for a desired amount of time under ANY circumstances
Mark as suspicious 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).
Note - All roles, including Read Only, can provide triage user check failures with these options.
Additionally, when you triage a check failure or observation using mark as suspicious or mark as normal behavior, you help the Identity Intelligence data science team gather data on ways to improve the check failure logic moving forward.
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".
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
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 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.
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.
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.
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
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 the desired platform (if more than one is connected) and click Confirm.
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.
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.
Supported IDPs: Okta, Azure AD, Google, Duo, Salesforce
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.
Triage Actions are accessed through check failures - either on the page of failing users for a given check or on the tab. You may notice that not all checks contain all the triage actions listed above. That is because cannot be marked as suspicious/normal.
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 section below.
Another action available, outside of the Actions button, is Update User Type. This action also requires which you can read more about below.
Actions reserved for full administrators, such as changing tenant settings, checks settings, or integration configuration, are discussed in the .
For both 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 the user has been excluded, this particular check will move to the 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.
For 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 suspicious or Mark as normal behavior buttons so that they are no longer failing a given check. It is recommended to leave a brief comment with the triage result of your investigation for record keeping and historical purposes.
Marking a user's check failure or observation as either suspicious or normal behavior will mitigate the failed check/observation for that user and move it to the section of the given user's User 360 Checks tab and will not alert on observations with the same context for the next 30 days.
the table of failing users on a given
a given user's tab
Marking a user as suspicious or interesting from a given Failing check page will apply that feedback to ALL observations for the given user; however, on the tab you can review each individual observation and mark each accordingly. This is important because if a user has multiple observations, each with different context, the observations should be reviewed individually and triaged appropriately via the User 360 Checks tab, otherwise you may miss future check failures for a user.
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 .
Click the Actions button on any tab within a selected user's and then select Send push notification
These actions will also show up as events in the user's tab
Click on the desired guest user to open their User360 tab
You can do this in Identity Intelligence via the Reset MFA action under the Actions button on any tab of a given user's .
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 .
The status will be displayed in the remediation status bar in the tab of the user360 for the selected user.
Via integrations with and , 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 and select the Open Ticket action to pen a ticket for that user
Select Open ticket for check, which can be found under the 3-dot button on either the or on the list of users failing a given check, to open a ticket
Any tickets opened via Identity Intelligence and their status will be visible at the bottom of the .
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. , which includes information on when, why and how to use it.
If there are any issues with the remediation action, you can see the details in the page under the tenant options menu in the top right corner.
For most IDP connections, Identity Intelligence will pull changes to static user account information and activity once every 24 hours. (Note: If or event streaming are enabled, the events in the Activity tab will be processed and visible more frequently)
Because of a limitation on the Microsoft side, Identity Intelligence typically gets users' on a monthly cycle. Use the Refresh User Data action to pull the current factor info for a given user if needed
