<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D50Z00008G7Vh7SAFOkta Classic EngineMulti-Factor AuthenticationAnswered2024-04-16T11:15:24.000Z2018-06-12T15:48:16.000Z2020-09-15T15:42:55.000Z

  • jerrell.gary1.4491858992560479E12 (Presales - Americas Commercial, Emerging West)

    Hello Jeff,

     

    Here is some documentaiton about impossible travel also known as Behavior Detection.

     

    https://help.okta.com/en/prod/Content/Topics/Security/proc-security-behavior-detection.htm

     

    Security Behavior Detection

    This is an Early Access feature. To enable it, please contact Okta Support.

    Deciding when to require a second MFA factor is a challenge to admins. Prompting for an additional factor every time can frustrate the users; however, having a less restrictive policy increases the risk of account compromise.

     

    To provide additional security without overburdening your end users, you can configure a Sign On policyfor your organization to require additional authentication for behaviors defined as higher risk based on variance from individual users' prior sign ins. Admins can configure the system so that individual end users are only prompted for an additional MFA factor when there is a change in behavior that the admin defines.

    There are two components of security behavior detection. The first component is defining the behavior to track. Some examples of trackable behaviors are the following:

    Sign in from a new country, state, or city

    Sign in from a new location more than a specified distance from previous successful sign ins

    Sign in from a new device

    Sign in from a new IP address

    Sign in from a location deemed unfeasible for a user to travel to across two successive logins.

     

    Note that this is an Early Access feature that first requires access to the Behavioral Policy feature. To enable it, please contact Okta Support.

    The second component is to specify what action to take when there is a change in trackable behavior for an end user. Some examples of actions to take are the following:

    Permit access

    Require the end user to validate with an additional multifactor authentication factor

    Set the session lifetime

     

    Note: At this time, you cannot deny access if a behavior condition is selected in a Sign On policy rule.

     

    Additionally, you can reset the behavior profile for an end user. This reset clears all tracked behavior history for the end user, but continues tracking new behavior.

    Defining a behavior does not trigger any actions. You must include the new behavior in a Sign On policy in order for behavior detection to take effect.

     

    Part 1 – Defining Behaviors

    Navigate to Security > Behavior Detection.

    Behavior types are based on changes in location, device, or the IP address from which Okta is accessed. You can have several named behaviors for each of these behavior types. For example, one location behavior can be based on the country from which the sign on originates, and another behavior can be based on the city from which the sign on originates. Either or both of these behaviors can be used in sign on policies; in this example, you can prompt for a second MFA factor when there is a change of country, but permit access when there is a change of city.

     

    The following table defines these behaviors.

    Behavior TypeNameDescriptionDefaults and Customization

    LocationNew CityA city that has not been the source of a prior, successful sign in.Checked against the last 20 successful sign ins. You can change the number to check against.

     

    New StateA state or region that has not been the source of a prior, successful sign in.Checked against the last 15 successful sign ins. You can change the number of successful sign ins to check against.

     

    New CountryA country that has not been the source of a prior, successful sign in.Checked against the last 10 successful sign ins. You can change the number of successful sign ins to check against.

     

    New Geo-LocationA location outside a specified radius that has not been the source of a prior, successful sign in.Checked against the last 20 successful sign ins for locations that are outside a 20 kilometer radius of the locations of prior, successful sign ins. You can change the number of successful sign ins to check against, specify the radius size, and define the location by longitude and latitude.

     

    DeviceNew DeviceA device that has not been the source of a prior, successful sign in. A device is based on the client; therefore, changing the browser is considered new deviceChecked against the last 20 successful sign ins. You can change the number of successful sign ins to check against.

     

    IPNew IPAn IP address that has not been the source of a prior, successful sign in.Checked against the last 50 successful sign ins. You can change the number of successful sign ins to check against.

     

    VelocityVelocityA measurement of velocity used to identify suspicious logins. Velocity is evaluated based on the distance and time elapsed between two subsequent user logins.Checked against the geographic distance and time elapsed between two successive logins. Defaults to 805 km/h (500 mph).

     

    In addition to these predefined behaviors, you can select Add Behavior to add a custom behavior. You can add any kind of behavior: location, device, or IP. The fields are the same as in the predefined behaviors.

    Similar screens appear for a behavior type if you are adding or editing. The following screenshot shows a Geolocation behavior edit.

     

    You can only use Active behaviors in security policies. You can leave a behavior as active if it is not used. Active means available for use in a sign on policy rule.

     

    Part 2 – Define Action to Take

    Navigate to Security > Authentication, and then select Sign On. Either create a new rule or edit an existing rule.

     

    Add one of the behaviors to the And behavior is box, shown below.

    To add a behavior, you can start typing a behavior name and a drop-down list of all matching defined behaviors displays from which you can select, as shown below.

     

    When selected, the behavior name appears as shown below. To remove a behavior, click the X next to the name.

     

    Note: If you add multiple behaviors, they are OR conditions. In the example show below, the behavior is defined as either a new city OR a new country.

    When added, these behaviors are evaluated along with any other items defined in the rule. Specify what to do when the conditions are met in the Then access is section, as shown below.

     

    Note: If you included an IP address or a network zone in this screen and you also included a behavior that contains IP address specification, all these criteria must be met to trigger the rule.

    Resetting End User Behavior

     

    You can reset the behavior profile for a single end user to clear all tracked behavior history, but continue tracking new behavior. To reset a behavior profile, navigate to Directory > People, and then click on the user whose history you want to reset. In the screen that opens, select More Actions and then select Reset Behavior Profile from the drop-down menu, as shown below. You are prompted for a confirmation. You cannot undo this action.

    Expand Post

  • feok4 (feok4)

    Thanks Jerrell.  This was a great reply and provides a ton of info.  One feature that I don't see mentioned is the abiliy to send an email alert when the user triggers an 'impossible travel' rule.  This would help us dtermine attack vectors and quickly identify if/when credentials were comprimised.

  • hgf18 (hgf18)

    When can we expect "Security Behavior Detection" to be released in GA? It's been an Early Access feature for well over a year now.

  • go3m5 (go3m5)

    @jerrell.gary1.4491858992560479E12 (Presales - Americas Commercial, Emerging West)​ or anyone else who can help -- this is such a great feature would love to see an update, especially to Jeff Swift's question if the results of Behavior Detection can generate alerts in the logs / etc that can be pulled into a SIEM workflow...

This question is closed.
Loading
impossible travel