nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/okta/defense_evasion_suspicious_okta_user_password_reset_or_unlock_attempts.toml

@@ -0,0 +1,123 @@
+[metadata]
+creation_date = "2020/08/19"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic", "@BenB196", "Austin Songer"]
+description = """
+Identifies a high number of Okta user password reset or account unlock attempts. An adversary may attempt to obtain
+unauthorized access to Okta user accounts using these methods and attempt to blend in with normal activity in their
+target's environment and evade detection.
+"""
+false_positives = [
+    """
+    The number of Okta user password reset or account unlock attempts will likely vary between organizations. To fit
+    this rule to their organization, users can duplicate this rule and edit the schedule and threshold values in the new
+    rule.
+    """,
+]
+from = "now-60m"
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "High Number of Okta User Password Reset or Unlock Attempts"
+note = """## Triage and analysis
+
+### Investigating High Number of Okta User Password Reset or Unlock Attempts
+
+This rule is designed to detect a suspiciously high number of password reset or account unlock attempts in Okta. Excessive password resets or account unlocks can be indicative of an attacker's attempt to gain unauthorized access to an account.
+
+#### Possible investigation steps:
+- Identify the actor associated with the excessive attempts. The `okta.actor.alternate_id` field can be used for this purpose.
+- 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`.
+- Review the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the password reset or unlock attempts.
+- Review the event actions associated with these attempts. Look at the `event.action` field and filter for actions related to password reset and account unlock attempts.
+- Check for other similar patterns of behavior from the same actor or IP address. If there is a high number of failed login attempts before the password reset or unlock attempts, this may suggest a brute force attack.
+- Also, look at the times when these attempts were made. If these were made during off-hours, it could further suggest an adversary's activity.
+
+### False positive analysis:
+- This alert might be a false positive if there are legitimate reasons for a high number of password reset or unlock attempts. This could be due to the user forgetting their password or account lockouts due to too many incorrect attempts.
+- Check the actor's past behavior. If this is their usual behavior and they have a valid reason for it, then it might be a false positive.
+
+### Response and remediation:
+- If unauthorized attempts are confirmed, initiate the incident response process.
+- Reset the user's password and enforce MFA re-enrollment, if applicable.
+- Block the IP address or device used in the attempts, if they appear suspicious.
+- 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 = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 47
+rule_id = "e90ee3af-45fc-432e-a850-4a58cf14a457"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset:okta.system and
+  event.action:(system.email.account_unlock.sent_message or system.email.password_reset.sent_message or
+                system.sms.send_account_unlock_message or system.sms.send_password_reset_message or
+                system.voice.send_account_unlock_call or system.voice.send_password_reset_call or
+                user.account.unlock_token)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0001"
+name = "Initial Access"
+reference = "https://attack.mitre.org/tactics/TA0001/"
+
+[rule.threshold]
+field = ["okta.actor.alternate_id"]
+value = 5
+

nldcsc_elastic_rules/rules/integrations/okta/impact_attempt_to_revoke_okta_api_token.toml

@@ -0,0 +1,87 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies attempts to revoke an Okta API token. An adversary may attempt to revoke or delete an Okta API token to
+disrupt an organization's business operations.
+"""
+false_positives = [
+    """
+    If the behavior of revoking Okta API tokens is expected, consider adding exceptions to this rule to filter false
+    positives.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempt to Revoke Okta API Token"
+note = """## Triage and analysis
+
+### Investigating Attempt to Revoke Okta API Token
+
+The rule alerts when attempts are made to revoke an Okta API token. The API tokens are critical for integration services, and revoking them may lead to disruption in services. Therefore, it's important to validate these activities.
+
+#### Possible investigation steps:
+- Identify the actor associated with the API token revocation attempt. You can use the `okta.actor.alternate_id` field for this purpose.
+- Determine the client used by the actor. Review the `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context` fields.
+- Verify if the API token revocation was authorized or part of some planned activity.
+- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed.
+- Analyze the past activities of the actor involved in this action. An actor who usually performs such activities may indicate a legitimate reason.
+- Evaluate the actions that happened just before and after this event. It can help understand the full context of the activity.
+
+### False positive analysis:
+- It might be a false positive if the action was part of a planned activity or was performed by an authorized person.
+
+### Response and remediation:
+- If unauthorized revocation attempts are confirmed, initiate the incident response process.
+- Block the IP address or device used in the attempts, if they appear suspicious.
+- Reset the user's password and enforce MFA re-enrollment, if applicable.
+- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
+- If the revoked token was used for critical integrations, coordinate with the relevant team to minimize the impact.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+"""
+references = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "676cff2b-450b-4cf1-8ed2-c0c58a4a2dd7"
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:system.api_token.revoke
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1531"
+name = "Account Access Removal"
+reference = "https://attack.mitre.org/techniques/T1531/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/okta/impact_okta_attempt_to_deactivate_okta_application.toml

@@ -0,0 +1,91 @@
+[metadata]
+creation_date = "2020/11/06"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to deactivate an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta
+application in order to weaken an organization's security controls or disrupt their business operations.
+"""
+false_positives = [
+    """
+    Consider adding exceptions to this rule to filter false positives if your organization's Okta applications are
+    regularly deactivated and the behavior is expected.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempt to Deactivate an Okta Application"
+note = """## Triage and analysis
+
+### Investigating Attempt to Deactivate an Okta Application
+
+This rule detects attempts to deactivate an Okta application. Unauthorized deactivation could lead to disruption of services and pose a significant risk to the organization.
+
+#### Possible investigation steps:
+- Identify the actor associated with the deactivation attempt by examining the `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name` 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.
+- Understand the context of the event from the `okta.debug_context.debug_data` and `okta.authentication_context` fields.
+- Check the `okta.outcome.result` and `okta.outcome.reason` fields to see if the attempt was successful or failed.
+- Review the past activities of the actor involved in this action by checking their previous actions logged in the `okta.target` field.
+- Analyze the `okta.transaction.id` and `okta.transaction.type` fields to understand the context of the transaction.
+- 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:
+- It might be a false positive if the action was part of a planned activity, performed by an authorized person, or if the `okta.outcome.result` field shows a failure.
+- An unsuccessful attempt might also indicate an authorized user having trouble rather than a malicious activity.
+
+### Response and remediation:
+- If unauthorized deactivation attempts are confirmed, initiate the incident response process.
+- 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.
+- Reset the user's password and enforce MFA re-enrollment, if applicable.
+- Conduct a review of Okta policies and ensure they are in accordance with security best practices.
+- If the deactivated application was crucial for business operations, coordinate with the relevant team to reactivate it and minimize the impact.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
+"""
+references = [
+    "https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm",
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "edb91186-1c7e-4db8-b53e-bfa33a1a0a8a"
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:application.lifecycle.deactivate
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1489"
+name = "Service Stop"
+reference = "https://attack.mitre.org/techniques/T1489/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2020/11/06"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to delete an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta
+application in order to weaken an organization's security controls or disrupt their business operations.
+"""
+false_positives = [
+    """
+    Consider adding exceptions to this rule to filter false positives if your organization's Okta applications are
+    regularly deleted and the behavior is expected.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempt to Delete an Okta Application"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> 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.
+
+### Investigating Attempt to Delete an Okta Application
+
+Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, flagging potential threats with a low-risk score, aiding analysts in identifying and mitigating unauthorized attempts.
+
+### Possible investigation steps
+
+- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.delete to confirm the attempted deletion action.
+- Identify the user account associated with the deletion attempt and verify their role and permissions within the organization to assess if the action was authorized.
+- Check the timestamp of the event to determine if the deletion attempt coincides with any known maintenance windows or authorized changes.
+- Investigate the specific Okta application targeted for deletion to understand its importance and potential impact on business operations if it were successfully deleted.
+- Examine any recent changes or unusual activities associated with the user account or the targeted application to identify potential indicators of compromise.
+- Correlate this event with other security alerts or logs to determine if it is part of a broader attack or isolated incident.
+
+### False positive analysis
+
+- Routine maintenance activities by IT staff may trigger the rule when they legitimately delete or modify applications. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for application lifecycle management might generate false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated user accounts or service accounts.
+- Testing environments where applications are frequently created and deleted for development purposes can lead to false positives. Exclude these environments from monitoring or adjust the rule to ignore actions within specific test domains.
+- Changes in application configurations by authorized personnel for legitimate business needs may be flagged. Implement a process to log and approve such changes, allowing for easy identification and exclusion from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Okta application to prevent further unauthorized actions. This can be done by temporarily disabling the application or restricting access to it.
+- Review the audit logs and event details associated with the deletion attempt to identify the source of the action, including user accounts and IP addresses involved.
+- Revoke access for any compromised or suspicious user accounts identified in the investigation to prevent further unauthorized actions.
+- Restore the deleted application from backup if applicable, ensuring that all configurations and settings are intact.
+- Notify the security team and relevant stakeholders about the incident, providing details of the attempted deletion and actions taken.
+- Conduct a root cause analysis to determine how the unauthorized attempt was made and implement additional security controls to prevent similar incidents in the future.
+- Enhance monitoring and alerting for Okta application lifecycle events to ensure rapid detection and response to any future unauthorized modification or deletion attempts.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "d48e1c13-4aca-4d1f-a7b1-a9161c0ad86f"
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:application.lifecycle.delete
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1489"
+name = "Service Stop"
+reference = "https://attack.mitre.org/techniques/T1489/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml

@@ -0,0 +1,93 @@
+[metadata]
+creation_date = "2020/11/06"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects attempts to modify an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta
+application in order to weaken an organization's security controls or disrupt their business operations.
+"""
+false_positives = [
+    """
+    Consider adding exceptions to this rule to filter false positives if your organization's Okta applications are
+    regularly modified and the behavior is expected.
+    """,
+]
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Attempt to Modify an Okta Application"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> 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.
+
+### Investigating Attempt to Modify an Okta Application
+
+Okta 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.
+
+### Possible investigation steps
+
+- 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.
+- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application.
+- Check for any recent changes in user permissions or roles that might explain the modification attempt.
+- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents.
+- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack.
+
+### False positive analysis
+
+- 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.
+- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods.
+- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only.
+- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts.
+- 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.
+
+### Response and remediation
+
+- 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.
+- 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.
+- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates.
+- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents.
+- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts.
+- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings.
+- 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.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm",
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 21
+rule_id = "c74fd275-ab2c-4d49-8890-e2943fa65c09"
+severity = "low"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:application.lifecycle.update
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/okta/impact_possible_okta_dos_attack.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/05/21"
+integration = ["okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+author = ["Elastic"]
+description = """
+Detects possible Denial of Service (DoS) attacks against an Okta organization. An adversary may attempt to disrupt an
+organization's business operations by performing a DoS attack against its Okta service.
+"""
+index = ["filebeat-*", "logs-okta*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Possible Okta DoS Attack"
+note = """## Triage and analysis
+
+> **Disclaimer**:
+> 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.
+
+### Investigating Possible Okta DoS Attack
+
+Okta, a leading identity management service, is crucial for managing user access in organizations. Adversaries may exploit Okta by overwhelming it with requests, causing service disruptions. The detection rule identifies potential DoS attacks by monitoring specific Okta system events that indicate rate limit violations, signaling attempts to degrade service availability.
+
+### Possible investigation steps
+
+- Review the specific Okta system events that triggered the alert, focusing on event.action values such as application.integration.rate_limit_exceeded, system.org.rate_limit.warning, system.org.rate_limit.violation, and core.concurrency.org.limit.violation to understand the nature of the rate limit violations.
+- Analyze the frequency and pattern of the triggered events to determine if there is a consistent or unusual spike in requests that could indicate a DoS attack.
+- Identify the source IP addresses or user accounts associated with the excessive requests to determine if they are legitimate users or potential adversaries.
+- Check for any recent changes or updates in the Okta configuration or integrations that might have inadvertently caused an increase in request rates.
+- Correlate the Okta events with other network or application logs to identify any broader patterns or simultaneous attacks on other services that might suggest a coordinated effort.
+
+### False positive analysis
+
+- High-volume legitimate user activity can trigger rate limit warnings. Monitor for patterns of normal usage spikes, such as during company-wide meetings or product launches, and consider setting exceptions for these events.
+- Automated processes or integrations that frequently interact with Okta may cause rate limit violations. Identify these processes and adjust their request rates or set exceptions to prevent false positives.
+- Scheduled batch jobs that access Okta services might exceed rate limits. Review and optimize the scheduling of these jobs to distribute the load more evenly or whitelist them if they are essential and non-disruptive.
+- Third-party applications integrated with Okta could inadvertently cause rate limit issues. Work with vendors to ensure their applications are optimized for Okta's rate limits or create exceptions for trusted applications.
+- Temporary spikes in user activity due to password resets or account provisioning can lead to false positives. Implement monitoring to distinguish between these benign activities and potential threats, and adjust the rule to accommodate expected spikes.
+
+### Response and remediation
+
+- Immediately assess the impact on business operations by checking the availability and performance of Okta services. Coordinate with IT teams to ensure critical services remain operational.
+- Contain the attack by implementing rate limiting or IP blocking for the identified sources of excessive requests. Use network security tools to enforce these restrictions.
+- Notify the security operations center (SOC) and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response efforts.
+- Review and adjust Okta's rate limit settings to mitigate the risk of future DoS attempts, ensuring they align with the organization's typical usage patterns.
+- Escalate the incident to Okta support for further investigation and assistance in mitigating the attack, providing them with relevant logs and event details.
+- Conduct a post-incident analysis to identify any gaps in the current security posture and update incident response plans accordingly.
+- Enhance monitoring and alerting for similar threats by refining detection rules and ensuring they are tuned to capture early indicators of rate limit violations.
+
+## Setup
+
+The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://developer.okta.com/docs/reference/api/system-log/",
+    "https://developer.okta.com/docs/reference/api/event-types/",
+    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
+    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
+    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
+]
+risk_score = 47
+rule_id = "e6e3ecff-03dd-48ec-acbd-54a04de10c68"
+severity = "medium"
+tags = [
+    "Use Case: Identity and Access Audit",
+    "Data Source: Okta",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:okta.system and event.action:(application.integration.rate_limit_exceeded or system.org.rate_limit.warning or system.org.rate_limit.violation or core.concurrency.org.limit.violation)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1498"
+name = "Network Denial of Service"
+reference = "https://attack.mitre.org/techniques/T1498/"
+
+[[rule.threat.technique]]
+id = "T1499"
+name = "Endpoint Denial of Service"
+reference = "https://attack.mitre.org/techniques/T1499/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+