Attempt to Deactivate an Okta Policy

  1[metadata]
  2creation_date = "2020/05/21"
  3integration = ["okta"]
  4maturity = "production"
  5min_stack_comments = "Breaking change in Okta integration bumping version to ^2.0.0"
  6min_stack_version = "8.10.0"
  7updated_date = "2023/10/24"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Detects attempts to deactivate an Okta policy. An adversary may attempt to deactivate an Okta policy in order to weaken
 13an organization's security controls. For example, an adversary may attempt to deactivate an Okta multi-factor
 14authentication (MFA) policy in order to weaken the authentication requirements for user accounts.
 15"""
 16false_positives = [
 17    """
 18    If the behavior of deactivating Okta policies is expected, consider adding exceptions to this rule to filter false
 19    positives.
 20    """,
 21]
 22index = ["filebeat-*", "logs-okta*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "Attempt to Deactivate an Okta Policy"
 26note = """## Triage and analysis
 27
 28### Investigating Attempt to Deactivate an Okta Policy
 29
 30Okta policies define rules to manage user access to resources. Policies such as multi-factor authentication (MFA) are critical for enforcing strong security measures. Deactivation of an Okta policy could potentially weaken the security posture, allowing for unauthorized access or facilitating other malicious activities.
 31
 32This rule is designed to detect attempts to deactivate an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. For example, disabling an MFA policy could lower the security of user authentication processes.
 33
 34#### Possible investigation steps:
 35
 36- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert.
 37- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor.
 38- Examine the `okta.outcome.reason` field for additional context around the deactivation attempt.
 39- Check the `okta.outcome.result` field to confirm the policy deactivation attempt.
 40- Check if there are multiple policy deactivation attempts from the same actor or IP address (`okta.client.ip`).
 41- Check for successful logins immediately following the policy deactivation attempt.
 42- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deactivation attempt.
 43
 44### False positive analysis:
 45
 46- Check if there were issues with the Okta system at the time of the deactivation attempt. This could indicate a system error rather than a genuine threat activity.
 47- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deactivation attempt. If these match the actor's normal behavior, it might be a false positive.
 48- Verify the actor's administrative rights to ensure they are correctly configured.
 49
 50### Response and remediation:
 51
 52- If unauthorized policy deactivation is confirmed, initiate the incident response process.
 53- Immediately lock the affected actor account and require a password change.
 54- Consider resetting MFA tokens for the actor and require re-enrollment.
 55- Check if the compromised account was used to access or alter any sensitive data or systems.
 56- If a specific deactivation technique was used, ensure your systems are patched or configured to prevent such techniques.
 57- Assess the criticality of affected services and servers.
 58- Work with your IT team to minimize the impact on users and maintain business continuity.
 59- If multiple accounts are affected, consider a broader reset or audit of MFA tokens.
 60- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta.
 61- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
 62
 63## Setup
 64
 65The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
 66references = [
 67    "https://help.okta.com/en/prod/Content/Topics/Security/Security_Policies.htm",
 68    "https://developer.okta.com/docs/reference/api/system-log/",
 69    "https://developer.okta.com/docs/reference/api/event-types/",
 70    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
 71]
 72risk_score = 21
 73rule_id = "b719a170-3bdb-4141-b0e3-13e3cf627bfe"
 74severity = "low"
 75tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
 76timestamp_override = "event.ingested"
 77type = "query"
 78
 79query = '''
 80event.dataset:okta.system and event.action:policy.lifecycle.deactivate
 81'''
 82
 83
 84[[rule.threat]]
 85framework = "MITRE ATT&CK"
 86[[rule.threat.technique]]
 87id = "T1562"
 88name = "Impair Defenses"
 89reference = "https://attack.mitre.org/techniques/T1562/"
 90[[rule.threat.technique.subtechnique]]
 91id = "T1562.007"
 92name = "Disable or Modify Cloud Firewall"
 93reference = "https://attack.mitre.org/techniques/T1562/007/"
 94
 95
 96
 97[rule.threat.tactic]
 98id = "TA0005"
 99name = "Defense Evasion"
100reference = "https://attack.mitre.org/tactics/TA0005/"