M ManySignal

Guide · ManySignal

GCP Security Monitoring Guide

Google Cloud's security telemetry is split across Cloud Audit Logs (Admin Activity, Data Access, System Events, Policy Denied), Security Command Center findings, VPC Flow Logs, and Cloud Armor. The GCP IAM model — with its project-folder-org hierarchy and workload identity federation — creates attack paths that are distinct from AWS and Azure and require GCP-specific detection logic.

MH Marcus Hale — Head of Detection Engineering
15 min read Published Jul 1, 2026 Download PDF
01

GCP telemetry sources and ingestion priority

Tier 1: Cloud Audit Logs — Admin Activity (always on, no cost) and Data Access (enable selectively for sensitive resources). Admin Activity covers IAM changes, project creation, service enablement, and resource deletion — the full control plane. Tier 2: Security Command Center findings, Cloud Armor logs for public-facing services. Tier 3: VPC Flow Logs for specific VPCs, Cloud Run and GKE audit logs.

Data Access logs for BigQuery are high-signal for exfiltration detection but high-volume. Enable them for datasets tagged with sensitive data classifications and use the ManySignal BigQuery connector with a volume-based sampling filter for read events.

  • Admin Activity logs: enabled at Org level via Log Sink to BigQuery or Pub/Sub
  • Data Access logs: enabled for sensitive datasets and GCS buckets only
  • Security Command Center Standard tier minimum; Premium for SCC findings
  • ManySignal GCP connector validated with test IAM change event
02

GCP IAM detection

GCP IAM bindings define who can do what on which resource. Critical detections: new Owner binding at Project or Org level, service account key creation for a service account with broad permissions, service account impersonation (iam.serviceAccounts.actAs) granted to an external identity, and Org policy change.

Workload identity federation is the preferred GCP authentication pattern for external workloads, but it introduces a new attack surface: external identity pool and provider configurations. Monitor changes to workload identity pools — a new attribute mapping that allows broader identity matching is a persistence technique.

# detections/gcp/org_owner_binding.yaml
key: gcp.org_owner_binding
domain: cloud_iam
severity: critical
type: streaming
where:
  class_uid: 3005
  source: gcp_audit_admin_activity
  method_name: "SetIamPolicy"
  resource_type: "cloudresourcemanager.googleapis.com/Organization"
graph:
  condition: new_role_binding_includes_roles/owner
attck:
  tactic: TA0004
  techniques: [T1098]
stage: active
03

BigQuery and GCS exfiltration detection

BigQuery is a high-value exfiltration target in GCP environments. Key patterns: large tabledata.list or jobs.query operations by an identity with no prior BigQuery activity (first-access behavioural), data export to an external GCS bucket not in the org, and dataset IAM policy change granting allUsers or allAuthenticatedUsers access.

For GCS, monitor bucket ACL changes that add allUsers (makes bucket public) and Object replication rules that copy objects to external buckets. These two patterns cover the most common GCS data exposure paths.

04

Security Command Center integration

SCC findings should be ingested as enrichment signals in the entity graph. When SCC flags a service account as 'anomalous grant' or a GCE instance as 'malware detected', that finding enriches any active case involving that resource. The combination of SCC context and CloudAudit timeline is what enables rapid scope determination.

Configure SCC notifications to a Pub/Sub topic and use the ManySignal Pub/Sub connector to ingest findings in near-real-time. Do not poll SCC findings — the Pub/Sub path is lower latency and more reliable.

05

Multi-project and Org-level monitoring

Use a Log Sink at the Org level to aggregate Admin Activity logs from all projects into a central BigQuery dataset or Pub/Sub topic. ManySignal's GCP connector reads from this centralised sink — you define one connector for the entire org rather than per-project.

Monitor Org policy constraints. A constraint change that removes a protection (e.g., removing compute.requireOsLogin or iam.disableServiceAccountCreation) is a high-severity control-plane event equivalent to an AWS SCP modification.

Key takeaways

  • Admin Activity logs are free and always on — enable them at Org level via central Log Sink.
  • Data Access logs are high-signal but high-volume; enable selectively for sensitive-tagged resources.
  • GCP IAM bindings at Org and Folder level are the highest-severity detection targets.
  • Workload identity federation pools and providers are a new persistence attack surface.
  • SCC findings are enrichment signals in the entity graph, not standalone alert queues.
  • Single Org-level Log Sink enables one ManySignal connector for the entire estate.

Further reading

Book a demo

Frequently asked questions

What is GCP Security Monitoring Guide in an agentic SOC?

GCP Security Monitoring Guide is part of ManySignal's agentic SOC and MDR platform, where AI agents detect, triage, investigate, and respond to threats with human-governed autonomy.

How does ManySignal handle gcp security monitoring guide?

ManySignal grounds gcp security monitoring guide in a temporal entity graph and behavioural baselines, so every verdict is backed by auditable evidence rather than opaque scores.

Can ManySignal replace my SOAR or MDR for gcp security monitoring guide?

Yes. ManySignal combines detection, triage, investigation, response, and reporting in one platform, and can operate as your MDR or augment an existing SOC team.

How is autonomy governed?

Through an autonomy ladder: recommend-only, approve-gated, and autonomous modes per action class, with dry-run previews, blast-radius limits, and a one-click tenant kill switch.

How fast is time to value?

Declarative connectors and shipped detections typically produce AI agent verdicts on live alerts within days, not quarters — no parsing projects or playbook-building phase.

Is ManySignal available as a managed service?

Yes. Consume ManySignal as MDR with 24/7 coverage and monthly reporting, run it as your in-house agentic SOC, or use it as the platform behind your own MDR practice.

How does ManySignal license the platform?

Pricing scales with protected assets and autonomy tier, not per-GB ingestion or per-alert volume. Starter, Growth, and Enterprise plans are available; MDR providers receive volume discounts for multi-tenant deployments.

Where does our data reside?

By default in AWS us-east-1. Enterprise tenants can pin data to specific AWS regions, deploy self-hosted on their own Kubernetes cluster, or use customer-managed encryption keys (CMK) to retain cryptographic control.

What does the evidence trail contain?

Each verdict stores the full question set, per-question agent answers, confidence weights, source event references, entity graph snapshots, and operator attestation — preserved immutably for the retention period chosen at contract time.

How does ManySignal handle a false-positive alert?

The triage agent auto-closes findings it assesses as false positives with a documented rationale — which rule fired, why the evidence fails to support escalation, and the entity baseline that informed the decision. Auto-closure rates typically reach 85–95% within 90 days as baselines mature.

Continue reading

The Complete SIEM Replacement Guide

SIEM Migration Runbook

AI SOC Implementation Guide

The Detection Engineering Handbook

See the agentic SOC in action

Watch AI agents work a real alert queue — verdicts, evidence, and confidence scores included. In-house SOC or MDR, your call.

Book a demo Explore the platform