The detection of a threat takes place prior to authentication evaluation. Requests that are blocked by ThreatInsight prevent user lockouts from suspicious IP addresses. Admins can audit sign-in requests to identify malicious activity by referring to the system log and choose to block IP addresses identified as malicious.
Note: The Okta Model for threat detection is based on a continuous evaluation of the latest data available. If Okta incorrectly identifies any trusted IP addresses as suspicious, you may exempt them from ThreatInsight as needed. Refer to Exempt Zones for more details.
To access this feature, navigate to Security > General from 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. console.
HealthInsight: Why is this task recommended?
This a HealthInsight security task. For more security recommendations from Okta, see HealthInsight.
Configure ThreatInsight to detect suspicious IP addresses from credential-based attacks.
When ThreatInsight actions are enabled, end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using apps to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. may sign in to their orgThe Okta container that represents a real-world organization. as usual. If a sign-in attempt from a malicious IP address is detected and authentication requests are set to be blocked, the user receives an HTTP 403 error.
Before you begin
- Create an IP Network zone that contains trusted IP addresses for your org so it may be exempted from ThreatInsight.
- Trusted IP addresses include IPs such as office gateway IPs or Okta agents. Refer to Exempt Zones for more details.
To configure and enable ThreatInsight:
- Sign in to the admin console and click Security > General.
- Navigate to Okta ThreatInsight Settings.
- Click Edit. A list of actions is displayed:
Log authentication attempts from malicious IPs
Log and block authentication attempts from malicious IPs
Select the desired action for your org and click Save to continue with your changes.
Note: It may take a few minutes for any changes to these settings to take effect.
|No Action||ThreatInsight actions are not enabled. Note that Okta collects ThreatInsight data for aggregation purposes even if this option is selected.|
|Log authentication attempts from malicious IPs||Sign-in attempts from malicious IP addresses are displayed in the system log. Network zones for whitelisting may be added.|
|Log and block authentication attempts from malicious IPs||Sign-in attempts from malicious IP addresses are displayed in the system log and blocked, returning an HTTP 403 error. Network zones for whitelisting may be added.|
When a network zone is added to this field, IP addresses included in the zones are exempt from the following actions:
- Log authentication attempts from malicious IPs
- Log and block authentication attempts from malicious IPs
System Log events
If ThreatInsight actions are enabled, requests from malicious IP addresses will appear in the admin System Log, which can be accessed from the admin console menu or directly from the link provided in Okta ThreatInsight Settings.
Enter the following query to find these type of events in the system log: eventType eq "security.threat.detected"
The security.threat.detected event only appears if the request is deemed a high threat.
ThreatInsight evaluates sign-in activity before the user itself can be identified so security.threat.detected events do not include a username.
If outcome.result is DENY, the request was terminated. The username cannot be identified.
- If outcome.result is ALLOW, use the following query to search for other events with the same transaction ID: transaction.id eq "<TRANSACTION_ID>"
- If there are other events in the transaction, the user can also be found in the actor field.