Boosting security with Okta Identity Threat Protection and Workflows

As cyberthreats grow in complexity and frequency, the need for robust identity security has never been more critical. Identity-based attacks, such as compromised credentials and unauthorized access, pose significant risks to organizations. Protecting against these threats requires a proactive and intelligent approach that detects and responds to suspicious activities and integrates seamlessly with existing security measures.

Enter Okta Identity Threat Protection with Okta AI, a cutting-edge solution designed to fortify your organization’s identity security. Combining the power of artificial intelligence (AI) with comprehensive identity protection, Okta Identity Threat Protection offers real-time, continuous threat detection and response capabilities tailored to address the unique challenges of modern cybersecurity.

One of the most powerful features of Okta Identity Threat Protection with Okta AI is its integration with Okta Workflows. These workflows serve to create automation and enable your security infrastructure to respond dynamically and effectively to threats. With customizable, policy-driven actions, Okta Workflows can be used to deactivate or quarantine compromised accounts, enforce multi-factor authentication (MFA) for high-risk activities, and alert security teams to potential breaches — helping make  your defenses active and responsive.

Let’s explore how Okta Identity Threat Protection with Okta AI and Okta Workflows, our low-code automation platform, can help you better meet your security and business goals.

Bespoke automation for Okta Identity Threat Protection

Below is a simplified view of Okta Identity Threat Protection with Okta AI. Signals and events from both Okta and partners are constantly fed into Okta, and the Identity Threat Protection risk engine determines risks and executes associated policies.

These policies can trigger corrective actions, such as performing Universal Logout or calling a delegated flow in Okta Workflows. In this article, we will call these policy-initiated workflows.

Risk evaluation may also trigger actions within Okta, such as increasing the user risk level (called the entity risk level). A user risk level change is just one of many events related to Identity Threat Protection that will be written to Okta system logs, along with things like re-evaluation of policies, session context changes, receiving a risk signal from a third-party vendor, and much more. Almost any activity within Okta is logged in the system log. It is common to trigger workflows from eligible events using event hooks or the built-in Okta connector within Workflows. In this article, we will call these event-initiated workflows.

Policy-initiated workflows

From the product documentation: When Identity Threat Protection with Okta AI uncovers a risk and the remediation event requires additional actions beyond universal sign-out, you can automatically run a delegated workflow.

The third-party apps and services provided through Okta Workflows connectors offer numerous possible remediation actions.

• Notify users or administrators through Slack or email
• Deactivate a user
• Remove a user from a privileged group
• Move a user to a new restricted group
• Quarantine a device
• Submit an incident ticket to a queue
• Configure different flows for different risk scenarios based on your requirements

In addition, you can use the Custom API Action cards included in nearly all connectors to create custom actions that can interface with any third-party API endpoints.

Okta Identity Threat Protection documentation illustrates several Workflow examples that could be initiated from specific policies, such as:

• Send a Slack message to indicate a policy violation
• Clear user sessions and send an email notification to reduce the risk 
• Remove the user from all memberships and deactivate their account

Thus, policy-initiated workflows are useful for automation tied to specific risks generated by Identity Threat Protection, as workflows are tied to specific policies. If you want to drive automation based on more generic situations, such as a user risk level change,  then event-initiated workflows are more appropriate.

Event-initiated workflows

Events appearing in the Okta system log can also initiate workflows. While specific events are related to Identity Threat Protection, you might want to leverage other events in Okta, such as those relating to devices, applications, group membership, and more. Perhaps you want to check a user's risk level before they can be unsuspended, before allowing a device to register, or when the user is assigned to an application.

There are two mechanisms to trigger a workflow from an event in the system log:

1. The Okta connector comes pre-built with a large number of events; you just click on the event to add it to the start of a workflow
2. Event hooks in Okta can call workflows built with an API endpoint that triggers the flow; an event hook is created for a specific event type, which calls the API and passes the event details

When building event-initiated workflows, using the Okta Connector events is simpler, but you can use the API endpoint if the Okta Connector doesn’t support the event you need.

There are examples of policy-initiated workflows in the documentation, so the following sections will look at some event-initiated examples.

Event-initiated workflow examples

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. 

2. Checking user risk on high-risk application assignment

In this example, we have a high-risk application in Okta (such as the PAM product, Okta Advanced Server Access), and when a user is assigned to this application, we want to check the user risk level. If the user has a Low risk level, app access is allowed. Access is allowed if the risk is Medium, but a Slack message is written to highlight this. If the risk is High, the application access is rolled back.

The workflow will:

• Be triggered by the application.user_membership.add event in the Okta system log. This is a standard event built into the Okta Workflows connector
• Look up the user by ID to get details in case a Slack message is required
• Determine user risk. In this case, it is doing a lookup of the user's groups to see if they are in a High or Medium risk group, then
  • If the user risk is Low, it allows the app access (i.e., it does nothing)
  • If the user risk is Medium, it allows the app access but formats and sends a Slack message to the admin team
  • If the user risk is High, it removes the user assignment to the application.

Let's walk through the flow. First, we have an event to indicate that a user, John Smith, has been added to the Okta Advanced Server Access app.

It looks up John’s details and the groups he belongs to so as to determine his risk.

If John is medium risk, and is thus in the corresponding Medium risk group (assigned by Workflows when his risk changed to Medium from some Identity Threat Protection event), a message will be written to Slack.

If John is high risk and in the corresponding high-risk group, his assignment will be reverted by using another Okta action.
 

This can be seen in the Okta system log events for the application (or user).

This is a fairly simple — and very powerful — example of using user risk to manage application risk.

3. Checking user risk on high-risk application assignment with user access review

Next, we will extend the previous scenario. Rather than automatically revoking access when a high-risk user is given access to a high-risk application, we will now raise a User Access Review in Okta Identity Governance.

The flow is basically the same as before, but rather than removing app access in the last step, the workflow will create and launch a user access review (access certification) using the Campaigns API in Okta Identity Governance and the Custom API action card on the Okta Connector (the details are buried in a helper flow).

As before, when the user is assigned to the app, the user risk level (High) routes the workflow to a helper flow that builds the relative URL and requestBody needed to create and launch the Access Certification campaign.

This is assigned to the user's manager to review, and when the manager logs into Okta, they see there is a campaign to review.

On checking the details, they see all applications assigned to John Smith.

They review the access, decide John doesn’t need the Okta Advanced Server Access app, and click the Revoke button.

This causes the removal of the application as shown in the system log events.

This approach provides more flexibility. Users might have a legitimate reason to access a high-risk application, so having a user access review by their manager is an audit-friendly way to manage it (of course, you could apply Access Request flows, but that’s a conversation for another article).

Staying ahead of the threat landscape

By leveraging these Okta capabilities, you can achieve higher security and operational efficiency, aligning your security protocols with your business goals. Whether enforcing MFA for suspicious activities, deactivating or quarantining compromised accounts, or notifying security teams of potential breaches, Okta Identity Threat Protection and Workflows enable your organization to remain resilient against identity-based attacks.

As we navigate the complexities of modern cybersecurity, Okta Identity Threat Protection with Okta AI stands out as a critical tool in your security arsenal. It better protects your organization and enhances your ability to respond to threats swiftly and effectively. By integrating these services, you are not just keeping up with the evolving threat landscape — you are staying ahead of it.

Embrace the future of identity security with Okta and enable your organization to handle today's and tomorrow's challenges. With Okta Identity Threat Protection and Okta Workflows, you can better secure your digital landscape, help protect your valuable assets, and confidently pursue your business objectives.

Learn more about Okta Identity Threat Protection with Okta AI and Okta Workflows.

These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice.