🛠️Remediation Actions

11/2023

Overview

Oort provides the ability to take actions 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 action, its intended use cases, and platform compatibility.

For more information, please see this short video -

Technical Requirements

To take actions beyond simply read-only data collection in identity platforms, Oort requires specific API or token write permissions or scopes within the platforms.

The specific API or token permissions are outlined in the integration guide for the respective IDP. Please see the following articles for more details -

• Azure AD

• Okta

• Duo

• Google

RBAC Role Permissions

All of the 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.

Actions

Send Push Notification

Supported platforms: Duo Security, 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

To enable this functionality for Okta integrations, the Okta service account used to generate the API token in use by Oort needs to be configured with the Okta Roles outlined in Remediation Actions & Read-write Okta Setup Steps.

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

Duo Implementation Details

Note - this functionality requires the Duo Security Auth API security token configuration 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".

Push Notification Workflow

1. Click the Actions button on the User360 page and then Send push notification.
2. A verification dialog box will open. If there are both Duo Security and Okta integrations in your Oort 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.
3. Click Confirm to send the push notification.

4. A Remediation status bar will appear above the User Overview page.
5. The API operation is asynchronous, so you may need to hit the refresh button to check the status.
6. If the user receives and accepts the push, the status will be SUCCESS, otherwise it will report FAILURE.

7. These actions will also show up as events in the user's Activity tab.

NOTE! - Because the push notification is sent from Oort 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 Oort customers).

Exclude User from Check

For both event-based threats and security posture Checks, you can exclude a user from that particular check. This exclusion can be Indefinite or for a specific period of time.

1. Use the 3-dot menu and click Exclude from check.
2. The pick the timeline, either Indefinitely or a desired amount of time, including a Custom time period, up to 180 days.
3. Optionally, include a Reason

4. The particular check will be moved to the Resolved Checks section with Result as Excluded.

If necessary, the user can be re-included in that Check using the 3-dot menu in the Resolved Checks section.

Mark as Interesting / Mark as Normal Behavior

For event-based identity threat detections, Oort users can remediate a failed check or observation using the Mark as interesting or Mark as normal behavior buttons available in the 3-dot menu of the failed check finding.

Marking a check as interesting or normal behavior will remediate the failed check for that occurrence and move it to the Mitigated section of the Users -> Checks tab.

Note - All roles, including Read Only, can provide feedback and mitigate checks using these options.

Delete Inactive 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 inactive or never used guest accounts in Azure AD, which functions as the primary identity directory for many Microsoft 365 environments.

With the correct API permissions noted above, Oort admin and help desk roles can delete these accounts directly from Oort, cleaning up the environment and reducing identity attack surface.

There are three requirements -

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

2. The account must be within the configured Protected Population within Oort (not excluded from all Checks)

3. The account must be failing the Inactive Guest Users check, which by default is set to 30 days of inactivity

To delete one of these accounts, navigate to the User360 page for it from

1. Go to the list of users failing the Inactive Guest Users check

2. Click on the guest user you would like to delete
3. Click Actions -> Delete User
4. A status bar will be displayed with the status of the operation in Azure AD

Refresh User Data

Supported IDPs: Okta, Azure AD, Google, Duo, Salesforce

For most IDP connections, Oort will pull changes to static user account information and also activity once every 24 hrs. Note that in the case that 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.

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 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 Oort 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 and type in the desired value. Then 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.

Open Ticket

Supported platforms: ServiceNOW, Jira

Via our integrations with ServiceNOW and Jira, Oort is able to open tickets in those platforms in several scenarios:

1. Open a ticket for a user and specify a general issue or request from the User Actions -> Open Ticket menu in the top right of the Users page. Enter a Subject and click Confirm to open the ticket.
2. Opening a ticket from the Failed Checks tab of the User page and select a specific check to open the ticket. Simply select the desired platform (if more than one are connected) and click Confirm.
3. In both these cases, the tickets opened by Oort and their status will be visible at the bottom of the Users Overview tab.

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 Oort via the top-level Actions menu on the User page.

After clicking Reset MFA, you will be prompted to confirm your action. At this time, the reset is effective across ALL connected IDPs for the user.

Log User Out of Active Sessions

Supported IDPs: Okta, Azure AD, Google

In the event of a identity security thread, you may need to log a user out of any active sessions in one or more IDP systems.

You can do this in Oort via Log Out User option in the top-level Actions menu on the User page.

As with other options, this will be effective on all platforms where the user has an account, and you will be prompted to confirm the action.

Status will be displayed in the remediation status bar in the Overview page for the 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 for the user account, in this case Okta. If a different group name is required, please coordinate with your Oort 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

Within the Oort Actions menu for a User, the Quarantine option will perform this action for connected IDPs.

Note that after being placed in this group, a user must be removed from the Quarantine group using the IDP platform, e.g. Okta.