How to Detect and Remediate Okta Impossible Traveler Alerts

Okta is a leading identity management platform that helps companies define and authenticate a user’s identity across applications. Because of this role, activity in the Okta logs can be an early indicator of a cyberattack.

One common type of suspect activity is called “impossible traveler”. This means that a login attempt has been performed from two distant locations in a short time range.

In this guide, we’ll explain how to detect these “impossible traveler” security alerts and the steps you need to take to respond. We’ll also explain how using an automation  platform like Blink can make this workflow easier by facilitating interactive steps.

Configuring “Impossible Traveler” Events in Okta

Out-of-the-box, Okta doesn’t track or send “impossible travel” events automatically.

You will first need to go to the Okta Admin Console and navigate to Security → Behavior Detection to define a behavior for “impossible traveler”.

The Velocity behavior type checks against the geographic distance and time elapsed between sign-in attempts. By default, it assumes a top travel average speed of 500 mph.

To add a velocity behavior, you can click “Add Behavior” and select “Velocity” from the dropdown. Enter “impossible traveler” as the behavior name and specify a velocity in kilometers per hour that is impossible relative to the prior sign-in location, and hit Save.

Next you can add this new velocity behavior to a sign-on policy rule.

Responding to “Impossible Traveler” Events

1. Detect the “impossible traveler” event from Okta logs

When the “impossible traveler” behavior is detected, it will be recorded in System Log events under DebugContext and DebugData.

If the behavior has a POSITIVE value, then it means that behavior was present for the sign-in activity. Depending on your sign-in policy, a sign-in with the “impossible traveler” behavior would be blocked or directed to MFA.

You can set up custom notifications for sign-in events with the “impossible traveler” behavior through webhooks, 3rd party tools, or the Okta Workflows add-on.

2. Create an incident on the required systems.

When you receive a notification about an impossible traveler event, the next step is to create an incident in your organization’s ticketing tool of choice. ServiceNow and Jira are common vendors for this.

This step is important so you have a clear, shareable record of the event that you can update as you investigate. It also contributes to an audit trail so you can generate aggregated reports on these sign-in security events.

3. Ask the user whether they performed the login.

Next, whoever is responding to the alert needs to reach out to the user to validate whether they were the one who attempted to log in. In practice, this means drafting a message and sending it to the person over Slack, Teams, or email. 

4. If they say yes, offer the SOC admin to close the incident.

If the end user validates that they were the one who attempted the sign-in, then you can update the ticket with that context and close the incident. You may need to review your sign-in policies to see why the behavior was detected.

5. If they say no, increase the alert criticality and suspend the Okta user.

If the end user responds that the sign-in was not them, then the risk that it is a malicious attempt is higher. You can then suspend the user by navigating to their name in the Okta console and update the ticket. Next, you can gather more information to investigate further.

To recap, this is the response workflow:

Automating “Impossible Traveler” Detection and Response with Blink

While the workflow for detecting and handling these events is pretty simple, it can be difficult to streamline. Setting up and managing custom alert notifications on your own can be tedious, and automating the response steps is difficult because there’s a different action to take depending on the end users feedback of if the sign-in was really theirs.

With Blink, you can easily set up event-based notifications across your tools that kickoff automated workflows. 

For example, this automation detects Okta impossible traveler events, sends an email or Slack message to the SOC, and opens an incident ticket in ServiceNow.

This automation is triggered whenever an Okta user starts a new session, and it executes the following steps:

1. Gets the locations from the logs for the last three logins.
2. If logins are from different countries, sends a message of a suspicious login to a Slack channel.
3. Logs a security event in your ticketing system.

When someone is ready to handle this alert, they can run a remediation automation that sends a message to the related end user and asks them to either confirm or deny whether that sign-in event was really theirs.

This is an automation triggered by an “usual login location” webhook in Okta. It executes the following steps:

1. Sends a Slack message to the user to ask them to validate if the login was actually their activity or not.
2. If the user responds that the login activity was not theirs, it will automatically lock the user in Okta.
3. Next, the automation sends a Slack message to an Okta admin asking whether to approve the logins and unlock the user’s account.
4. Lastly, it will update a Jira ticket with the responses and context from each step.

You can either run these steps or automations separately, or combine them to create one automation for the full process.

With these automations, you can quickly get validation from team members via Slack and take suspension actions quickly to mitigate risk.

If you want to create new conditional workflows or notifications, it’s as easy as entering your request as a prompt into Blink Copilot. A no-code workflow will be generated in seconds and can be easily customized.

There are also over 7K pre-built automations in the Blink library that solve common security tasks like this one across your hundreds of tools.

Get started with Blink today to see how easy automation can be.