New Okta Authentication Behavior Detected

calendar Dec 9, 2024 · Use Case: Identity and Access Audit Tactic: Initial Access Data Source: Okta  ·
Share on: linkedin copy

Detects events where Okta behavior detection has identified a new authentication behavior.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2023/11/07"
 3integration = ["okta"]
 4maturity = "production"
 5updated_date = "2024/12/09"
 6min_stack_version = "8.15.0"
 7min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration."
 8
 9[rule]
10author = ["Elastic"]
11description = "Detects events where Okta behavior detection has identified a new authentication behavior."
12from = "now-30m"
13index = ["filebeat-*", "logs-okta*"]
14interval = "15m"
15language = "kuery"
16license = "Elastic License v2"
17name = "New Okta Authentication Behavior Detected"
18note = """## Triage and analysis
19
20### Investigating New Okta Authentication Behavior Detected
21
22This rule detects events where Okta behavior detection has identified a new authentication behavior such as a new device or location.
23
24#### Possible investigation steps:
25- Identify the user involved in this action by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` fields.
26- Determine the authentication anomaly by examining the `okta.debug_context.debug_data.risk_behaviors` and `okta.debug_context.debug_data.flattened` fields.
27- Determine the client used by the actor. Review the `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.zone`, `okta.client.device`, and `okta.client.id` fields.
28- If the client is a device, check the `okta.device.id`, `okta.device.name`, `okta.device.os_platform`, `okta.device.os_version`, and `okta.device.managed` fields.
29- Review the past activities of the actor involved in this action by checking their previous actions.
30- Examine the `okta.request.ip_chain` field to potentially determine if the actor used a proxy or VPN to perform this action.
31- Evaluate the actions that happened just before and after this event in the `okta.event_type` field to help understand the full context of the activity.
32
33### False positive analysis:
34- A user may be using a new device or location to sign in.
35- The Okta behavior detection may be incorrectly identifying a new authentication behavior and need adjusted.
36
37### Response and remediation:
38- If the user is legitimate and the authentication behavior is not suspicious, no action is required.
39- If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA).
40    - If MFA is already enabled, consider resetting MFA for the user.
41- If the user is not legitimate, consider deactivating the user's account.
42- If this is a false positive, consider adjusting the Okta behavior detection settings.
43- Block the IP address or device used in the attempts if they appear suspicious, using the data from the `okta.client.ip` and `okta.device.id` fields.
44- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
45
46## Setup
47
48The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
49"""
50references = [
51    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
52    "https://sec.okta.com/articles/2023/08/cross-tenant-impersonation-prevention-and-detection",
53    "https://unit42.paloaltonetworks.com/muddled-libra/",
54    "https://help.okta.com/oie/en-us/content/topics/security/behavior-detection/about-behavior-detection.htm",
55    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
56    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
57]
58risk_score = 47
59rule_id = "260486ee-7d98-11ee-9599-f661ea17fbcd"
60severity = "medium"
61tags = ["Use Case: Identity and Access Audit", "Tactic: Initial Access", "Data Source: Okta"]
62timestamp_override = "event.ingested"
63type = "query"
64
65query = '''
66event.dataset:okta.system and okta.debug_context.debug_data.risk_behaviors:*
67'''
68
69
70[[rule.threat]]
71framework = "MITRE ATT&CK"
72
73[rule.threat.tactic]
74id = "TA0001"
75name = "Initial Access"
76reference = "https://attack.mitre.org/tactics/TA0001/"

Triage and analysis

Investigating New Okta Authentication Behavior Detected

This rule detects events where Okta behavior detection has identified a new authentication behavior such as a new device or location.

Possible investigation steps:

  • Identify the user involved in this action by examining the okta.actor.id, okta.actor.type, okta.actor.alternate_id, and okta.actor.display_name fields.
  • Determine the authentication anomaly by examining the okta.debug_context.debug_data.risk_behaviors and okta.debug_context.debug_data.flattened fields.
  • Determine the client used by the actor. Review the okta.client.ip, okta.client.user_agent.raw_user_agent, okta.client.zone, okta.client.device, and okta.client.id fields.
  • If the client is a device, check the okta.device.id, okta.device.name, okta.device.os_platform, okta.device.os_version, and okta.device.managed fields.
  • Review the past activities of the actor involved in this action by checking their previous actions.
  • Examine the okta.request.ip_chain field to potentially determine if the actor used a proxy or VPN to perform this action.
  • Evaluate the actions that happened just before and after this event in the okta.event_type field to help understand the full context of the activity.

False positive analysis:

  • A user may be using a new device or location to sign in.
  • The Okta behavior detection may be incorrectly identifying a new authentication behavior and need adjusted.

Response and remediation:

  • If the user is legitimate and the authentication behavior is not suspicious, no action is required.
  • If the user is legitimate but the authentication behavior is suspicious, consider resetting the user's password and enabling multi-factor authentication (MFA).
    • If MFA is already enabled, consider resetting MFA for the user.
  • If the user is not legitimate, consider deactivating the user's account.
  • If this is a false positive, consider adjusting the Okta behavior detection settings.
  • Block the IP address or device used in the attempts if they appear suspicious, using the data from the okta.client.ip and okta.device.id fields.
  • Conduct a review of Okta policies and ensure they are in accordance with security best practices.

Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

References

Related rules

to-top