Google Cloud — Security Command Center

Security Command Center (SCC) is GCP's centralized security and risk management platform. It provides visibility into your cloud assets, detects misconfigurations and vulnerabilities, and surfaces active threats. As organizations adopt multi-project architectures, SCC becomes essential for maintaining a unified security posture across the entire organization.

Why Security Command Center Exists

Google Cloud Security Command Center (SCC) is not a dashboard you open once a quarter. It's a continuous monitoring and risk assessment platform that aggregates findings from over 150 Google-managed services and third-party integrations. In production, we've seen teams treat SCC as a passive report generator, only to miss active exfiltration because they never configured real-time notifications. SCC's value is in its ability to surface misconfigurations, vulnerabilities, and threats in near real-time, but only if you wire it into your incident response pipeline. Without proper integration, SCC becomes a noise generator. The platform supports two tiers: Standard (free, limited to asset inventory and basic findings) and Premium (paid, adds threat detection, event threat detection, and container threat detection). For any production environment handling sensitive data, Premium is non-negotiable. The cost is trivial compared to the cost of a breach.

gcloud services enable securitycenter.googleapis.com

gcloud scc notifications create my-notification \
    --organization=123456789012 \
    --description="Critical findings to Pub/Sub" \
    --pubsub-topic=projects/my-project/topics/scc-alerts \
    --filter="severity=\"CRITICAL\" OR severity=\"HIGH\""

gcloud scc mute-configs create auto-mute-low \
    --organization=123456789012 \
    --description="Mute low severity findings" \
    --filter="severity=\"LOW\""

Asset Discovery and Inventory Management

SCC automatically discovers and inventories all Google Cloud resources within your organization, including projects, folders, Compute Engine instances, Cloud Storage buckets, and IAM policies. This inventory is the foundation for all security analysis. However, the default discovery can be slow—up to 24 hours for new resources. In production, we force a rescan after provisioning critical infrastructure using the API. Asset inventory also surfaces relationships, like which service accounts have access to which buckets, which is invaluable for attack path analysis. One common pitfall is that SCC does not discover resources in projects that are not part of the organization hierarchy. Ensure all projects are under the organization node. Also, note that asset inventory is updated every 12-24 hours by default; for real-time needs, use the Asset Inventory API directly with a watcher.

from google.cloud import securitycenter
from google.cloud.securitycenter_v1.types import RunAssetDiscoveryRequest

client = securitycenter.SecurityCenterClient()
organization_name = f"organizations/123456789012"

request = RunAssetDiscoveryRequest(parent=organization_name)
operation = client.run_asset_discovery(request=request)
print(f"Started asset discovery: {operation.operation.name}")

# Wait for completion
operation.result()
print("Asset discovery completed.")

Understanding Findings and Severity Levels

Findings are the core of SCC—they represent potential security issues detected by various services. Each finding has a severity (CRITICAL, HIGH, MEDIUM, LOW), a category (e.g., OPEN_BUCKET, WEAK_SSL, MALWARE), and a source (e.g., Security Health Analytics, Event Threat Detection, Container Threat Detection). In production, the volume of findings can be overwhelming. We mute LOW and MEDIUM findings that are known false positives (e.g., a test bucket that is intentionally public). But never mute CRITICAL or HIGH without a documented exception. Findings also have a state (ACTIVE, INACTIVE) and can be marked as resolved. Use the mute feature to reduce noise, but ensure you have a process to periodically review muted findings. The SCC API allows you to list, update, and set mute configurations programmatically, which is essential for automation.

from google.cloud import securitycenter

client = securitycenter.SecurityCenterClient()
parent = f"organizations/123456789012/sources/-/findings"

request = {
    "parent": parent,
    "filter": "severity=CRITICAL AND state=ACTIVE",
    "page_size": 100
}

for finding in client.list_findings(request=request):
    print(f"Finding: {finding.name}")
    print(f"  Category: {finding.category}")
    print(f"  Resource: {finding.resource_name}")
    print(f"  Event Time: {finding.event_time}")
    print("---")

Security Health Analytics: Misconfiguration Detection

Security Health Analytics (SHA) is the built-in scanner that checks your cloud resources against Google's security best practices. It covers over 150 detectors, including open firewall ports, public buckets, IAM role misuse, and encryption settings. SHA runs continuously and generates findings when it detects violations. In production, we've found that SHA is excellent for catching low-hanging fruit like public buckets or overly permissive firewall rules. However, it has limitations: it cannot detect custom misconfigurations (e.g., a specific IAM role that violates your internal policy). For that, you need custom detectors via Event Threat Detection or third-party tools. SHA findings are categorized by severity, but we've seen MEDIUM findings that are actually critical in context (e.g., a firewall rule allowing SSH from 0.0.0.0/0 on a bastion host). Always review findings in context.

gcloud scc findings list \
    --organization=123456789012 \
    --source=security_health_analytics \
    --filter="severity=HIGH AND category=OPEN_FIREWALL" \
    --format="json"

Event Threat Detection: Real-Time Threat Monitoring

Event Threat Detection (ETD) monitors your cloud logs in real time for suspicious activity, such as malware, cryptocurrency mining, and data exfiltration. It uses machine learning and threat intelligence to detect anomalies. ETD is a Premium-tier feature and requires enabling log export to a BigQuery dataset or Pub/Sub. In production, ETD is your first line of defense against active attacks. However, it generates a high volume of alerts, many of which are benign (e.g., a developer running a script that downloads a known malware sample for testing). We've learned to create suppression rules for known good activities. ETD also supports custom threat detection using YARA rules, which is powerful for detecting proprietary malware. One critical configuration: ensure ETD is enabled for all projects in the organization, not just a subset. Attackers often pivot to less monitored projects.

gcloud services enable eventthreatdetection.googleapis.com \
    --organization=123456789012

gcloud scc settings enable \
    --organization=123456789012 \
    --service=event_threat_detection

# Create a suppression rule for a known false positive
gcloud scc etd suppression-rules create \
    --organization=123456789012 \
    --name="suppress-test-malware" \
    --description="Suppress malware detection for test VMs" \
    --filter="resource.labels.instance_id=1234567890"

Container Threat Detection: Securing GKE Workloads

Container Threat Detection (CTD) monitors your Google Kubernetes Engine (GKE) clusters for threats at the container and node level. It detects privilege escalation, malicious binaries, and suspicious network connections. CTD is a Premium feature and requires the Security Command Center API to be enabled on the cluster. In production, CTD is essential for any GKE cluster running untrusted workloads. However, it has a performance impact—it runs as a DaemonSet on each node. We've seen teams disable CTD on clusters with high resource utilization, which is a mistake. Instead, allocate additional resources to the node pool. CTD also integrates with GKE's audit logging to provide context. One common issue: CTD may flag legitimate administrative tools like kubectl exec as suspicious. Tune the sensitivity or create exceptions for known admin activities.

gcloud container clusters update my-cluster \
    --region=us-central1 \
    --enable-security-posture \
    --enable-workload-vulnerability-scanning

gcloud scc settings enable \
    --organization=123456789012 \
    --service=container_threat_detection

# Verify CTD is running
kubectl get pods -n kube-system | grep security

Automating Remediation with Cloud Functions and SCC API

SCC findings are only useful if you act on them. In production, we automate remediation using Cloud Functions triggered by Pub/Sub notifications from SCC. For example, when a finding of type OPEN_BUCKET is created, a Cloud Function can automatically make the bucket private. However, automation must be careful: not all public buckets are misconfigurations. We use a tagging strategy: buckets with label 'public-allowed=true' are exempt. The SCC API allows you to update findings (e.g., mark as resolved) and mute them. We also automate the creation of mute rules for known false positives. The key is to have a feedback loop: if an automated remediation fails, it should create a new finding or alert. This pattern reduces mean time to remediation (MTTR) from days to minutes.

import base64
import json
from google.cloud import storage
from google.cloud import securitycenter

def remediate_open_bucket(event, context):
    pubsub_message = base64.b64decode(event['data']).decode('utf-8')
    finding = json.loads(pubsub_message)
    
    if finding['category'] != 'OPEN_BUCKET':
        return
    
    bucket_name = finding['resource_name'].split('/')[-1]
    
    storage_client = storage.Client()
    bucket = storage_client.get_bucket(bucket_name)
    
    # Check for exemption label
    if bucket.labels.get('public-allowed') == 'true':
        print(f"Bucket {bucket_name} is exempted. Skipping.")
        return
    
    # Make bucket private
    bucket.iam_configuration.public_access_prevention = 'enforced'
    bucket.patch()
    print(f"Remediated bucket {bucket_name}: enforced public access prevention.")
    
    # Update finding state to resolved
    scc_client = securitycenter.SecurityCenterClient()
    finding_name = finding['name']
    scc_client.update_finding({
        'finding': {
            'name': finding_name,
            'state': 'INACTIVE'
        },
        'update_mask': {'paths': ['state']}
    })

Integrating SCC with SIEM and Incident Response

SCC findings should feed into your existing SIEM (e.g., Splunk, Chronicle) and incident response platform (e.g., Jira, PagerDuty). The recommended approach is to export findings to Pub/Sub, then use a subscriber to forward them. In production, we've seen teams pipe all findings directly to PagerDuty, causing alert fatigue. Instead, filter by severity and category. For example, only CRITICAL findings go to PagerDuty; HIGH findings go to a Slack channel; MEDIUM and LOW go to a weekly report. Also, enrich findings with context from your CMDB (e.g., resource owner, environment). This reduces time to triage. One advanced pattern: use SCC's findings as triggers for automated playbooks in your SOAR platform. For example, a CRITICAL finding for a compromised VM could trigger an automatic isolation of the VM.

import base64
import json
import requests

def forward_to_siem(event, context):
    pubsub_message = base64.b64decode(event['data']).decode('utf-8')
    finding = json.loads(pubsub_message)
    
    # Enrich with resource owner from CMDB
    resource_name = finding['resource_name']
    owner = get_owner_from_cmdb(resource_name)  # hypothetical
    finding['owner'] = owner
    
    # Forward to SIEM
    siem_url = "https://siem.example.com/api/events"
    headers = {"Authorization": "Bearer YOUR_TOKEN"}
    response = requests.post(siem_url, json=finding, headers=headers)
    response.raise_for_status()
    print(f"Forwarded finding {finding['name']} to SIEM.")

Cost Management and Optimization of SCC Premium

SCC Premium is priced per resource per month, with different rates for compute, storage, and other resources. In production, costs can escalate quickly if you have many projects. We've seen monthly bills of $10k+ for large organizations. To optimize, start by enabling SCC Premium only on projects that contain sensitive data or are production-facing. Use the SCC dashboard to monitor costs and identify which resources are driving charges. Also, consider using the Standard tier for development projects. Another cost-saving measure is to use mute rules to suppress findings that don't require Premium features (e.g., if you only need asset inventory, Standard may suffice). However, be careful: disabling Premium on a project also disables ETD and CTD, which are critical for security. We recommend a risk-based approach: classify projects into tiers (e.g., critical, high, medium, low) and enable Premium accordingly.

gcloud scc assets list \
    --organization=123456789012 \
    --format="json" | jq '[.[] | .asset_type] | group_by(.) | map({asset_type: .[0], count: length})'

Advanced: Custom Detectors and Threat Intelligence

SCC allows you to create custom detectors using YARA rules for ETD and custom modules for SHA. This is essential for detecting organization-specific threats, such as proprietary malware or policy violations. In production, we've built custom YARA rules to detect data exfiltration patterns unique to our application. However, custom detectors require careful tuning to avoid false positives. We recommend starting with a small set of rules and iterating based on feedback. Also, integrate SCC with external threat intelligence feeds (e.g., Recorded Future, VirusTotal) to enrich findings. This can be done via Cloud Functions that query the threat intel API and update the finding with additional context. One advanced pattern: use SCC's findings to trigger a Cloud Function that queries VirusTotal for file hashes and adds reputation data to the finding. This reduces investigation time.

rule CustomExfilPattern {
    meta:
        description = "Detect exfiltration of customer data"
        severity = "CRITICAL"
    strings:
        $customer_id = /CUST-[A-Z0-9]{10}/
        $exfil_domain = "dropbox.com"
    condition:
        all of them
}

Compliance Reporting and Audit Readiness

SCC provides built-in compliance reports for standards like CIS, PCI DSS, and NIST. These reports are generated from SHA findings and can be exported to BigQuery for custom analysis. In production, we use SCC to continuously monitor compliance posture and generate weekly reports for auditors. However, SCC's compliance coverage is not exhaustive. For example, it does not cover all PCI DSS requirements. We supplement with manual checks and third-party tools. One key feature is the ability to export findings to BigQuery, which allows you to run custom queries to demonstrate compliance. For example, you can query for all findings related to encryption at rest. We also use SCC's asset inventory to generate a list of all resources and their compliance status. This is invaluable during audits.

SELECT 
  resource_name,
  category,
  severity,
  event_time
FROM `my_project.scc_export.findings`
WHERE 
  category IN ('ENCRYPTION_NOT_ENABLED', 'WEAK_SSL')
  AND state = 'ACTIVE'
ORDER BY severity DESC;

Operational Runbook: Daily, Weekly, and Monthly Tasks

To keep SCC effective, establish a regular operational cadence. Daily: review CRITICAL and HIGH findings, triage new ones, and ensure automated remediation worked. Weekly: review muted findings to ensure they are still valid, update suppression rules, and check for new false positives. Monthly: review custom detectors, update YARA rules, and assess SCC costs. Also, conduct a quarterly review of SCC configuration: ensure all projects are covered, notification channels are working, and IAM permissions are correct. In production, we've seen teams neglect these tasks, leading to stale findings and missed threats. Automate as much as possible: use Cloud Scheduler to trigger weekly reports and send them to a Slack channel. The key is to make SCC a living part of your security operations, not a set-it-and-forget-it tool.

#!/bin/bash
# Generate weekly SCC findings report

REPORT_DATE=$(date +%Y-%m-%d)
REPORT_FILE="scc_weekly_report_$REPORT_DATE.csv"

gcloud scc findings list \
    --organization=123456789012 \
    --filter="state=ACTIVE" \
    --format="csv(name,category,severity,resource_name,event_time)" > $REPORT_FILE

gsutil cp $REPORT_FILE gs://my-reports-bucket/scc/

echo "Report uploaded: gs://my-reports-bucket/scc/$REPORT_FILE"