Attempt to Modify an Okta Application

 1[metadata]
 2creation_date = "2020/11/06"
 3integration = ["okta"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 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 application. An adversary may attempt to modify, deactivate, or delete an Okta
13application in order to weaken an organization's security controls or disrupt their business operations.
14"""
15false_positives = [
16    """
17    Consider adding exceptions to this rule to filter false positives if your organization's Okta applications are
18    regularly modified and the behavior is expected.
19    """,
20]
21index = ["filebeat-*", "logs-okta*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "Attempt to Modify an Okta Application"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
29
30### Investigating Attempt to Modify an Okta Application
31
32Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to alter, deactivate, or delete them, aiming to compromise security controls or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to preempt potential security breaches.
33
34### Possible investigation steps
35
36- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.update to identify the specific application and user involved in the modification attempt.
37- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application.
38- Check for any recent changes in user permissions or roles that might explain the modification attempt.
39- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents.
40- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack.
41
42### False positive analysis
43
44- Routine administrative updates to Okta applications by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform regular maintenance.
45- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods.
46- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only.
47- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts.
48- Changes made by third-party vendors or partners with legitimate access can be mistaken for unauthorized attempts. Ensure these entities are properly documented and their actions are accounted for in the monitoring setup.
49
50### Response and remediation
51
52- Immediately isolate the affected Okta application to prevent further unauthorized modifications. This can be done by temporarily disabling the application or restricting access to it.
53- Review and revoke any unauthorized changes made to the application settings. Restore the application to its last known good configuration using backup or audit logs.
54- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates.
55- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents.
56- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts.
57- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings.
58- Communicate with relevant stakeholders, including IT and security teams, to inform them of the incident and any changes made to the application settings as part of the remediation process.
59
60## Setup
61
62The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
63references = [
64    "https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm",
65    "https://developer.okta.com/docs/reference/api/system-log/",
66    "https://developer.okta.com/docs/reference/api/event-types/",
67    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
68    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
69    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
70]
71risk_score = 21
72rule_id = "c74fd275-ab2c-4d49-8890-e2943fa65c09"
73severity = "low"
74tags = ["Use Case: Identity and Access Audit", "Data Source: Okta", "Tactic: Impact", "Resources: Investigation Guide"]
75timestamp_override = "event.ingested"
76type = "query"
77
78query = '''
79event.dataset:okta.system and event.action:application.lifecycle.update
80'''
81
82
83[[rule.threat]]
84framework = "MITRE ATT&CK"
85
86[rule.threat.tactic]
87id = "TA0040"
88name = "Impact"
89reference = "https://attack.mitre.org/tactics/TA0040/"