Last reviewed:
How to map Security Command Center findings, Cloud Audit Logs and Google SecOps detections to ATT&CK techniques without treating GCP like renamed AWS.
GCP detection coverage starts with three different kinds of evidence. Security Command Center findings describe security events and risky assets. Cloud Audit Logs record control-plane activity. Google SecOps detections describe SIEM-side rules built on the logs you forward into SecOps.
Keep those families separate when you map them to ATT&CK. A Security Command Center Event Threat Detection finding and a raw audit-log entry can both point at Valid Accounts, but they do not give an analyst the same proof. One says a managed service raised a finding. The other says a principal called an API.
Security Command Center is the closest GCP match for a managed cloud finding inventory. It aggregates findings from Event Threat Detection, Container Threat Detection, VM Threat Detection, Sensitive Data Protection, Web Security Scanner and partner sources. Each finding has a category, severity, affected resource and source name.
Map by finding category and source, not by severity alone. Severity changes with vendor tuning and tenant context. The behaviour behind the finding is the part that belongs in the ATT&CK map. A suspicious service-account activity finding may support Valid Accounts. A public storage exposure finding may be context for Collection or Exfiltration, but it is not proof that data left the account.
Cloud Audit Logs show who called which Google Cloud API, from where, against which resource. Admin Activity logs are on by default for most services. Data Access logs are noisier and often need explicit enablement. That split matters for coverage: a technique may look covered in a lab but vanish in production if the required log type is disabled.
Treat audit logs as the ground truth for control-plane behaviour. IAM binding changes, service-account key creation, logging sink edits, firewall-rule changes and storage-bucket policy changes all map cleanly to ATT&CK techniques when the operation name and target resource are preserved.
Google SecOps detections sit one layer above the cloud logs. They may use YARA-L rules, default curated detections, imported Sigma conversions or customer-authored logic. The ATT&CK mapping should attach to the rule intent and the data it reads, not only to the rule name.
This is where GCP coverage can become comparable with AWS and Azure. Security Command Center covers managed findings. Audit logs cover the control plane. SecOps rules cover the tenant-specific detections your team has chosen to run. DCV keeps those sources visible so a coverage score can say what is native, what is SIEM-side and what still needs work.
def gcp_evidence_kind(source):
if source in {'SCC_ETD', 'SCC_CONTAINER_THREAT_DETECTION'}:
return 'managed-finding'
if source in {'CLOUD_AUDIT_ADMIN', 'CLOUD_AUDIT_DATA'}:
return 'audit-log-evidence'
if source == 'GOOGLE_SECOPS_RULE':
return 'siem-detection'
return 'needs-review'