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

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a firewall rule is deleted in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App Engine.
+These firewall rules can be configured to allow or deny connections to or from virtual machine (VM) instances or
+specific applications. An adversary may delete a firewall rule in order to weaken their target's security controls.
+"""
+false_positives = [
+    """
+    Firewall rules may be deleted by system administrators. Verify that the firewall configuration change 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 Firewall Rule 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 Firewall Rule Deletion
+
+In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors audit logs for deletion actions, flagging potential defense evasion attempts by identifying specific deletion events in VPC or App Engine environments.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.dataset:gcp.audit to confirm the deletion action and gather details such as the timestamp, user identity, and source IP address associated with the event.
+- Investigate the event.action field to determine whether the deletion occurred in the VPC or App Engine environment, and identify the specific firewall rule that was deleted.
+- Check the user or service account activity around the time of the deletion to identify any suspicious behavior or unauthorized access attempts.
+- Assess the impact of the deleted firewall rule by reviewing the network traffic patterns and security posture before and after the deletion.
+- Collaborate with the network security team to determine if the deletion was part of a legitimate change management process or if it indicates a potential security incident.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may trigger firewall rule deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for infrastructure management might delete and recreate firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service accounts or tags associated with these tools.
+- Changes in application deployment processes, especially in environments like App Engine, can lead to legitimate firewall rule deletions. Review deployment logs and processes to identify patterns and exclude these from alerts.
+- Organizational policy changes that involve restructuring network security may result in bulk deletions of firewall rules. Coordinate with network security teams to understand planned changes and temporarily adjust detection rules during these periods.
+- Test environments often have dynamic configurations where firewall rules are frequently added and removed. Exclude specific projects or environments designated for testing from the detection rule to reduce noise.
+
+### Response and remediation
+
+- Immediately isolate affected VM instances or applications by applying restrictive firewall rules to prevent further unauthorized access or data exfiltration.
+- Review audit logs to identify the source of the deletion action, including user accounts and IP addresses involved, and verify if the action was authorized.
+- Recreate the deleted firewall rules based on the last known good configuration to restore security controls and prevent unauthorized access.
+- Conduct a security review of the affected environment to identify any additional unauthorized changes or indicators of compromise.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted.
+- Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future.
+- Review and update access controls and permissions for users and service accounts to ensure that only authorized personnel can modify firewall rules.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://cloud.google.com/vpc/docs/firewalls",
+    "https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls",
+]
+risk_score = 47
+rule_id = "ff9b571e-61d6-4f6c-9561-eb4cca3bafe1"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:(*.compute.firewalls.delete or google.appengine.*.Firewall.Delete*Rule)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a firewall rule is modified in Google Cloud Platform (GCP) for Virtual Private Cloud (VPC) or App
+Engine. These firewall rules can be modified to allow or deny connections to or from virtual machine (VM) instances or
+specific applications. An adversary may modify an existing firewall rule in order to weaken their target's security
+controls and allow more permissive ingress or egress traffic flows for their benefit.
+"""
+false_positives = [
+    """
+    Firewall rules may be modified by system administrators. Verify that the firewall configuration change 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 Firewall Rule Modification"
+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 Firewall Rule Modification
+
+In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential defense evasion attempts by flagging suspicious changes in network configurations.
+
+### Possible investigation steps
+
+- Review the audit logs for entries with the event.dataset field set to gcp.audit to confirm the source of the alert.
+- Examine the event.action field for values such as *.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule to identify the specific type of firewall rule modification.
+- Identify the user or service account responsible for the modification by checking the actor information in the audit logs.
+- Assess the changes made to the firewall rule, including the before and after states, to determine if the modification allows more permissive ingress or egress traffic.
+- Investigate the context of the modification by reviewing related activities in the audit logs around the same time to identify any suspicious patterns or sequences of actions.
+- Check for any recent security incidents or alerts involving the affected VPC or App Engine application to understand potential motives or impacts of the rule change.
+- If unauthorized or suspicious activity is confirmed, initiate incident response procedures to mitigate any potential security risks.
+
+### False positive analysis
+
+- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known IP addresses or user accounts that regularly perform these tasks.
+- Automated scripts or tools used for infrastructure management might modify firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
+- Changes made during scheduled maintenance windows can be considered non-threatening. Implement time-based exceptions to ignore modifications during these periods.
+- Modifications related to scaling operations in App Engine or VPCs might be legitimate. Review and whitelist specific actions associated with scaling events to prevent unnecessary alerts.
+- Regular audits or compliance checks might involve temporary rule changes. Document these activities and exclude them from detection by correlating with audit logs or change management records.
+
+### Response and remediation
+
+- Immediately isolate the affected VPC or App Engine application by applying a restrictive firewall rule to prevent further unauthorized access or data exfiltration.
+- Review the audit logs to identify the source of the modification, including user accounts and IP addresses involved, and revoke any suspicious credentials or access.
+- Restore the firewall rule to its previous secure state using backup configurations or documented baselines to ensure the network is protected.
+- Conduct a thorough security assessment of the affected environment to identify any additional unauthorized changes or indicators of compromise.
+- Notify the security operations team and relevant stakeholders about the incident, providing details of the modification and actions taken.
+- Implement enhanced monitoring and alerting for future firewall rule changes to detect and respond to similar threats more quickly.
+- Consider engaging with Google Cloud support or a third-party security expert if the incident scope is beyond internal capabilities or if further expertise is required.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = [
+    "https://cloud.google.com/vpc/docs/firewalls",
+    "https://cloud.google.com/appengine/docs/standard/python/understanding-firewalls",
+]
+risk_score = 47
+rule_id = "2783d84f-5091-4d7d-9319-9fceda8fa71b"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Configuration Audit",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:(*.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml

@@ -0,0 +1,97 @@
+[metadata]
+creation_date = "2020/09/21"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies a Logging bucket deletion in Google Cloud Platform (GCP). Log buckets are containers that store and organize
+log data. A deleted bucket stays in a pending state for 7 days, and Logging continues to route logs to the bucket during
+that time. To stop routing logs to a deleted bucket, you can delete the log sinks that have the bucket as their
+destination, or modify the filter for the sinks to stop it from routing logs to the deleted bucket. An adversary may
+delete a log bucket to evade detection.
+"""
+false_positives = [
+    """
+    Logging bucket 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. Logging 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 Logging 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 Logging Bucket Deletion
+
+In GCP, log buckets are essential for storing and organizing log data, crucial for monitoring and auditing activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, focusing on actions that indicate bucket removal. This helps security analysts quickly spot and respond to potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteBucket to confirm the deletion event and gather details such as the timestamp, user identity, and source IP address.
+- Investigate the user account associated with the event to determine if the action was authorized or if there are any signs of compromise, such as unusual login locations or times.
+- Check for any recent changes to log sinks that might indicate an attempt to stop log routing to the deleted bucket, which could suggest intentional evasion.
+- Assess the impact of the bucket deletion by identifying which logs were being routed to the bucket and determining if any critical log data might be lost or compromised.
+- Look for any correlated events or alerts around the same timeframe that might indicate a broader attack or unauthorized activity within the GCP environment.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may trigger bucket deletion events. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for log management might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on their service accounts or specific identifiers.
+- Testing environments often involve the creation and deletion of resources, including log buckets. Exclude events from these environments by using labels or project identifiers to differentiate them from production environments.
+- Scheduled cleanup jobs that remove old or unused buckets can generate false positives. Document these jobs and adjust the detection rule to ignore deletions occurring within their scheduled time frames.
+- Misconfigured log sinks that inadvertently delete buckets should be reviewed. Regularly audit and adjust sink configurations to ensure they align with intended log routing and retention policies.
+
+### Response and remediation
+
+- Immediately halt any ongoing log routing to the deleted bucket by deleting or modifying the log sinks associated with it to prevent further data loss.
+- Restore the deleted log bucket from its pending deletion state within the 7-day window to recover any logs that may still be routed to it.
+- Conduct a thorough review of IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions.
+- Implement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly.
+- Escalate the incident to the security operations team for further investigation and to determine if the deletion was part of a broader attack strategy.
+- Review and update incident response plans to include specific procedures for handling log bucket deletions and similar defense evasion tactics.
+- Consider enabling alerts for any future attempts to delete log buckets, ensuring rapid detection and response to potential threats.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/logging/docs/buckets", "https://cloud.google.com/logging/docs/storage"]
+risk_score = 47
+rule_id = "5663b693-0dea-4f2e-8275-f1ae5ff2de8e"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Log Auditing",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteBucket and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml

@@ -0,0 +1,94 @@
+[metadata]
+creation_date = "2020/09/18"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies a Logging sink deletion in Google Cloud Platform (GCP). Every time a log entry arrives, Logging compares the
+log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to
+the sink's export destination. An adversary may delete a Logging sink to evade detection.
+"""
+false_positives = [
+    """
+    Logging sink 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. Logging sink 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 Logging Sink 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 Logging Sink Deletion
+
+In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and storage. Adversaries may delete these sinks to prevent logs from being exported, thereby evading detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion tactics.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion.
+- Check the event.dataset:gcp.audit logs for any preceding or subsequent suspicious activities by the same user or service account, which might indicate a pattern of malicious behavior.
+- Investigate the event.outcome:success to confirm the deletion was successful and determine the impact on log monitoring and export capabilities.
+- Assess the context and timing of the deletion event to see if it coincides with other security alerts or incidents, which might suggest a coordinated attack.
+- Verify the permissions and roles assigned to the user or service account involved in the deletion to ensure they align with the principle of least privilege and identify any potential misconfigurations.
+
+### False positive analysis
+
+- Routine maintenance or configuration changes 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 tools used for managing logging configurations might inadvertently delete sinks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or service accounts.
+- Changes in project ownership or restructuring within the organization can lead to legitimate sink deletions. Document these organizational changes and adjust the monitoring rules to account for them, ensuring that alerts are only generated for unexpected deletions.
+- Test environments often undergo frequent changes, including sink deletions, which can result in false positives. Implement separate monitoring rules or exceptions for test environments to reduce noise in alerting.
+
+### Response and remediation
+
+- Immediately revoke access to the affected GCP project for any suspicious or unauthorized users identified in the audit logs to prevent further malicious activity.
+- Restore the deleted logging sink by recreating it with the original configuration to ensure that log entries are once again exported to the designated destination.
+- Conduct a thorough review of recent log entries and audit logs to identify any other unauthorized changes or suspicious activities that may have occurred around the time of the sink deletion.
+- Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query.
+- Escalate the incident to the security operations team for further investigation and to determine if the sink deletion is part of a larger attack campaign.
+- Review and update access controls and permissions for logging sink management to ensure that only authorized personnel have the ability to modify or delete sinks.
+- Consider enabling additional security features such as VPC Service Controls or Organization Policy constraints to provide an extra layer of protection against unauthorized modifications to logging configurations.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/logging/docs/export"]
+risk_score = 47
+rule_id = "51859fa0-d86b-4214-bf48-ebb30ed91305"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Log Auditing",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteSink and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2020/09/23"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship
+(Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A
+subscription is a named resource representing the stream of messages to be delivered to the subscribing application.
+"""
+false_positives = [
+    """
+    Subscription 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. Subscription 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 Pub/Sub Subscription 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 Pub/Sub Subscription Deletion
+
+Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between event producers and consumers. Subscriptions in Pub/Sub are crucial for message delivery to applications. Adversaries may delete subscriptions to disrupt communication, evade detection, or impair defenses. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.pubsub.v*.Subscriber.DeleteSubscription to identify the user or service account responsible for the deletion.
+- 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 subscription by examining the associated project and any related resources to understand the potential impact on the application or service.
+- Verify if the deletion aligns with any recent changes or maintenance activities within the organization to rule out legitimate actions.
+- Assess the permissions and roles assigned to the user or service account to ensure they are appropriate and not overly permissive, which could indicate a security risk.
+- Consult with the relevant application or service owners to confirm whether the subscription deletion was authorized and necessary.
+
+### False positive analysis
+
+- Routine maintenance activities by administrators may lead to subscription deletions that are not malicious. To manage this, create exceptions for known maintenance windows or specific admin accounts.
+- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
+- Development and testing environments often involve frequent creation and deletion of subscriptions. Exclude these environments from alerts by filtering based on project IDs or environment tags.
+- Subscription deletions as part of a resource cleanup process can be non-threatening. Document and exclude these processes by identifying patterns in the audit logs, such as specific user agents or IP addresses associated with cleanup operations.
+
+### Response and remediation
+
+- Immediately verify the legitimacy of the subscription deletion by contacting the responsible team or individual to confirm if the action was authorized.
+- If unauthorized, revoke access for the user or service account involved in the deletion to prevent further unauthorized actions.
+- Restore the deleted subscription from backup or recreate it if necessary, ensuring that message delivery to the application is resumed.
+- Conduct a thorough review of audit logs to identify any other suspicious activities or patterns that may indicate further compromise.
+- Implement additional access controls and monitoring for Pub/Sub resources to prevent unauthorized deletions in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were affected.
+- Update incident response plans and playbooks to include specific procedures for handling Pub/Sub subscription deletions and similar threats.
+
+## Setup
+
+The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
+references = ["https://cloud.google.com/pubsub/docs/overview"]
+risk_score = 21
+rule_id = "cc89312d-6f47-48e4-a87c-4977bd4633c3"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Log Auditing",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.DeleteSubscription and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2020/09/18"
+integration = ["gcp"]
+maturity = "production"
+updated_date = "2025/01/15"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship
+(Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A publisher
+application creates and sends messages to a topic. Deleting a topic can interrupt message flow in the Pub/Sub pipeline.
+"""
+false_positives = [
+    """
+    Topic 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. Topic 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 Pub/Sub Topic 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 Pub/Sub Topic Deletion
+
+Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing applications to communicate by publishing messages to topics. Deleting a topic can disrupt this communication, potentially as a tactic for defense evasion. Adversaries might exploit this by deleting topics to impair defenses or hide their tracks. The detection rule monitors audit logs for successful topic deletions, flagging potential misuse for further investigation.
+
+### Possible investigation steps
+
+- Review the audit logs for the specific event.action: google.pubsub.v*.Publisher.DeleteTopic to identify the exact time and user or service account responsible for the deletion.
+- Investigate the event.dataset:gcp.audit logs around the same timeframe to identify any related activities or anomalies that might indicate malicious intent or unauthorized access.
+- Check the event.outcome:success to confirm the deletion was completed successfully and correlate it with any reported service disruptions or issues in the affected applications.
+- Assess the permissions and roles of the user or service account involved in the deletion to determine if they had legitimate access and reasons for performing this action.
+- Contact the user or team responsible for the deletion to verify if the action was intentional and authorized, and gather any additional context or justification for the deletion.
+- Review any recent changes in IAM policies or configurations that might have inadvertently allowed unauthorized topic deletions.
+
+### False positive analysis
+
+- Routine maintenance or updates by administrators can lead to legitimate topic deletions. To manage this, create exceptions for known maintenance periods or specific admin accounts.
+- Automated scripts or tools that manage Pub/Sub topics might delete topics as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers.
+- Development and testing environments often involve frequent topic creation and deletion. Exclude these environments from monitoring by filtering based on project IDs or environment tags.
+- Scheduled clean-up jobs that remove unused or temporary topics can trigger false positives. Document these jobs and adjust the detection rule to ignore deletions occurring during their execution times.
+- Changes in project requirements or architecture might necessitate topic deletions. Ensure that such changes are communicated and documented, allowing for temporary exceptions during the transition period.
+
+### Response and remediation
+
+- Immediately assess the impact of the topic deletion by identifying affected services and applications that rely on the deleted topic for message flow.
+- Restore the deleted topic from backup if available, or recreate the topic with the same configuration to resume normal operations.
+- Notify relevant stakeholders, including application owners and security teams, about the incident and potential service disruptions.
+- Review access logs and permissions to identify unauthorized access or privilege escalation that may have led to the topic deletion.
+- Implement stricter access controls and permissions for Pub/Sub topics to prevent unauthorized deletions in the future.
+- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the deletion is part of a larger attack pattern.
+- Enhance monitoring and alerting for Pub/Sub topic deletions to ensure rapid detection and response to 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/pubsub/docs/overview"]
+risk_score = 21
+rule_id = "3202e172-01b1-4738-a932-d024c514ba72"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: GCP",
+    "Data Source: Google Cloud Platform",
+    "Use Case: Log Auditing",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.DeleteTopic and event.outcome:success
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+