Boosting security with Okta Identity Threat Protection and Workflows

Below are three examples of triggering workflows from events in the Okta system log and covering different use cases.

1. A user risk level change triggers a ticket in ServiceNow and assignment to a high-risk group in Okta.
2. When a user is assigned to a high-risk application, a workflow checks the user's risk and allows or rolls back the new access.
3. When a user is assigned to a high-risk application, a workflow checks the user's risk and allows or triggers a User Access Review in Okta Identity Governance.

1. Logging a ServiceNow ticket and assigning a user to a high-risk group

In this example, we use an event hook subscribed to user.risk.detect events to fire a workflow. In this scenario, we notify our security team about the event in Slack with useful details and email the manager of the user whose risk level changed.

In cases where a user's risk level is HIGH, we also create a ServiceNow incident, add the user to a high-risk group in Okta, enrich our notification with a link to the ServiceNow incident, and indicate that the user has been added to the group. When the user's risk level lowers, they are removed from the high-risk group.

The workflow will:

• Be triggered by the user.risk.detect event in the Okta system log. We'll use an event hook pointed at an API Endpoint flow. (See Processing Okta Event Hooks with Workflows for more information.)
• Parse the event details
• Read the user by ID to return information from their profile and generate a link to a system log query related to the event
• Determine the user's risk level:
  • If it is now "HIGH"
    • Create a ServiceNow incident
    • Add the user to a high-risk Okta group
    • Email the user's manager
    • Enrich chat notifications with context about the above actions
  • If it has decreased from "HIGH":
    • Remove the user from the high-risk Okta group
    • Enrich chat notifications with context about the above actions
• Send notifications on all user.risk.detect events:
  • Slack (or Teams) message to a security channel for all user.risk.detect events
• Add information about group addition/removal and link to ServiceNow incident when applicable.

Let's walk through the flow. First, we parse out the payload from the user.risk.detect event and assign some values we'll use later in our flow. We then close out the connection to the event hook with a 200 status code.

Next, we'll call some helper flows. One will help us further parse out the debugData.risk event to get the current and previous risk levels. The other will retrieve some profile information about the user whose risk level has elevated and build a link to a system log query about the event.

If the user's risk is now "HIGH," we'll

• Add them to the high-risk Okta group
• Send an email to the user's manager
• Create an incident in ServiceNow
• Customize our Slack notification sent with every risk level change to inform our team that the user was added to the group and include a link to the ServiceNow incident. The message will also indicate if the ServiceNow "Create Incident" action fails.

Finally, we'll take the messages dynamically built up, indicating

• The user has been added or removed from the high-risk Okta group
• ServiceNow incident and link (or link to investigate if incident creation failed)

We'll combine those with the rest of the risk event details we send by default with every user.risk.detect event, and send our notification.

Implementing a flow like this leverages the power of Workflows and Okta Identity Threat Protection to give your team continuous real-time visibility into risk signals detected in your Okta tenant. It allows you to integrate different platforms you use to send notifications, create tickets, and automate responses, like quarantining the user in a high-risk group or triggering an incident with an SLA for response in another platform. The "High Risk" Okta group could be subject to strict policies that limit a user's access until your team has had a chance to investigate. Adding users to the group could trigger other flows, or you could even have stricter policies within Identity Threat Protection that apply to the group.