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

nldcsc_elastic_rules/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies an Identity and Access Management (IAM) role deletion in Google Cloud Platform (GCP). A role contains a set
+of permissions that allows you to perform specific actions on Google Cloud resources. An adversary may delete an IAM
+role to inhibit access to accounts utilized by legitimate users.
+"""
+false_positives = [
+    """
+    Role deletions may be done by a system or network administrator. Verify whether the user email, resource name,
+    and/or hostname should be making changes in your environment. Role deletions by unfamiliar users or hosts should be
+    investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP IAM Role Deletion"
+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 GCP IAM Role Deletion
+
+Google Cloud Platform's IAM roles define permissions for actions on resources, crucial for managing access. Adversaries might delete roles to disrupt legitimate user access, hindering operations. The detection rule monitors audit logs for successful role deletions, signaling potential unauthorized access removal, thus aiding in identifying and mitigating such security threats.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteRole to identify the exact role that was deleted and the associated project or resource.
+- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs.
+- Check the event.timestamp to determine when the role deletion occurred and correlate it with any other suspicious activities around the same time.
+- Investigate the event.outcome:success to confirm that the role deletion was completed successfully and assess the potential impact on access and operations.
+- Analyze the context of the deletion by reviewing recent changes or activities in the project or organization to understand if the deletion was part of a legitimate change or an unauthorized action.
+- Contact the user or team responsible for the project to verify if the role deletion was intentional and authorized, and gather additional context if needed.
+
+### False positive analysis
+
+- Routine administrative actions may trigger alerts when roles are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
+- Automated scripts or tools that manage IAM roles might cause false positives if they delete roles as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
+- Deletion of temporary or test roles used in development environments can be mistaken for malicious activity. Implement filters to exclude actions within designated development projects or environments.
+- Changes in organizational structure or policy might necessitate role deletions, which could be misinterpreted as threats. Document and communicate these changes to the security team to adjust monitoring rules accordingly.
+- Third-party integrations or services that manage IAM roles could inadvertently cause false positives. Ensure these services are properly documented and their actions are whitelisted if deemed non-threatening.
+
+### Response and remediation
+
+- Immediately revoke any active sessions and credentials associated with the deleted IAM role to prevent unauthorized access.
+- Restore the deleted IAM role from a backup or recreate it with the same permissions to ensure legitimate users regain access.
+- Conduct a thorough review of recent IAM activity logs to identify any unauthorized changes or suspicious activities related to IAM roles.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring on IAM role changes to detect and alert on any future unauthorized deletions promptly.
+- Review and tighten IAM role permissions to ensure the principle of least privilege is enforced, reducing the risk of similar incidents.
+- Consider enabling additional security features such as multi-factor authentication (MFA) for accounts with permissions to modify IAM roles.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/iam/docs/understanding-roles"]
+risk_score = 21
+rule_id = "e2fb5b18-e33c-4270-851e-c3d675c9afcd"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteRole and event.outcome:success
+'''
+
+
+[[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/gcp/impact_gcp_service_account_deleted.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a service account is deleted in Google Cloud Platform (GCP). A service account is a special type of
+account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to
+make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users
+through domain-wide delegation. An adversary may delete a service account in order to disrupt their target's business
+operations.
+"""
+false_positives = [
+    """
+    Service accounts may be deleted by system administrators. Verify that the behavior was expected. Exceptions can be
+    added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Service Account Deletion"
+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 GCP Service Account Deletion
+
+In Google Cloud Platform, service accounts are crucial for enabling applications and VMs to perform authorized actions without user intervention. Adversaries may exploit this by deleting service accounts to disrupt operations or remove access. The detection rule monitors audit logs for successful service account deletions, flagging potential malicious activity to ensure timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion.
+- Identify the user or service account that initiated the deletion by examining the actor information in the audit logs.
+- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity.
+- Investigate the context of the deleted service account, including its permissions and the resources it had access to, to assess the potential impact of its deletion.
+- Contact the relevant team or individual responsible for the service account to verify if the deletion was authorized and intentional.
+- If unauthorized, review access controls and consider implementing additional security measures to prevent future unauthorized deletions.
+
+### False positive analysis
+
+- Routine maintenance or updates may involve the deletion and recreation of service accounts. To manage this, create exceptions for known maintenance activities by excluding specific service account names or associated project IDs during these periods.
+- Automated scripts or deployment tools might delete and recreate service accounts as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on the user or service account executing the script.
+- Organizational policy changes or restructuring can lead to legitimate service account deletions. Coordinate with the IT or security team to document these changes and adjust the detection rule to exclude these known events.
+- Test environments often involve frequent creation and deletion of service accounts. Exclude test project IDs or environments from the detection rule to prevent unnecessary alerts.
+
+### Response and remediation
+
+- Immediately revoke any permissions associated with the deleted service account to prevent unauthorized access or actions by adversaries exploiting the deletion.
+- Restore the deleted service account if possible, using GCP's undelete feature, to minimize disruption to business operations and restore normal functionality.
+- Review and audit recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded or followed the service account deletion.
+- Notify the security team and relevant stakeholders about the incident to ensure awareness and facilitate coordinated response efforts.
+- Implement additional monitoring on critical service accounts to detect and alert on any further unauthorized deletion attempts.
+- Conduct a root cause analysis to determine how the service account deletion was initiated and address any security gaps or misconfigurations that allowed it.
+- Enhance access controls and consider implementing multi-factor authentication for actions involving service account management to prevent similar incidents in the future.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/iam/docs/service-accounts"]
+risk_score = 47
+rule_id = "8fb75dda-c47a-4e34-8ecd-34facf7aad13"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccount and event.outcome:success
+'''
+
+
+[[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/gcp/impact_gcp_service_account_disabled.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/09/22"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a service account is disabled in Google Cloud Platform (GCP). A service account is a special type of
+account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to
+make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users
+through domain-wide delegation. An adversary may disable a service account in order to disrupt to disrupt their target's
+business operations.
+"""
+false_positives = [
+    """
+    Service accounts may be disabled by system administrators. Verify that the behavior was expected. Exceptions can be
+    added to this rule to filter expected behavior.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Service Account Disabled"
+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 GCP Service Account Disabled
+
+In Google Cloud Platform, service accounts are crucial for applications and VMs to perform authorized actions without user intervention. Adversaries may disable these accounts to disrupt services, impacting business operations. The detection rule identifies successful disablement actions in audit logs, signaling potential malicious activity by correlating specific event actions and outcomes, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.DisableServiceAccount to identify the exact time and source of the disablement action.
+- Identify the user or service account that performed the disablement by examining the actor information in the audit logs.
+- Check for any recent changes or unusual activities associated with the disabled service account, such as modifications to permissions or roles.
+- Investigate any related events or actions in the audit logs around the same timeframe to identify potential patterns or additional suspicious activities.
+- Assess the impact of the disabled service account on business operations by determining which applications or services were using the account.
+- Contact relevant stakeholders or application owners to verify if the disablement was authorized or if it was an unexpected action.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may involve disabling service accounts temporarily. To manage this, create exceptions for known maintenance periods or specific administrator actions.
+- Automated scripts or tools used for testing or deployment might disable service accounts as part of their process. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags.
+- Organizational policy changes or restructuring might lead to intentional service account disablement. Document these changes and update the detection rule to recognize these legitimate actions.
+- Service accounts associated with deprecated or retired applications may be disabled as part of cleanup efforts. Maintain an updated list of such applications and exclude related disablement actions from alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected service account by revoking its permissions to prevent further unauthorized actions.
+- Review the audit logs to identify any other suspicious activities associated with the disabled service account and assess the potential impact on business operations.
+- Re-enable the service account if it is determined to be legitimate and necessary for business functions, ensuring that it is secured with appropriate permissions and monitoring.
+- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
+- Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly.
+- Conduct a root cause analysis to understand how the service account was disabled and address any security gaps or misconfigurations that allowed the incident to occur.
+- Consider implementing additional security measures such as multi-factor authentication and least privilege access to enhance the protection of service accounts.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/iam/docs/service-accounts"]
+risk_score = 47
+rule_id = "bca7d28e-4a48-47b1-adb7-5074310e9a61"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.DisableServiceAccount and event.outcome:success
+'''
+
+
+[[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/gcp/impact_gcp_storage_bucket_deleted.toml

@@ -0,0 +1,87 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adversary may delete a storage bucket in
+order to disrupt their target's business operations.
+"""
+false_positives = [
+    """
+    Storage buckets may be deleted by a system or network administrator. Verify whether the user email, resource name,
+    and/or hostname should be making changes in your environment. Bucket deletions by unfamiliar users or hosts should
+    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP Storage Bucket Deletion"
+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 GCP Storage Bucket Deletion
+
+Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging events where storage buckets are removed, thus enabling timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action "storage.buckets.delete" to identify the user or service account responsible for the deletion.
+- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with any other suspicious activities around that time.
+- Investigate the IP address and location from which the deletion request originated to assess if it aligns with expected access patterns.
+- Examine the permissions and roles assigned to the user or service account involved in the deletion to determine if they had legitimate access.
+- Look for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket.
+- Contact the relevant stakeholders or data owners to confirm if the deletion was authorized or if it was unexpected.
+
+### False positive analysis
+
+- Routine maintenance or scheduled deletions by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or applications that manage storage lifecycle policies might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
+- Development or testing environments often involve frequent creation and deletion of storage buckets. Exclude these environments from monitoring by filtering based on project IDs or environment tags.
+- Organizational policy changes that involve restructuring storage resources can lead to legitimate bucket deletions. Coordinate with relevant teams to update detection rules temporarily during such changes.
+
+### Response and remediation
+
+- Immediately isolate the affected GCP project to prevent further unauthorized access or actions. This can be done by revoking access keys and permissions for any suspicious accounts identified in the audit logs.
+- Restore the deleted storage bucket from the most recent backup to minimize data loss and operational disruption. Ensure that the backup is clean and free from any malicious alterations.
+- Conduct a thorough review of IAM roles and permissions associated with the affected storage bucket to ensure that only authorized users have the necessary access. Implement the principle of least privilege.
+- Enable versioning on critical storage buckets to protect against accidental or malicious deletions in the future, allowing for easier recovery of deleted objects.
+- Set up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised.
+- Document the incident, including actions taken and lessons learned, to improve response strategies and update incident response plans for future reference.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/storage/docs/key-terms#buckets"]
+risk_score = 47
+rule_id = "bc0f2d83-32b8-4ae2-b0e6-6a45772e9331"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: GCP", "Data Source: Google Cloud Platform", "Tactic: Impact", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:"storage.buckets.delete"
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+

nldcsc_elastic_rules/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml

@@ -0,0 +1,107 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are
+user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will
+not be updated automatically and could lead to privilege creep if not carefully scrutinized.
+"""
+false_positives = [
+    """
+    Custom role creations may be done by a system or network administrator. Verify whether the user email, resource
+    name, and/or hostname should be making changes in your environment. Role creations by unfamiliar users or hosts
+    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP IAM Custom Role Creation"
+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 GCP IAM Custom Role Creation
+
+Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role.
+- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations.
+- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions.
+- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies.
+- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs.
+
+### False positive analysis
+
+- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior.
+- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts.
+- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern.
+- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly.
+- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities.
+
+### Response and remediation
+
+- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action.
+- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization.
+- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege.
+- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation.
+- Implement additional monitoring on the identified user or service account to detect any further suspicious activities.
+- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles.
+- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/iam/docs/understanding-custom-roles"]
+risk_score = 47
+rule_id = "aa8007f0-d1df-49ef-8520-407857594827"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Initial Access",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.CreateRole and event.outcome:success
+'''
+
+
+[[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.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/"
+

nldcsc_elastic_rules/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of an Identity and Access Management (IAM) service account key in Google Cloud Platform (GCP).
+Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate. If a key
+is deleted, the application will no longer be able to access Google Cloud resources using that key. A security best
+practice is to rotate your service account keys regularly.
+"""
+false_positives = [
+    """
+    Service account key deletions may be done by a system or network administrator. Verify whether the user email,
+    resource name, and/or hostname should be making changes in your environment. Key deletions by unfamiliar users or
+    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+index = ["filebeat-*", "logs-gcp*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "GCP IAM Service Account Key Deletion"
+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 GCP IAM Service Account Key Deletion
+
+In GCP, IAM service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries might delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aiding in timely investigation and response.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.iam.admin.v*.DeleteServiceAccountKey to identify the service account key that was deleted.
+- Check the event.outcome: success to confirm the key deletion was successful and not an attempted action.
+- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs.
+- Investigate the context around the deletion event, including the timestamp and any preceding or subsequent actions in the logs, to understand the sequence of events.
+- Verify if the key deletion aligns with the organization's key rotation policy or if it appears suspicious or unauthorized.
+- Assess the impact of the key deletion on applications or services that rely on the affected service account for authentication.
+- If unauthorized activity is suspected, initiate a broader investigation into potential unauthorized access or other malicious activities involving the affected service account.
+
+### False positive analysis
+
+- Routine key rotation activities by administrators can trigger alerts. To manage this, establish a baseline of expected key rotation schedules and exclude these from alerts.
+- Automated scripts or tools that perform regular maintenance and key management might cause false positives. Identify these scripts and whitelist their actions in the monitoring system.
+- Service account keys associated with non-critical or test environments may be deleted frequently as part of normal operations. Consider excluding these environments from the alerting criteria to reduce noise.
+- Temporary service accounts used for short-term projects or testing may have keys deleted as part of their lifecycle. Document these accounts and adjust the detection rule to ignore deletions from these specific accounts.
+
+### Response and remediation
+
+- Immediately revoke any remaining access for the compromised service account to prevent further unauthorized access to Google Cloud resources.
+- Investigate the audit logs to identify any unauthorized actions performed using the deleted key and assess the impact on affected resources.
+- Recreate the deleted service account key if necessary, ensuring that the new key is securely stored and access is restricted to authorized personnel only.
+- Implement additional monitoring on the affected service account to detect any further suspicious activities or unauthorized access attempts.
+- Escalate the incident to the security operations team for a comprehensive review and to determine if further investigation or response is required.
+- Review and update the key rotation policy to ensure that service account keys are rotated more frequently and securely managed to prevent similar incidents in the future.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://cloud.google.com/iam/docs/service-accounts",
+    "https://cloud.google.com/iam/docs/creating-managing-service-account-keys",
+]
+risk_score = 21
+rule_id = "9890ee61-d061-403d-9bf6-64934c51f638"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Identity and Access Audit",
+    "Tactic: Persistence",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.iam.admin.v*.DeleteServiceAccountKey and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1098"
+name = "Account Manipulation"
+reference = "https://attack.mitre.org/techniques/T1098/"
+
+
+[rule.threat.tactic]
+id = "TA0003"
+name = "Persistence"
+reference = "https://attack.mitre.org/tactics/TA0003/"
+