Risk scoring
Risk scoring uses a data-driven risk engine to determine whether each sign-in event is likely to represent malicious activity. Okta assigns a risk level to each sign in attempt by evaluating information such as the following:
- The IP address used to make the sign-in request.
- Behavioral information about the user who made the sign-in request.
- Previous successful and failed sign-in attempts
- Routing information associated with the request
You can use this risk assessment information when you configure sign-on policy rules to take different actions based on the risk level of the sign-in event. For example, if you configure Okta sign-on policies to evaluate risk conditions, Okta uses information—such as the device details and location—to determine the risk level of the sign-in attempt. You can configure the policy to then take different actions based on the risk level assigned to the sign-in attempt. If a sign-in attempt is evaluated and identified as "high" risk, you might require additional authentication before granting access.
The risk engine automatically identifies all new user sign-on attempts as "high" risk events. With each subsequent successful sign-on attempt, the risk engine gathers more information about the user’s sign-on activity and patterns and evaluates subsequent sign-in attempts relative to this baseline.
Risk scoring is designed to complement, not replace, existing security tools and should not be used to:
- Substitute bot management or automation detection
- Replace Web Application Firewalls (WAFs)
- Assist with any type of security compliance
Risk-related information in System Log events
System Log events record information about how the risk level was determined for each authentication attempt. For example, the risk level for a sign-in event might be based on any combination of the following factors:
- Anomalous location
- Anomalous device
- Suspected threat based on Okta ThreatInsight detection
To see details about the risk evaluation for an event, navigate to DebugContext and DebugData. For example:
In this example, the risk level for this sign-on attempt is MEDIUM because the user signed on using a new device, as indicated by reasons=Anomalous Device.
You might notice that the ThreatSuspected field is false even though the risk level is Medium. If this sign-on attempt had been from an IP address suspected of potentially malicious activity, the ThreatSuspected field would display true.
You can also query the System Log to view all events with a specific risk level. For example, to see a list of events identified as MEDIUM risk level, you can filter the System Log using the following query:
debugContext.debugData.risk eq "{level=MEDIUM}"
To see a list of events identified as HIGH risk level, you can filter the System Log using the following query:
debugContext.debugData.risk eq "{level=HIGH}"
To see a list of events identified as LOW risk level, you can filter the System Log using the following query:
debugContext.debugData.risk eq "{level=LOW}"
By default, Okta evaluates all sign-in requests for risk and changes in user behavior. If you don't configure rules to specifically evaluate the risk level of sign-in requests, the results of the risk and behavior evaluation are added to the DebugContext in the System Log in a separate LogOnlySecurityData field.
Configure risk scoring
You can add risk scoring as a condition for any application or Okta sign-on policy rule by setting the AND Risk is field for a rule to Low, Medium, or High.
Rules have the risk level set to Any by default.
To configure risk scoring:
- Create an Okta sign-on policy and configure the rule for it:
- Create an app sign-on policy and configure the rule for it:
- Select the AND Risk is condition, then select a risk level and save the rule.