🛠️Triaging Alerts and Remediation Actions

11/2023

Overview

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:

Triage Actions vs Remediation Actions

Triage Actions

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 suspicious/normal.

No additional permissions or set up are required to utilize the Triage Actions.

Remediation 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.

Other Actions

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.

RBAC Role Permissions

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.

Technical Requirements

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:

Triage Actions

Exclude User from Check

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

  1. Use the 3-dot menu at the end of the corresponding row and click Exclude from check.

  2. 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.

  1. 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

  2. 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.

Mark as Suspicious / Mark as Normal Behavior

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 suspicious or Mark as normal behavior buttons so that they are no longer failing a given check. 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 Resolved 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.

These triage actions are available under the 3-dot menu in two places

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 User 360 Checks 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.

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.

When to use each triage action

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.

Remediation Actions

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

Send Push Notification

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.

Okta Implementation Details

Specifically, the Okta service account for Identity Intelligence needs to have Help Desk Administrator role or a higher role.

Duo Implementation Details

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".

How to Send a Push Notification

  1. Click the Actions button on any tab within a selected user's User360 and then select Send push notification

  2. 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

  1. Click Confirm to send the push notification

  2. A Remediation status bar will appear above the User Overview page

  3. The API operation is asynchronous, so you may need to hit the refresh button within the remediation status bar to update the status

  4. If the user receives and accepts the push, the status will be SUCCESS. Otherwise it will report FAILURE

  5. 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).

Delete Guest User

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 -

  1. The account must be of type guest in Azure AD

  2. 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:

  1. Click on the desired guest user to open their User360 Overview tab

  2. Click Actions -> Delete User

  3. A Remediation status bar will be displayed with the status of the operation in Azure AD

  4. 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.

Reset MFA

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.

Log User Out of Active Sessions

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.

Quarantine 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:

  1. 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

  2. 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:

    1. The user's account may be compromised, so the Quarantine group allows them to only access the user help desk portal and nothing else

    2. 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

Additional Actions

Open Ticket

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.

Open a ticket for a specific user:

  1. 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

  2. Enter a Subject and click Confirm to open the ticket in your Ticketing System. Specify if it is a general issue or a request

Open a ticket for a specific check failure for a specific user:

  1. 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

  1. 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.

Link User

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.

Update User Type

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.

  1. To do so, click Assign

  1. Type in your desired value and click Save Changes

  1. 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.

Refresh User Data

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

PreviousChecks TabNextLinking User Accounts

Last updated