gcp-monitoring-delete-notification-channel

Principal can delete or modify Cloud Monitoring notification channels (monitoring.notificationChannels.delete / monitoring.notificationChannels.update), ensuring that even when an alert policy fires its notifications are not delivered - a defense-evasion primitive that does not grant resource access.

derived gcp emits CanModifyConfiguration

match

A conjunctive graph pattern. Variables (?x) bind node ids; every clause must hold.

{'principal': None} HasPermission {'monitoring': None}

where

node_type(?monitoring) == LoggingService node_class(?monitoring) == ManagementService ?monitoring.provider_type == 'google.monitoring.Workspace' ?principal has EFFECTIVE monitoring.notificationChannels.delete OR monitoring.notificationChannels.update on ?monitoring (project scope)

emit

source type	`Identity`
target type	`LoggingService`
source	`?principal`
target	`?monitoring`
permissions	`monitoring.notificationChannels.delete` `monitoring.notificationChannels.update`
conditions	`iam_permission` `api_enabled`
state logic	ACTIVE if monitoring.notificationChannels.delete or monitoring.notificationChannels.update is in the principal's effective IAM grants for the project scope and the Cloud Monitoring API is enabled; BLOCKED if an IAM deny policy or org policy denies both actions; CONDITIONAL(api_enabled) if Cloud Monitoring API enablement is unknown.

Narrative

{principal.name} can delete or modify Cloud Monitoring notification channels in project {monitoring.project} (monitoring.notificationChannels.delete / monitoring.notificationChannels.update). Deleting all notification channels for an alert policy means that when the policy fires an incident, no on-call engineer, PagerDuty integration, Slack webhook, or Pub/Sub subscriber receives the notification. Updating a channel endpoint to an attacker-controlled address is a subtler variant: alert metadata continues flowing but reaches the attacker, not the defender. Neither action grants access to any GCP resource - this is a defense-evasion / cover-tracks primitive.

Raw rule rules/derived/gcp/monitoring.yaml

id: gcp-monitoring-delete-notification-channel
emits: CanModifyConfiguration
description: "Principal can delete or modify Cloud Monitoring notification channels (monitoring.notificationChannels.delete\
  \ / monitoring.notificationChannels.update), ensuring that even when an alert policy fires its notifications\
  \ are not delivered \u2014 a defense-evasion primitive that does not grant resource access."
match:
- - principal: null
  - HasPermission
  - monitoring: null
where:
- node_type(?monitoring) == LoggingService
- node_class(?monitoring) == ManagementService
- ?monitoring.provider_type == 'google.monitoring.Workspace'
- ?principal has EFFECTIVE monitoring.notificationChannels.delete OR monitoring.notificationChannels.update
  on ?monitoring (project scope)
emit:
  source_type: Identity
  target_type: LoggingService
  source: ?principal
  target: ?monitoring
  permissions:
  - monitoring.notificationChannels.delete
  - monitoring.notificationChannels.update
  conditions:
  - iam_permission
  - api_enabled
  state_logic: ACTIVE if monitoring.notificationChannels.delete or monitoring.notificationChannels.update
    is in the principal's effective IAM grants for the project scope and the Cloud Monitoring API is enabled;
    BLOCKED if an IAM deny policy or org policy denies both actions; CONDITIONAL(api_enabled) if Cloud
    Monitoring API enablement is unknown.
  confidence: 0.88
  derived_from:
  - ?principal HasPermission ?monitoring (monitoring.notificationChannels.delete or monitoring.notificationChannels.update
    effective)
  false_positive_note: "Notification channels are the delivery mechanism for alert firings \u2014 they\
    \ are a DETECTIVE control component, not a preventive guardrail. Destroying them does not set BLOCKED\
    \ on any graph edge; it reduces the probability that attacker activity triggers an on-call response.\
    \ Do NOT chain to CanExecuteAs or CanEnterProject. monitoring.notificationChannels.update is a subtler\
    \ evasion than deletion: it can redirect notifications to an attacker-controlled Pub/Sub topic, email,\
    \ or webhook, capturing alert metadata without producing visible operational noise. Both actions are\
    \ captured here because the security impact (silencing notification delivery) is equivalent. A Pub/Sub-\
    \ backed notification channel changed to an attacker-controlled topic does NOT enable code execution\
    \ in Monitoring itself \u2014 any downstream Pub/Sub subscriber execution is modeled in pubsub.yaml.\
    \ Verify effective grants at the project level; roles/monitoring.viewer does not grant either action."
  narrative: "{principal.name} can delete or modify Cloud Monitoring notification channels in project\
    \ {monitoring.project} (monitoring.notificationChannels.delete / monitoring.notificationChannels.update).\
    \ Deleting all notification channels for an alert policy means that when the policy fires an incident,\
    \ no on-call engineer, PagerDuty integration, Slack webhook, or Pub/Sub subscriber receives the notification.\
    \ Updating a channel endpoint to an attacker-controlled address is a subtler variant: alert metadata\
    \ continues flowing but reaches the attacker, not the defender. Neither action grants access to any\
    \ GCP resource \u2014 this is a defense-evasion / cover-tracks primitive."