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

nldcsc_elastic_rules/rules/integrations/pad/privileged_access_ml_okta_rare_source_ip_by_user.toml

@@ -0,0 +1,101 @@
+[metadata]
+creation_date = "2025/02/18"
+integration = ["pad", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job has identified a user performing privileged operations in Okta from an uncommon source IP,
+indicating potential privileged access activity. This could suggest an account compromise, misuse of administrative
+privileges, or an attacker leveraging a new network location to escalate privileges.
+"""
+from = "now-1h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "pad_okta_rare_source_ip_by_user"
+name = "Unusual Source IP for Okta Privileged Operations Detected"
+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 Unusual Source IP for Okta Privileged Operations Detected
+
+Okta is a widely used identity management service that controls access to applications and data. Adversaries may exploit Okta by using stolen credentials to perform privileged operations from unfamiliar IP addresses, indicating potential misuse or compromise. The detection rule leverages machine learning to identify deviations in IP usage patterns, flagging unusual access attempts that could signify privilege escalation or account compromise.
+
+### Possible investigation steps
+
+- Review the source IP address flagged by the alert to determine its geolocation and assess if it aligns with the user's typical access patterns or known locations.
+- Check the Okta logs for the specific user account to identify any other recent activities from the same IP address or any other unusual IP addresses.
+- Investigate the timing and nature of the privileged operations performed to determine if they align with the user's normal behavior or job responsibilities.
+- Correlate the flagged IP address with any known threat intelligence feeds to check for any history of malicious activity associated with it.
+- Contact the user to verify if they were aware of the access attempt and if they have recently used a new network location or VPN service.
+- Examine any recent changes to the user's account settings or permissions that could indicate unauthorized modifications.
+
+### False positive analysis
+
+- Employees traveling or working remotely may trigger alerts due to accessing Okta from new IP addresses. To manage this, maintain a list of known IP ranges for remote work and travel, and configure exceptions for these ranges.
+- Use of VPNs or proxy services can result in access from unfamiliar IPs. Regularly update the list of approved VPN or proxy IP addresses and exclude them from triggering alerts.
+- Changes in corporate network infrastructure, such as new IP allocations, can cause false positives. Ensure that any changes in network configurations are communicated to the security team to update the detection rule's exceptions.
+- Scheduled maintenance or testing activities by IT staff might appear as unusual access. Document and whitelist IP addresses used during these activities to prevent unnecessary alerts.
+- Third-party integrations or services that access Okta on behalf of users can be mistaken for suspicious activity. Identify and whitelist these services' IP addresses to avoid false positives.
+
+### Response and remediation
+
+- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access.
+- Conduct a thorough review of recent privileged operations performed by the affected account to identify any unauthorized changes or data access.
+- Reset the password for the compromised account and enforce multi-factor authentication (MFA) to enhance security.
+- Notify the security team and relevant stakeholders about the potential compromise for further investigation and monitoring.
+- Review and update access logs to ensure all unusual IP addresses are flagged and monitored for any future access attempts.
+- Implement network-based restrictions to block the identified unusual IP address from accessing the Okta environment.
+- Conduct a post-incident analysis to identify the root cause and update security policies and procedures to prevent similar incidents in the future."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/pad",
+]
+risk_score = 21
+rule_id = "fbb10f1e-77cb-42f9-994e-5da17fc3fc15"
+setup = """## Setup
+
+The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.
+
+### Privileged Access Detection Setup
+The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Privileged Access Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.
+- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+
+#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Privileged Access Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[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 = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_application_assignment_changes.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2025/02/18"
+integration = ["pad", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job has identified an unusual spike in Okta group application assignment change events, indicating
+potential privileged access activity. Threat actors might be assigning applications to groups to escalate access,
+maintain persistence, or facilitate lateral movement within an organization’s environment.
+"""
+from = "now-3h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "pad_okta_spike_in_group_application_assignment_changes"
+name = "Spike in Group Application Assignment Change Events"
+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 Spike in Group Application Assignment Change Events
+
+In modern environments, identity and access management systems like Okta manage user access to applications. Adversaries may exploit these systems by altering group application assignments to gain unauthorized access or escalate privileges. The detection rule leverages machine learning to identify unusual spikes in these changes, signaling potential misuse and enabling timely investigation of privilege escalation activities.
+
+### Possible investigation steps
+
+- Review the specific group application assignment change events that triggered the alert to identify which groups and applications were involved.
+- Analyze the timeline of the changes to determine if there is a pattern or specific time frame when the spike occurred.
+- Investigate the user accounts associated with the changes to assess if they have a history of suspicious activity or if they belong to high-risk roles.
+- Check for any recent changes in group membership or application access policies that could explain the spike in assignment changes.
+- Correlate the events with other security alerts or logs to identify any concurrent suspicious activities, such as failed login attempts or unusual access patterns.
+- Consult with the IT or security team to verify if there were any legitimate administrative activities or changes that could have caused the spike.
+
+### False positive analysis
+
+- Routine administrative changes in group application assignments can trigger false positives. Regularly review and document these changes to differentiate them from suspicious activities.
+- Automated processes or scripts that frequently update group assignments may cause spikes. Identify and whitelist these processes to prevent unnecessary alerts.
+- Organizational restructuring or onboarding/offboarding activities can lead to increased group assignment changes. Temporarily adjust the detection thresholds or exclude these events during known periods of high activity.
+- Changes related to application updates or migrations might be flagged. Coordinate with IT teams to schedule these changes and exclude them from monitoring during the update window.
+- Frequent changes by trusted users or administrators can be excluded by creating exceptions for specific user accounts or roles, ensuring that only unexpected changes trigger alerts.
+
+### Response and remediation
+
+- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation.
+- Revert any unauthorized group application assignments to their previous state to mitigate potential misuse.
+- Conduct a thorough review of recent changes in group application assignments to identify any additional unauthorized modifications.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or accounts have been compromised.
+- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activity.
+- Review and update access controls and group assignment policies to prevent similar unauthorized changes in the future.
+- Coordinate with the IT and security teams to ensure that all affected systems and applications are patched and secured against known vulnerabilities."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/pad",
+]
+risk_score = 21
+rule_id = "3278313c-d6cd-4d49-aa24-644e1da6623c"
+setup = """## Setup
+
+The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.
+
+### Privileged Access Detection Setup
+The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Privileged Access Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.
+- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+
+#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Privileged Access Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_lifecycle_changes.toml

@@ -0,0 +1,106 @@
+[metadata]
+creation_date = "2025/02/18"
+integration = ["pad", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job has identified an unusual spike in Okta group lifecycle change events, indicating potential
+privileged access activity. Adversaries may be altering group structures to escalate privileges, maintain persistence,
+or facilitate lateral movement within an organization’s identity management system.
+"""
+from = "now-3h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "pad_okta_spike_in_group_lifecycle_changes"
+name = "Spike in Group Lifecycle Change Events"
+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 Spike in Group Lifecycle Change Events
+
+In identity management systems like Okta, group lifecycle changes are crucial for managing user access and permissions. Adversaries may exploit these changes to escalate privileges or maintain unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on privilege escalation tactics, it helps security analysts pinpoint and investigate suspicious activities.
+
+### Possible investigation steps
+
+- Review the specific group lifecycle change events that triggered the alert to identify which groups were altered and the nature of the changes.
+- Examine the user accounts associated with the changes to determine if they have a history of suspicious activity or if they have recently been granted elevated privileges.
+- Check the timestamps of the group changes to see if they coincide with other unusual activities or known attack patterns within the organization.
+- Investigate any recent access requests or approvals related to the affected groups to ensure they were legitimate and authorized.
+- Correlate the group changes with other security alerts or logs to identify potential lateral movement or privilege escalation attempts by adversaries.
+- Assess the current membership of the affected groups to ensure no unauthorized users have been added or legitimate users removed.
+
+### False positive analysis
+
+- Routine administrative changes in group memberships can trigger false positives. Security teams should identify and whitelist these regular activities to prevent unnecessary alerts.
+- Automated processes or scripts that modify group structures for legitimate reasons may cause spikes. Exclude these known processes by creating exceptions in the detection rule.
+- Large-scale onboarding or offboarding events can lead to a temporary increase in group lifecycle changes. Coordinate with HR or relevant departments to anticipate these events and adjust monitoring thresholds accordingly.
+- Changes due to system integrations or updates might be misinterpreted as suspicious. Document and exclude these events by maintaining an updated list of integration activities.
+- Regular audits or compliance checks that involve group modifications should be recognized and filtered out to avoid false alarms.
+
+### Response and remediation
+
+- Immediately isolate affected user accounts and groups to prevent further unauthorized access or privilege escalation. This can be done by temporarily disabling accounts or removing them from critical groups.
+- Conduct a thorough review of recent group lifecycle changes to identify unauthorized modifications. Revert any unauthorized changes to restore the original group structures and permissions.
+- Implement additional monitoring on the affected accounts and groups to detect any further suspicious activities. This includes setting up alerts for any new group changes or access attempts.
+- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms used by the adversary.
+- Review and update access controls and group management policies to ensure they align with the principle of least privilege, minimizing the risk of privilege escalation.
+- Coordinate with the IT and security teams to apply patches or updates to any vulnerabilities identified during the investigation that may have been exploited for privilege escalation.
+- Document the incident, including all actions taken, and conduct a post-incident review to identify lessons learned and improve future response strategies."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/pad",
+]
+risk_score = 21
+rule_id = "aa28f01d-bc93-4c8f-bc01-6f67f2a0a833"
+setup = """## Setup
+
+The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.
+
+### Privileged Access Detection Setup
+The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Privileged Access Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.
+- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+
+#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Privileged Access Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_membership_changes.toml

@@ -0,0 +1,106 @@
+[metadata]
+creation_date = "2025/02/18"
+integration = ["pad", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job has identified an unusual spike in Okta group membership events, indicating potential privileged
+access activity. Attackers or malicious insiders might be adding accounts to privileged groups to escalate their access,
+potentially leading to unauthorized actions or data breaches.
+"""
+from = "now-3h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "pad_okta_spike_in_group_membership_changes"
+name = "Spike in Group Membership Events"
+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 Spike in Group Membership Events
+
+In modern IT environments, group membership management is crucial for controlling access to resources. Adversaries may exploit this by adding accounts to privileged groups, thereby escalating their access rights. The detection rule leverages machine learning to identify unusual spikes in group membership events, signaling potential unauthorized access attempts. This proactive approach helps in mitigating risks associated with privilege escalation.
+
+### Possible investigation steps
+
+- Review the specific Okta group membership events that triggered the alert to identify which accounts were added to privileged groups.
+- Cross-reference the accounts added with known user roles and responsibilities to determine if the changes align with expected access patterns.
+- Check recent activity logs for the accounts added to privileged groups to identify any suspicious or unauthorized actions following the group membership change.
+- Investigate the source of the group membership changes, including the user or system that initiated the changes, to assess if it was a legitimate administrative action.
+- Analyze historical data for similar spikes in group membership events to determine if this is part of a recurring pattern or an isolated incident.
+- Consult with the IT or security team to verify if there were any recent changes in access policies or group management procedures that could explain the spike.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger spikes in group membership events, such as scheduled updates or onboarding processes. Users can create exceptions for these known activities to prevent false alerts.
+- Automated scripts or tools that manage group memberships for legitimate purposes might cause false positives. Identifying and excluding these scripts from monitoring can reduce unnecessary alerts.
+- Changes in group membership due to organizational restructuring or policy updates can appear as spikes. Documenting these changes and adjusting the detection parameters accordingly can help mitigate false positives.
+- Frequent legitimate access requests to privileged groups during specific business cycles, like end-of-quarter financial reviews, can be excluded by setting time-based exceptions.
+- Regular audits or compliance checks that involve temporary access to privileged groups should be accounted for by creating temporary exceptions during these periods.
+
+### Response and remediation
+
+- Immediately isolate the affected accounts by removing them from any privileged groups to prevent further unauthorized access.
+- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized additions and remove them as necessary.
+- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on the affected accounts and privileged groups to detect any further suspicious activity.
+- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future unauthorized changes.
+- Document the incident and response actions taken, and conduct a post-incident review to identify any gaps in the current security posture and improve future response efforts."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/pad",
+]
+risk_score = 21
+rule_id = "138520d2-11ff-4288-a80e-a45b36dca4b1"
+setup = """## Setup
+
+The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.
+
+### Privileged Access Detection Setup
+The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Privileged Access Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.
+- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+
+#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Privileged Access Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/pad/privileged_access_ml_okta_spike_in_group_privilege_changes.toml

@@ -0,0 +1,111 @@
+[metadata]
+creation_date = "2025/02/18"
+integration = ["pad", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job has identified an unusual spike in Okta group privilege change events, indicating potential
+privileged access activity. Attackers might be elevating privileges by adding themselves or compromised accounts to
+high-privilege groups, enabling further access or persistence.
+"""
+from = "now-3h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "pad_okta_spike_in_group_privilege_changes"
+name = "Spike in Group Privilege Change Events"
+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 Spike in Group Privilege Change Events
+
+In environments using Okta, group privilege changes are crucial for managing access. Adversaries may exploit this by adding themselves to privileged groups, gaining unauthorized access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential privilege escalation attempts, thus aiding in early threat detection and response.
+
+### Possible investigation steps
+
+- Review the specific group privilege change events identified by the machine learning job to determine which accounts were added to privileged groups.
+- Cross-reference the accounts involved in the privilege changes with recent login activity to identify any unusual or suspicious access patterns.
+- Check the history of privilege changes for the affected groups to see if there is a pattern of unauthorized access or if this is an isolated incident.
+- Investigate the source IP addresses and locations associated with the privilege change events to identify any anomalies or unexpected geolocations.
+- Examine any recent changes to the accounts involved, such as password resets or multi-factor authentication (MFA) modifications, to assess if they have been compromised.
+- Collaborate with the affected users or their managers to verify if the privilege changes were authorized and legitimate.
+
+### False positive analysis
+
+- Routine administrative tasks may trigger spikes in group privilege changes. Regularly scheduled audits or updates to group memberships should be documented and excluded from alerts.
+- Automated scripts or tools that manage user access can cause frequent changes. Identify these scripts and create exceptions for their activity to prevent false positives.
+- Organizational restructuring or mergers often lead to bulk updates in group privileges. During these periods, temporarily adjust the sensitivity of the detection rule or whitelist specific activities.
+- Onboarding or offboarding processes can result in a high volume of legitimate group changes. Coordinate with HR and IT to anticipate these events and adjust monitoring accordingly.
+- Changes in security policies or compliance requirements might necessitate widespread privilege adjustments. Ensure these policy-driven changes are communicated to the security team to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected accounts by removing them from any high-privilege groups to prevent further unauthorized access.
+- Conduct a thorough review of recent group membership changes in Okta to identify any other unauthorized privilege escalations.
+- Reset passwords and enforce multi-factor authentication for the affected accounts to secure them against further compromise.
+- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further suspicious activity is detected.
+- Implement additional monitoring on the affected accounts and privileged groups to detect any further unauthorized changes or access attempts.
+- Review and update access control policies to ensure that only authorized personnel can modify group memberships, reducing the risk of future privilege escalation.
+- Document the incident, including all actions taken, to improve response strategies and inform future security measures."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/pad",
+]
+risk_score = 21
+rule_id = "02b4420d-eda2-4529-9e46-4a60eccb7e2d"
+setup = """## Setup
+
+The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.
+
+### Privileged Access Detection Setup
+The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Privileged Access Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.
+- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+
+#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Privileged Access Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1068"
+name = "Exploitation for Privilege Escalation"
+reference = "https://attack.mitre.org/techniques/T1068/"
+
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+

nldcsc_elastic_rules/rules/integrations/pad/privileged_access_ml_okta_spike_in_user_lifecycle_management_changes.toml

@@ -0,0 +1,105 @@
+[metadata]
+creation_date = "2025/02/18"
+integration = ["pad", "okta"]
+maturity = "production"
+updated_date = "2025/07/02"
+
+[rule]
+anomaly_threshold = 75
+author = ["Elastic"]
+description = """
+A machine learning job has identified an unusual spike in Okta user lifecycle management change events, indicating
+potential privileged access activity. Threat actors may manipulate user accounts to gain higher access rights or persist
+within the environment.
+"""
+from = "now-3h"
+interval = "15m"
+license = "Elastic License v2"
+machine_learning_job_id = "pad_okta_spike_in_user_lifecycle_management_changes"
+name = "Spike in User Lifecycle Management Change Events"
+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 Spike in User Lifecycle Management Change Events
+
+User lifecycle management in environments like Okta involves creating, modifying, and deleting user accounts. Adversaries may exploit this by manipulating accounts to escalate privileges or maintain access. The detection rule leverages machine learning to identify unusual spikes in these events, signaling potential misuse. By focusing on anomalies, it aids in early detection of privilege escalation tactics.
+
+### Possible investigation steps
+
+- Review the specific user accounts involved in the lifecycle management change events to identify any patterns or anomalies, such as multiple changes in a short period or changes made by unusual sources.
+- Check the timestamps of the change events to determine if they align with normal business hours or if they occurred during unusual times, which might indicate suspicious activity.
+- Investigate the source IP addresses and locations associated with the change events to identify any unusual or unauthorized access points.
+- Examine the types of changes made to the user accounts, such as privilege escalations or role modifications, to assess if they align with legitimate business needs.
+- Cross-reference the user accounts involved with recent security alerts or incidents to determine if they have been previously flagged for suspicious activity.
+- Consult with the account owners or relevant department heads to verify if the changes were authorized and necessary for business operations.
+
+### False positive analysis
+
+- Routine administrative tasks such as bulk user account updates or scheduled maintenance can trigger spikes in user lifecycle management events. To manage this, create exceptions for known maintenance windows or bulk operations.
+- Automated processes or scripts that regularly modify user accounts may cause false positives. Identify these processes and exclude them from the detection rule to prevent unnecessary alerts.
+- Onboarding or offboarding periods with high user account activity can lead to spikes. Adjust the detection thresholds temporarily during these periods or exclude specific user groups involved in these activities.
+- Integration with third-party applications that frequently update user attributes might result in false positives. Review and whitelist these applications to reduce noise in the detection system.
+
+### Response and remediation
+
+- Immediately isolate the affected user accounts to prevent further unauthorized access or privilege escalation. This can be done by disabling the accounts or changing their passwords.
+- Review and revoke any unauthorized permissions or roles that were assigned during the spike in user lifecycle management change events. Ensure that only legitimate access rights are restored.
+- Conduct a thorough audit of recent user account changes to identify any additional accounts that may have been manipulated. Pay special attention to accounts with elevated privileges.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response.
+- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activity or attempts to regain unauthorized access.
+- Escalate the incident to higher-level security management if the scope of the breach is extensive or if sensitive data may have been compromised.
+- Review and update access management policies and procedures to prevent similar incidents in the future, ensuring that changes to user accounts are logged and regularly reviewed."""
+references = [
+    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
+    "https://docs.elastic.co/en/integrations/pad",
+]
+risk_score = 21
+rule_id = "178770e0-5c20-4246-b430-e216a2888b23"
+setup = """## Setup
+
+The rule requires the Privileged Access Detection integration assets to be installed, as well as Okta logs collected by integrations such as Okta.
+
+### Privileged Access Detection Setup
+The Privileged Access Detection integration detects privileged access activity by identifying abnormalities in Windows, Linux and Okta events. Anomalies are detected using Elastic's Anomaly Detection feature.
+
+#### Prerequisite Requirements:
+- Fleet is required for Privileged Access Detection.
+- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
+- Okta events collected by [Okta](https://docs.elastic.co/en/integrations/okta) integration.
+- To add the Okta integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
+
+#### The following steps should be executed to install assets associated with the Privileged Access Detection integration:
+- Go to the Kibana homepage. Under Management, click Integrations.
+- In the query bar, search for Privileged Access Detection and select the integration to see more details about it.
+- Follow the instructions under the **Installation** section.
+- For this rule to work, complete the instructions through **Add preconfigured anomaly detection jobs**.
+"""
+severity = "low"
+tags = [
+    "Use Case: Privileged Access Detection",
+    "Rule Type: ML",
+    "Rule Type: Machine Learning",
+    "Tactic: Privilege Escalation",
+    "Resources: Investigation Guide",
+]
+type = "machine_learning"
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1078"
+name = "Valid Accounts"
+reference = "https://attack.mitre.org/techniques/T1078/"
+
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0004"
+name = "Privilege Escalation"
+reference = "https://attack.mitre.org/tactics/TA0004/"
+