Security Behavior Detection

This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, contact Okta Support.

To provide additional security without overburdening your end users, you can configure a Sign On policy for your organization to require additional authentication for behaviors defined as higher risk based on variance from individual users' prior sign-in attempts.

About Behavior Security Detection

Deciding when to require a second MFA factor is a common challenge for admins. Prompting end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. to authenticate with an additional factor for every sign-in attempt can frustrate the users; however, having a less restrictive policy increases the risk of account compromise. With this feature, 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 adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. defines.

There are two components of security behavior detection:

Define the behavior to track.
Define an action to take if there is a change in trackable behavior for an end user.

Examples of trackable behaviors	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 sign-in attempts.
Examples of actions to take	Permit access Require the end user to validate with an additional multifactor authentication factor Set the session lifetime

New device behavior detection

Browser flow for new devices

New device behavior is based on the presence of:

An Okta security image cookie in the browser.
A browser fingerprint collected by the Okta Sign-in widget.

The security cookie and browser fingerprint are evaluated when an end user signs in to Okta directly from the Okta Sign-in Widget.

A browser cookie already exists if an end user signed in to Okta in the past and their security image is enabled. Under these conditions, the end user's device is treated as a known device.
When the security image cookie does not exist, Okta determines if a matching browser fingerprint already exists based on previous successful authentications. If the same browser fingerprint is detected, the device is treated as a known device, otherwise it is treated as a new device.
The security image is enabled by default and can be disabled in the Admin Console under Admin > Settings > Customization > Optional User Account Fields > Security Image.

Note about browser fingerprints

Web browser vendors such as Apple and Mozilla are reducing fingerprint accuracy in their browsers. As a result, browser support for browser fingerprinting only provides best effort accuracy.
The same browser fingerprint may be sent from multiple devices. The browser fingerprint may change over time.
If the new device behavior is going to rely solely on the browser fingerprinting, Okta recommends using new device behavior detection with new IP behavior detection. Using both together could reduce false negatives.

Trusted AppAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. Flows

A trusted app flow represents a scenario where end-user sign-in requests are proxied to Okta through an app using a valid SSWS token. In this flow, the end user does not interact directly with the Okta Sign-In Widget. Requests are instead forwarded by the trusted app to Okta through the authentication API.

If a customer uses a trusted app flow and new device behavior is configured, evaluation of the new device behavior works as follows:

The trusted app is required to pass a unique and deterministic device identifier as part of X-Device-Token header. See Primary authentication with device fingerprinting for information on how this identifier is passed.
Admins are responsible for storing the unique and deterministic value passed by the trust app in the X-Device-Fingerprint header on the clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. side. This can be in a client-side cookie.
For trusted app flows, new device behavior is based on the X-Device-Fingerprint header. Okta determines if a matching value already exists based on previous successful authentications. If the same value is detected, the device is treated as a known device, otherwise it is treated as a new device.

General guidelines

Sensitive data should not be stored on the client side. See Device Fingerprint Best Practices on how to securely generate this value.
Use the HTTPonly flag when storing a cookie.
JavaScript fingerprinting methods are strongly discouraged. Okta recommends storing the UUID that is generated on the server side.

Before you begin

Note the following about behavior detection:

You cannot deny access if a behavior condition is selected in a Sign On policy rule.
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.
You must include the new behavior in a Sign On policy in order for behavior detection to take effect. Defining a behavior only does not trigger any actions.
Location policies are based on a third party geo-location database — as a result, location data may not always be fully accurate. Okta updates geo-location IP data once a week to minimize potential inaccuracies with location data.

Step 1: Define a behavior type

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 Type	Name	Description	Defaults and Customization
Location	New City	A 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 State	A 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 Country	A 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-Location	A 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.
Device	New Device	A 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 device	Checked against the last 20 successful sign ins. You can change the number of successful sign ins to check against.
IP	New IP	An 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.
Velocity	Velocity	A 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.

Step 2: Define an action

Navigate to Security > AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect., 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.

Reset 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.

System Log events

The System Log lists behavior that is evaluated for any sign-in attempts.

For user.session.start and policy.evaluate.sign_on events:

Navigate to to DebugContext to see a map of behavior evaluations.
The map has entries in the form of key=value.
Key is the behavior name and value is the evaluation output.

Possible values:

POSITIVE: Behavior is detected. POSITIVE results in the policy rule matching – if MFA is configured for the rule, Okta prompts for MFA.
NEGATIVE: Behavior is not detected. NEGATIVE results in the policy rule not matching – if MFA is configured for the rule, Okta does not prompt for MFA.
UNKNOWN: Not enough history to detect behavior. UNKNOWN results in the policy rule matching – if MFA is configured for the rule, Okta prompts for MFA.
BAD_REQUEST: Not enough information from the sign-in attempt to detect behavior. For example, if the cookies and device fingerprint are missing, Okta treats it as a BAD_REQUEST, which results in the policy rule matching – if MFA is configured for the rule, Okta prompts for MFA.

Top