scc_notifications — version 1.2

Source: presets/scc/scc-notifications.satz

Purpose

Security Command Center findings, published to a Pub/Sub topic as they are raised — the piece downstream of enablement that every customer needs.

A NOTIFICATION IS A CHAIN, NOT A RESOURCE. Three things have to line up, and two of them are outside the notification config itself:

1. a Pub/Sub topic findings are published to;
2. SCC's notification service agent holding roles/securitycenter.notificationServiceAgent on THAT topic — without the grant the config is created and never publishes;
3. the notification config, which names the organisation, the topic and the filter that decides which findings travel.

The publisher is service-org-<organisation id>@gcp-sa-scc-notification.iam.gserviceaccount.com — the identity the config reports in its own serviceAccount field, not the security-center-api agent SCC activation creates. Security Command Center adds this binding itself when the config is created; the estate declares it anyway, because an access the estate depends on belongs in the estate, and _iam_member is not authoritative, so both writing it converge.

A domain-restricted organisation permits it: iam.managed.allowedPolicyMembers does not apply to Google-managed service agents (verified on a live organisation with that policy enforcing and this agent in no subject list).

The v2 resource is deliberate: the v1 notification API answers "This API is no longer available" on a live organisation.

WHAT THIS DOES NOT COVER. Enabling the detectors, which has no provider resource at all: presets/scc/scc-service-enablement.satz, an action. Use both — findings nobody raises are findings nobody publishes. Who reads the topic is the customer's: presets/scc/scc-findings-mail.satz subscribes to it and mails an address for an organisation that has no SIEM, and presets/scc/scc-export.satz keeps the findings in BigQuery. Not covered at all: mute configs, custom modules and Security Posture.

NO CLAIM. No catalog control covers Security Command Center, so this pack witnesses nothing and report-compliance says nothing about it.

Use it

params {
  // the pack's own defaults — copy only the lines you change
  scc_notification_topic_name = "{customer_shortname}-scc-findings"
  scc_notification_project = infra_project_name
  scc_notification_config_id = "satz-findings"
  scc_notification_description = "Active findings at HIGH and CRITICAL, published by Security Command Center"
  scc_notification_filter = "state="ACTIVE" AND (severity="HIGH" OR severity="CRITICAL")"
}

use "presets/scc/scc-notifications.satz"

Needs from outside the pack:

• customer_organization_id — declared by estate_core; use one of them alongside, or declare it in the estate.
• customer_shortname — declared by estate_core; use one of them alongside, or declare it in the estate.
• infra_project_name — declared by estate_core; use one of them alongside, or declare it in the estate.

Params

Questions

What to ask before this pack is configured, and what changing the answer costs.

scc_notification_project — Whoever can read the topic reads every finding in the organisation, including the ones that name a misconfiguration nobody has fixed yet. The infrastructure project keeps it with the other operational plumbing; a separate security project keeps it away from whoever administers workloads. Moving it later is a new topic, and a subscriber has to be repointed.

scc_notification_filter — Written in Security Command Center's filter language, not Cloud Logging's. Too wide and the topic is noise nobody reads; too narrow and a real finding never leaves the console. The default is active findings at HIGH and CRITICAL, which is what a duty roster can answer. Widening it later is an edit, and the findings already raised are not re-sent.

Contributes

Claims

None — this pack proves no control by itself.

History

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

Use it with scc_service_enablement: this pack decides where findings GO, that one decides whether any are raised. On its own it publishes an empty topic.

The order matters on a domain-restricted organisation. The grant here names SCC's notification service agent, which the CIS pack already lists in allowed_policy_member_subjects — so apply the CIS pack first, or the iam.managed.allowedPolicyMembers policy refuses the grant and the config publishes nothing while reporting no error.

The subscriber is the customer's own. A topic with no subscription keeps findings for its retention and drops them after, so attach the SIEM, the ticket system or the mail relay before treating the chain as live.