GCP Security Command Center Deployment: Security Health Analytics, Event Threat Detection, and SIEM Export
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
GCP Security Command Center at the Standard tier is a configuration scanner. It will tell you that a Cloud Storage bucket is public, that a firewall rule allows 0.0.0.0/0, and that a Cloud SQL instance has no root password. These are valuable findings, but they are passive — they describe what exists, not what is happening. A compromised GCP service account actively exfiltrating data to an attacker's bucket, a crypto miner running in a GKE pod, or an attacker who has added a new IAM role binding to maintain persistence are all active threats that the Standard tier will not detect.
GCP SCC Premium's Event Threat Detection changes this by analyzing Cloud Logging data against Google's threat intelligence in near-real time, generating findings within minutes of detecting indicators of compromise. Container Threat Detection extends this to GKE workload runtime — detecting the reverse shells and binary injection patterns that indicate a container has been compromised. Together these two Premium tier capabilities turn SCC from a compliance scanner into an active threat detection layer. The operational challenge is integrating SCC findings into the security operations workflow: exporting findings to Pub/Sub for SIEM ingestion, building remediation SLAs around finding severity, and configuring mute rules to suppress the accepted-risk misconfigurations that create noise.
Configuration: organization-level setup and findings triage workflow
Organization-level SCC setup is a one-time operation but the findings triage workflow is a recurring process that requires organizational commitment to be effective. Enabling SCC generates hundreds to thousands of findings on the first scan, particularly for organizations that have been running GCP without a security posture management tool. The initial triage involves distinguishing accepted-risk misconfigurations from genuine remediation priorities, configuring mute rules for the accepted risks, and establishing remediation SLAs for the genuine findings. Without this initial triage work, the findings queue grows faster than it is remediated and teams lose confidence in the tool.
Categorize initial SCC findings into three buckets: immediate remediation, scheduled remediation, and accepted risk (muted)
After the initial SCC scan, export all CRITICAL and HIGH findings to a spreadsheet using the SCC findings API or BigQuery export and assign each unique category/resource combination to one of three buckets. Immediate remediation (SLA: 7 days) covers CRITICAL findings on production resources: open firewall rules on production VPCs, public Cloud Storage buckets containing sensitive data, Cloud SQL instances with public IPs and no authorized networks restriction. Scheduled remediation (SLA: 30 days) covers HIGH findings on production resources and all findings on non-production resources. Accepted risk with mute rule covers findings where the configuration is intentional and the risk is documented: a public Cloud Storage bucket hosting a static website where public access is required, or a firewall rule allowing unrestricted egress from specific data processing nodes. Build mute rules for every accepted-risk finding immediately so that the active findings queue reflects only genuine remediation work.
Enable Event Threat Detection log sources for VPC Flow Logs and Cloud DNS before evaluating ETD finding quality
Event Threat Detection's detection quality depends on having the right Cloud Logging sources enabled. Before evaluating ETD findings, enable VPC Flow Logs on all production VPC subnets (required for network-based detectors like Exfiltration and Malware), enable Cloud DNS logging on all Cloud DNS policies (required for DNS-based C2 detection), and enable Data Access audit logs for Cloud Storage and BigQuery (required for Exfiltration detectors that analyze data access patterns). Without these log sources enabled, ETD will generate findings only from the Admin Activity logs that are always enabled, missing the network and data access telemetry that the highest-value threat detectors require. After enabling all required log sources, allow 24-48 hours for ETD to establish behavioral baselines before treating the absence of findings as confirmation that no threats exist.
Integration: SIEM export and response workflow
SCC findings sitting in the GCP console are not actionable at security operations speed. Integrating SCC findings into the SIEM via Pub/Sub export makes them visible alongside other security events, enables correlation with network and endpoint data, and routes alerts to on-call responders via the same paging workflows used for other security incidents. The integration also solves the retention problem: SCC retains findings for a limited period, while BigQuery or SIEM storage provides long-term retention for compliance and trend analysis.
Build a finding severity-to-response-tier mapping before configuring Pub/Sub alert routing
Define the expected response behavior for each SCC finding severity before configuring Pub/Sub alert routing, so that the routing configuration enforces the policy rather than requiring analyst discretion. CRITICAL findings (active threats from Event Threat Detection: reverse shell, credential access, data exfiltration) route to on-call via PagerDuty with a 15-minute acknowledgment SLA. HIGH findings (Security Health Analytics: open firewall rules, public buckets) route to a ticketing system with a 24-hour acknowledgment SLA. MEDIUM and LOW findings route to a daily digest or scheduled ticket review with no on-call component. Implement this routing using a Pub/Sub subscription filter that splits findings to different downstream destinations based on the finding's severity field, or use a Cloud Function that evaluates the finding severity and routes accordingly. Hardcoding the routing policy in infrastructure means it cannot be bypassed by individual analyst decisions to ignore high-severity findings during busy periods.
Create a BigQuery dashboard for recurring security posture reviews using SCC continuous export data
Configure SCC continuous export to BigQuery and build a recurring security posture dashboard in Looker Studio that tracks finding remediation velocity alongside open finding counts by severity. The key metrics for each review cycle: new CRITICAL/HIGH findings created in the period (leading indicator of new issues), CRITICAL/HIGH findings closed in the period (remediation throughput), ACTIVE CRITICAL/HIGH finding count trend over 30 days (is the posture improving or degrading?), and oldest ACTIVE CRITICAL finding by creation date (how long is the longest-standing critical issue open?). A degrading trend line on the active critical finding count means more findings are added each period than closed — the early signal that remediation capacity is insufficient and teams need either engineering resources or a re-evaluation of the SCC scope to ensure only in-scope production resources are generating findings requiring immediate remediation.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
GCP Security Command Center provides cloud-native security posture management and threat detection that covers the GCP-specific attack paths (IAM misconfiguration, public resource exposure, cloud-native service compromise) that generic SIEM tools without GCP context routinely miss. Enable SCC at the organization level for unified cross-project visibility. Upgrade to the Premium tier for Event Threat Detection and Container Threat Detection — the Standard tier's passive configuration scanning is insufficient for environments with active production workloads. Export findings to Pub/Sub for SIEM integration and BigQuery for long-term retention. Configure mute rules for accepted-risk findings to keep the active queue focused on genuine remediation priorities. Establish severity-based response SLAs and build a recurring BigQuery dashboard to track posture trends. SCC is the control plane for GCP security operations; the investment in initial setup and workflow integration pays in reduced cloud-native threat detection blind spots.
Frequently asked questions
How do I enable GCP Security Command Center at the organization level?
Enable Security Command Center at the organization level rather than the project level to get a unified view of findings across all GCP projects under the organization. In the GCP console, navigate to Security > Security Command Center and click Enable for the organization — you need the Organization Admin role (roles/resourcemanager.organizationAdmin) to enable at the organization level. During enablement, select the service tier: Standard (free, covers Security Health Analytics and Web Security Scanner basic) or Premium (paid, adds Event Threat Detection, Container Threat Detection, VM Threat Detection, and Web Security Scanner full). The initial SCC scan after enablement takes 6-24 hours to assess all organization resources. Organization-level SCC is strongly preferred over project-level because it centralizes all findings in one location, enables cross-project finding correlation, and allows you to configure organization-wide mute rules and notification settings from a single configuration pane. After enablement, the Security Command Center dashboard shows the organization's total finding counts by severity and category across all projects.
What does Security Health Analytics detect and how do I remediate its findings?
Security Health Analytics continuously monitors GCP resource configurations and flags deviations from security best practices as findings in SCC. Key finding categories: OPEN_FIREWALL detects VPC firewall rules allowing unrestricted inbound traffic on sensitive ports (SSH on 0.0.0.0/0, RDP on 0.0.0.0/0, all traffic on 0.0.0.0/0) and the remediation is to restrict the source range to specific IP ranges; PUBLIC_BUCKET_ACL detects Cloud Storage buckets with allUsers or allAuthenticatedUsers IAM bindings (public access) and the remediation is to remove the public IAM binding; SQL_NO_ROOT_PASSWORD detects Cloud SQL instances without a root password set; KMS_KEY_NOT_ROTATED detects Cloud KMS keys that have not been rotated in over 90 days; LEGACY_AUTHORIZATION_ENABLED detects GKE clusters with legacy ABAC authorization enabled instead of RBAC. Each finding in the SCC console includes a description of the issue, its severity, the affected resource, and a remediation step. Filter findings by ACTIVE state and CRITICAL or HIGH severity to prioritize the highest-risk misconfigurations for immediate remediation.
How do I configure SCC findings export to a SIEM using Pub/Sub?
Export SCC findings to a SIEM in real time using the Pub/Sub notification export. In the SCC console, navigate to Settings > Notifications and create a new notification configuration: select the organization or specific project scope, set a filter expression to control which findings are exported (e.g., severity=HIGH OR severity=CRITICAL to export only high-priority findings), and select a Pub/Sub topic as the destination. Create the Pub/Sub topic first in the GCP console under Pub/Sub > Topics. SCC publishes a JSON finding notification message to the topic within seconds of detecting a new finding or a finding state change. Configure your SIEM to consume from the Pub/Sub subscription: Splunk uses the Pub/Sub Add-on, Elastic uses the GCP Pub/Sub input, and Chronicle has a native SCC integration that automatically ingests findings. For SIEM platforms without native Pub/Sub integration, deploy a Cloud Function that triggers on Pub/Sub messages and forwards the finding JSON to the SIEM's HTTP Event Collector or API endpoint.
How does Event Threat Detection work and what threat categories does it cover?
Event Threat Detection (ETD) analyzes Cloud Logging data in near-real time using Google's threat intelligence feeds, machine learning models, and rule-based detectors to identify active threats across your GCP environment. ETD ingests data from Cloud Audit Logs, Cloud DNS logs, VPC Flow Logs, HTTP load balancer logs, and Google Workspace logs (if integrated) and runs detectors against this data stream. The detector categories map to MITRE ATT&CK: Initial Access detectors catch credential compromise indicators like access from unusual geolocations and login from known-malicious IPs; Persistence detectors catch backdoor creation like new service account keys created for privileged accounts; Privilege Escalation detectors catch unexpected role bindings granting admin access; Defense Evasion detectors catch logging disabled events and audit log deletion; Credential Access detectors catch credential enumeration via service account key listing; Exfiltration detectors catch unusual data transfer patterns from Cloud Storage; and Malware detectors catch communication with known-malicious IP addresses from GCP Compute instances. ETD findings appear in SCC within minutes of the triggering event in Cloud Logging.
How do I use mute rules to reduce SCC finding noise from accepted-risk configurations?
Configure mute rules in SCC to suppress recurring findings that represent accepted risks or known false positives in your environment, preventing them from consuming analyst time and inflating finding counts. In the SCC console under Mute Configurations, create a mute rule with a filter expression that matches the specific finding type, resource, and any additional conditions: for example, mute OPEN_FIREWALL findings on specifically named firewall rules that are intentionally public-facing, or mute specific Security Health Analytics detector findings on development project resources that are not in scope for production security standards. Mute rules set future matching findings to MUTED state automatically, so they do not appear in the default active findings view. Use the most specific filter expressions possible to avoid accidentally muting legitimate findings: target specific resource names, specific detector names, and specific project IDs rather than broad category mutes. Review all mute rules quarterly and remove rules for risks that have been remediated or whose acceptance rationale is no longer valid.
How do I export SCC findings to BigQuery for long-term retention and analysis?
Export SCC findings to BigQuery using SCC's continuous export feature, which automatically streams all new and updated findings to a BigQuery dataset for long-term retention and SQL-based analysis. In the SCC console, navigate to Settings > Continuous export and create a new BigQuery export: select the organization scope, specify the BigQuery dataset (create it first in the BigQuery console in a project designated for security data), and optionally add a filter to export only specific finding types or severities. SCC creates the BigQuery table schema automatically and streams finding records to BigQuery within minutes of detection. Once in BigQuery, you can run SQL queries against the findings table for compliance reporting, trend analysis, and SIEM enrichment: SELECT category, count(*) as finding_count FROM scc_findings.findings WHERE state='ACTIVE' AND severity IN ('CRITICAL', 'HIGH') GROUP BY category ORDER BY finding_count DESC provides a breakdown of active high-severity findings by category. Connect BigQuery to Looker Studio for visual security dashboards that track finding remediation velocity and posture trends over time.
How do I integrate Container Threat Detection with GKE for runtime security?
Container Threat Detection (CTD) provides runtime security monitoring for GKE clusters by analyzing container behavior at the kernel level using Google-managed node agents deployed to GKE nodes automatically when SCC Premium is enabled and CTD is active for the project. CTD detects: added_binary_executed (a binary not present in the original container image was executed at runtime, indicating container escape or malware dropped by an attacker), added_library_loaded (a shared library not in the original image was loaded, indicating in-memory injection), reverse_shell (a process in a container established a network connection to an external IP and attached a shell, the classic container compromise indicator), and unexpected_child_process (a container process spawned an unexpected child process that is not part of normal container behavior). CTD findings appear in SCC within seconds of the runtime event and include the cluster name, namespace, pod name, container name, process name, and command line of the suspicious activity. Connect CTD findings to PagerDuty or equivalent on-call tooling via Pub/Sub export for immediate incident response on reverse shell and added binary findings.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.