Attempt to Modify an Okta Policy
Detects attempts to modify an Okta policy. An adversary may attempt to modify an Okta policy in order to weaken an organization's security controls. For example, an adversary may attempt to modify an Okta multi-factor authentication (MFA) policy in order to weaken the authentication requirements for user accounts.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/05/21"
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 = """
12Detects attempts to modify an Okta policy. An adversary may attempt to modify an Okta policy in order to weaken an
13organization's security controls. For example, an adversary may attempt to modify an Okta multi-factor authentication
14(MFA) policy in order to weaken the authentication requirements for user accounts.
15"""
16false_positives = [
17 """
18 Consider adding exceptions to this rule to filter false positives if Okta policies are regularly modified in your
19 organization.
20 """,
21]
22index = ["filebeat-*", "logs-okta*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Attempt to Modify an Okta Policy"
26note = """## Triage and analysis
27
28### Investigating Attempt to Modify an Okta Policy
29
30Modifications to Okta policies may indicate attempts to weaken an organization's security controls. If such an attempt is detected, consider the following steps for investigation.
31
32#### Possible investigation steps:
33- Identify the actor associated with the event. Check the fields `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name`.
34- Determine the client used by the actor. You can look at `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context`.
35- Check the nature of the policy modification. You can review the `okta.target` field, especially `okta.target.display_name` and `okta.target.id`.
36- Examine the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the modification attempt.
37- Check if there have been other similar modification attempts in a short time span from the same actor or IP address.
38
39### False positive analysis:
40- This alert might be a false positive if Okta policies are regularly updated in your organization as a part of normal operations.
41- Check if the actor associated with the event has legitimate rights to modify the Okta policies.
42- Verify the actor's geographical location and the time of the modification attempt. If these align with the actor's regular behavior, it could be a false positive.
43
44### Response and remediation:
45- If unauthorized modification is confirmed, initiate the incident response process.
46- Lock the actor's account and enforce password change as an immediate response.
47- Reset MFA tokens for the actor and enforce re-enrollment, if applicable.
48- Review any other actions taken by the actor to assess the overall impact.
49- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques.
50- Consider a security review of your Okta policies and rules to ensure they follow security best practices.
51
52## Setup
53
54The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
55references = [
56 "https://developer.okta.com/docs/reference/api/system-log/",
57 "https://developer.okta.com/docs/reference/api/event-types/",
58 "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
59 "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
60 "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
61]
62risk_score = 21
63rule_id = "6731fbf2-8f28-49ed-9ab9-9a918ceb5a45"
64severity = "low"
65tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Defense Evasion"]
66timestamp_override = "event.ingested"
67type = "query"
68
69query = '''
70event.dataset:okta.system and event.action:policy.lifecycle.update
71'''
72
73
74[[rule.threat]]
75framework = "MITRE ATT&CK"
76[[rule.threat.technique]]
77id = "T1562"
78name = "Impair Defenses"
79reference = "https://attack.mitre.org/techniques/T1562/"
80[[rule.threat.technique.subtechnique]]
81id = "T1562.007"
82name = "Disable or Modify Cloud Firewall"
83reference = "https://attack.mitre.org/techniques/T1562/007/"
84
85
86
87[rule.threat.tactic]
88id = "TA0005"
89name = "Defense Evasion"
90reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Attempt to Modify an Okta Policy
Modifications to Okta policies may indicate attempts to weaken an organization's security controls. If such an attempt is detected, consider the following steps for investigation.
Possible investigation steps:
- Identify the actor associated with the event. Check the fields
okta.actor.id
,okta.actor.type
,okta.actor.alternate_id
, andokta.actor.display_name
. - Determine the client used by the actor. You can look at
okta.client.device
,okta.client.ip
,okta.client.user_agent.raw_user_agent
,okta.client.ip_chain.ip
, andokta.client.geographical_context
. - Check the nature of the policy modification. You can review the
okta.target
field, especiallyokta.target.display_name
andokta.target.id
. - Examine the
okta.outcome.result
andokta.outcome.reason
fields to understand the outcome of the modification attempt. - Check if there have been other similar modification attempts in a short time span from the same actor or IP address.
False positive analysis:
- This alert might be a false positive if Okta policies are regularly updated in your organization as a part of normal operations.
- Check if the actor associated with the event has legitimate rights to modify the Okta policies.
- Verify the actor's geographical location and the time of the modification attempt. If these align with the actor's regular behavior, it could be a false positive.
Response and remediation:
- If unauthorized modification is confirmed, initiate the incident response process.
- Lock the actor's account and enforce password change as an immediate response.
- Reset MFA tokens for the actor and enforce re-enrollment, if applicable.
- Review any other actions taken by the actor to assess the overall impact.
- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques.
- Consider a security review of your Okta policies and rules to ensure they follow 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
- Attempt to Deactivate an Okta Network Zone
- Attempt to Deactivate an Okta Policy
- Attempt to Deactivate an Okta Policy Rule
- Attempt to Delete an Okta Network Zone
- Attempt to Delete an Okta Policy