GCP Pub/Sub Topic Deletion

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.

Elastic rule (View on GitHub)

 1[metadata]
 2creation_date = "2020/09/18"
 3integration = ["gcp"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies the deletion of a topic in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship
11(Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A publisher
12application creates and sends messages to a topic. Deleting a topic can interrupt message flow in the Pub/Sub pipeline.
13"""
14false_positives = [
15    """
16    Topic deletions may be done by a system or network administrator. Verify whether the user email, resource name,
17    and/or hostname should be making changes in your environment. Topic deletions by unfamiliar users or hosts should be
18    investigated. If known behavior is causing false positives, it can be exempted from the rule.
19    """,
20]
21index = ["filebeat-*", "logs-gcp*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "GCP Pub/Sub Topic Deletion"
25note = """## Triage and analysis
26
27> **Disclaimer**:
28> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
29
30### Investigating GCP Pub/Sub Topic Deletion
31
32Google 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.
33
34### Possible investigation steps
35
36- 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.
37- 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.
38- 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.
39- 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.
40- 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.
41- Review any recent changes in IAM policies or configurations that might have inadvertently allowed unauthorized topic deletions.
42
43### False positive analysis
44
45- 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.
46- 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.
47- 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.
48- 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.
49- 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.
50
51### Response and remediation
52
53- Immediately assess the impact of the topic deletion by identifying affected services and applications that rely on the deleted topic for message flow.
54- Restore the deleted topic from backup if available, or recreate the topic with the same configuration to resume normal operations.
55- Notify relevant stakeholders, including application owners and security teams, about the incident and potential service disruptions.
56- Review access logs and permissions to identify unauthorized access or privilege escalation that may have led to the topic deletion.
57- Implement stricter access controls and permissions for Pub/Sub topics to prevent unauthorized deletions in the future.
58- 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.
59- Enhance monitoring and alerting for Pub/Sub topic deletions to ensure rapid detection and response to similar incidents in the future.
60
61## Setup
62
63The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
64references = ["https://cloud.google.com/pubsub/docs/overview"]
65risk_score = 21
66rule_id = "3202e172-01b1-4738-a932-d024c514ba72"
67severity = "low"
68tags = [
69    "Domain: Cloud",
70    "Data Source: GCP",
71    "Data Source: Google Cloud Platform",
72    "Use Case: Log Auditing",
73    "Tactic: Defense Evasion",
74    "Resources: Investigation Guide",
75]
76timestamp_override = "event.ingested"
77type = "query"
78
79query = '''
80event.dataset:gcp.audit and event.action:google.pubsub.v*.Publisher.DeleteTopic and event.outcome:success
81'''
82
83
84[[rule.threat]]
85framework = "MITRE ATT&CK"
86[[rule.threat.technique]]
87id = "T1562"
88name = "Impair Defenses"
89reference = "https://attack.mitre.org/techniques/T1562/"
90
91
92[rule.threat.tactic]
93id = "TA0005"
94name = "Defense Evasion"
95reference = "https://attack.mitre.org/tactics/TA0005/"
...
toml

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.

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.

  • 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.
  • 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.
  • 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.

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

References

Related rules

to-top