Google Cloud Logging Monitoring and Detection

Configuring and analyzing network logs means combining firewall decisions, sampled flows, full-packet copies, and intrusion alerts in Cloud Logging (opens in a new tab) for detection and forensics. Cloud Next Generation Firewall (Cloud NGFW) enforces policy inline and can block threats, while Cloud Intrusion Detection System (Cloud IDS) detects threats passively from mirrored traffic. VPC Flow Logs and Packet Mirroring provide the underlying traffic evidence, and Log Analytics makes all of it queryable with SQL.

1.1Inline Prevention With Cloud NGFW Versus Passive Detection With Cloud IDS

Cloud NGFW and Cloud IDS differ in where they sit in the traffic path and how they respond to threats. Cloud NGFW records which firewall policy rule allowed or denied traffic and, in Enterprise with intrusion detection and prevention, intercepts matched traffic for Layer 7 inspection. Traffic flows from virtual machine (VM) instances or Google Kubernetes Engine (GKE) clusters to firewall policy rules, then matched packets flow to a zonal firewall endpoint, then the endpoint scans for threat signatures and enforces the action in the security profile.

Cloud IDS works differently because mirrored traffic flows from Compute Engine VMs or GKE clusters to a Google-managed peered network, where Palo Alto Networks technologies inspect the copy. Cloud IDS endpoints in the Virtual Private Cloud (VPC) (opens in a new tab) monitor ingress, egress, and intra-VPC traffic, including VM-to-VM east-west traffic that reveals lateral movement. The operational difference is fixed:

Firewall Rules Logging supports both models by auditing per-rule allow and deny decisions for TCP and UDP in either direction. Logging is enabled per firewall rule, applies to VPC firewall rules and hierarchical and global network firewall policies, and should be enabled only on rules under investigation to control volume and cost.

1.2Sampled Flow Records With VPC Flow Logs Versus Full Capture With Packet Mirroring

VPC Flow Logs and Packet Mirroring differ in granularity, cost, and forensic power. VPC Flow Logs samples packets sent from and received by VM instances, including GKE nodes, Cloud Run and App Engine with Direct VPC egress, and VLAN attachments for Cloud Interconnect and Cloud VPN. Sampled TCP, UDP, ICMP, ESP, GRE, and Remote Direct Memory Access (RDMA) flows are aggregated by 5-tuple connection over an interval, with byte and packet counts estimated to account for missed packets.

Visibility is controlled by four peer settings. Aggregation interval combines one connection into one entry over 5 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, or 15 minutes. Secondary sampling keeps entries from 1.0 to 0.0, with Compute Engine API defaults of 50% and Network Management API defaults of 100%. Metadata annotations can be full, limited, or off, and filters can emit only matching flows. Scope determines billing and storage: organization scope covers all subnets and attachments with per-project billing, while project scope covers one VPC network or one subnet, attachment, or tunnel, with logs stored in the reporting VPC project and Shared VPC logs stored in the host project.

Packet Mirroring copies all packets with full payloads from source VMs to collector instances running third-party tools. Mirroring happens on the VM, not on the network, so it does not sit inline. Use VPC Flow Logs for continuous monitoring of top talkers, inter-region traffic, and country-level flows, and use Packet Mirroring when investigation needs payloads such as HTTP detail or malware reconstruction.

1.3Centralized Threat Hunting With Log Analytics and SQL

Log Analytics turns distributed firewall, flow, DNS, and IDS logs into one queryable dataset. Data flows from VPC Flow Logs, Firewall Rules Logging, Cloud DNS logging, and Cloud IDS into an upgraded Cloud Logging bucket with Log Analytics enabled, where the _AllLogs view exposes structured fields such as timestamp, resource.type, log_id, and json_payload. An aggregated sink with a log scoping filter routes organization, folder, project, and billing account logs to that bucket, to BigQuery for very large near real-time analysis, to Cloud Storage with optional Bucket Lock for immutable retention, or to Pub/Sub for SIEM ingestion.

SQL analysis uses BigQuery-compatible syntax in both places but with different access patterns. Log Analytics queries [PROJECT].[REGION].[BUCKET]._AllLogs and extracts nested fields with JSON_VALUE(json_payload.field), while BigQuery export queries dataset tables such as ids_googleapis_com_threat with jsonPayload.field. Correlation joins firewall decisions, flow 5-tuples, and IDS verdicts on time, IP addresses, ports, and protocol to answer whether a deny rule worked or whether allowed traffic later triggered a HIGH or CRITICAL alert. Firewall Insights and Network Analyzer (opens in a new tab) extend this by exposing shadowed rules, misconfigurations, and packet-drop signals.

Designing an effective logging strategy means enabling the right audit and network sources, routing them through Log Router, and retaining them for analysis and compliance. Logs flow from the producing service to Log Router, then Log Router applies exclusions first and sink inclusion filters second, then matching entries flow from each sink to its destination. The design balances visibility, cost, retention, and least-privilege access.

2.1Critical Audit and Network Sources for Security Coverage

Critical log sources show who changed what and what traffic was allowed or denied. Cloud Audit Logs (opens in a new tab) record control-plane and data-plane activity, while network logs record packet and rule decisions in the VPC. Most high-value sources require explicit enablement per subnet, rule, service, or organization policy.

Key sources to configure include:

• Administrator Activity audit logs for configuration changes, aggregated centrally for investigation.
• Data Access audit logs for reads and writes to user data, enabled selectively because volume and cost are high.
• VPC Flow Logs for subnet flows with source and destination IPs, ports, and instance context.
• Firewall Rules Logging for TCP and UDP evaluations with ALLOW or BLOCK action.
• Load balancer, GKE, Cloud Storage, Compute, and serial console logs for edge, container, object, and VM activity.
• Database statement logging and Workspace Login, Admin, and Group logs when databases or Workspace are in scope.

Admin Activity logs are on by default, while Data Access, VPC Flow Logs, and Firewall Rules Logging must be explicitly enabled before detectors and queries can use them.

2.2Centralized Routing With Log Router Sinks and Exclusions

Log Router is the ingestion pipeline that keeps, drops, and exports entries. Every entry arrives at Log Router, exclusions discard noise, and each sink forwards its inclusion-filter matches to its destination using a writer identity that must have destination permission. An aggregated sink created at the organization or folder collects from all current and future child projects into one central project outside workload-team control.

A practical pattern uses one aggregated sink that routes Admin Activity logs to a Cloud Logging bucket enabled for Observability Analytics, plus a second sink that routes Data Access logs from sensitive projects to Cloud Storage with retention locks. A Compute and network sink is built in order: create the sink, choose Cloud Storage, BigQuery, Pub/Sub, Logging bucket, or Google SecOps feed, build a resource filter such as resource.type="gce_instance", add log-name clauses such as vpc_flows or compute.googleapis.com/firewall, then grant the writer and validate in a test project. Centralized collection divides by use:

2.3Retention, Encryption, and Threat Detection Design

Log storage control decides region, duration, encryption, and who can read sensitive fields. Cloud Logging buckets are regional resources with custom retention from 1 day to 3650 days that applies to every log in the bucket. Default encryption at rest is sufficient without key requirements, while customer-managed encryption keys (CMEK) in Cloud Key Management Service (KMS) control lifecycle with optional hardware security module (HSM) or external key management.

Access is layered by hiding whole entries versus hiding fields. Log views hide entire LogEntry objects from users without that view, while field-level access controls hide individual fields such as email addresses. Analysis follows an ordered workflow: first enable logs, then route organization-wide logs with an aggregated sink, then analyze with SQL, YARA-L, or SIEM queries. Cloud Monitoring alerts on baseline deviations, Cloud IDS and NGFW monitor traffic, and Security Command Center correlates findings from Security Health Analytics, Event Threat Detection, Virtual Machine Threat Detection, Container Threat Detection, and Web Security Scanner.

Logging, monitoring, and response in Google Cloud is an enable, route, analyze, and recover workflow that assumes an attacker is already inside. Cloud Logging (opens in a new tab) ingests audit and network telemetry, an aggregated sink routes organization-wide copies to tamper-proof destinations, and analytics tools scan the centralized data for threats. Detection then drives containment, forensics, recovery, and program improvement.

3.1Centralized Audit Coverage With Transparency for Provider Access

Cloud Audit Logs record who did what, when, and to which resource through AuthenticationInfo, methodName, timestamp, request and requestMetadata, response, and serviceData. Admin Activity logs are on by default, while Data Access logs, token generation such as GenerateAccessToken, and service-specific platform logs must be enabled because they increase ingestion cost. Complete coverage adds VPC Flow Logs per subnet, Firewall Rules Logging per rule, Kubernetes and GKE audit logs, and Cloud IDS logs for north-south and east-west detections including VM-to-VM lateral movement.

Customer admins and Google personnel sit on opposite sides of the visibility boundary. Cloud Audit Logs cover customer administrator and data access but not manual Google support access. Access Transparency closes the gap with near real-time logs of targeted Google personnel access, while Access Approval requires explicit customer approval before that access is permitted, with approved requests linked to Transparency logs. Centralized destinations enforce immutability with Cloud Storage Bucket Lock from seconds to years, granular IAM read access, and optional VPC Service Controls (opens in a new tab) perimeters around Storage, BigQuery, and Bigtable to constrain exfiltration.

3.2Continuous Threat Detection With Baselines and Security Command Center

Continuous detection builds a baseline for normal network behavior and flags deviations such as unusual protocols, unexpected connections, and sudden transfer spikes. Network Analyzer highlights performance and security anomalies, Cloud IDS generates alerts on malicious traffic, and NGFW intrusion prevention can block suspicious events. Security Command Center (SCC) enabled at the organization level with Premium tier centralizes findings, attack-path simulation, and compliance monitoring.

SCC findings come from Security Health Analytics for misconfigurations, Event Threat Detection for near real-time log threats, Virtual Machine Threat Detection for malicious VM applications, Container Threat Detection for runtime container attacks, Cloud Run Threat Detection for serverless runtime, and Web Security Scanner for OWASP Top Ten issues. Event Threat Detection depends on enabled logs: Admin Activity is always scanned once enabled, while most Data Access and Workspace logs must be explicitly enabled first. Credential abuse is tracked by alerting on iamcredentials.googleapis.com methods, service-account delegation fields, sts.googleapis.com exchanges, service-account key anomalies, and SCC persistence, evasion, privilege-escalation, and initial-access findings.

3.3Formal Incident Lifecycle From Containment to Learning

The formal data incident response lifecycle moves an event through ordered stages where each stage depends on the prior stage:

1. Identification and reporting: Automated and manual processes detect and report the issue.
2. Coordination triage: On-call responder assesses severity and assigns an incident commander.
3. Response team engagement: Commander designates leads and forms the response team.
4. Investigation: Team gathers facts and adds resources for expedient resolution.
5. Containment and recovery: Operations lead limits damage, fixes the cause, and restores service.
6. Communication: Communications lead evaluates notification need and develops the plan.
7. Closure and improvement: Team reviews the response, assigns owners, and improves protections.

For ransomware, the team activates the plan, confirms impact to Google Cloud, opens a P1 case with Cloud Customer Care, quarantines infected systems first to limit lateral movement, restores from healthy backups or infrastructure as code with Terraform, Jenkins, and Cloud Build, eradicates the vulnerability, then writes detection rules that would fire if the attack recurs. Forensics preserves logs and system state with business justification, distinguishes intentional, accidental, bug, and stolen-credential access, extracts tactics and procedures into new indicators, and routes notifications through Essential Contacts. AI may suggest causes during investigation but must not execute commands during resolution without validation and explicit human confirmation.

Secure access to logs controls which identities can query telemetry in Cloud Logging and from which context those queries succeed. Identity and Access Management (IAM) grants access from an identity to a log bucket or view, IAM Conditions and access levels add request context, and VPC Service Controls adds a network and resource perimeter. Together they separate operational logs from sensitive Data Access audit logs.

4.1Least-Privilege Logging Roles and Context-Aware Conditions

Predefined logging roles separate standard logs from private audit data in the _Default bucket. Logs Viewer (opens in a new tab) grants read access to standard logs, Private Logs Viewer is additionally required for Data Access audit logs, Logs View Accessor grants access to specific log views, and Logging Admin manages buckets, sinks, and views. Least privilege grants only the needed role at the smallest scope, preferably to groups, with automatic expiry, periodic review, and 2-step verification for privileged use.

IAM Conditions make a valid role insufficient alone by evaluating time, resource name, IP address, geography, or device on every request. Access Context Manager defines an access level such as corporate network or valid mutual-TLS certificate, and Chrome Enterprise Premium evaluates that level on each user API request to Cloud Logging. This allows queries only from approved networks, regions, or maintenance windows and rejects valid credentials used from attacker-controlled machines.

4.2Perimeter Boundaries and Segregation Architectures

VPC Service Controls perimeters enclose protected projects, Logging buckets, and supported APIs on the inside while untrusted networks and exfiltration destinations remain on the outside. Policies allow movement within the perimeter but deny reads, copies, or sink exports that cross the boundary without an explicit ingress or egress rule. The perimeter applies to all user and service account identities, so an automated exporter cannot bypass it.

Segregation architectures isolate sensitivity by stream, entry, or field:

A common pattern keeps operational logs in _Default for Logs Viewer access while a sink routes Data Access logs to a locked-down security project for Private Logs Viewer holders only.

4.3Custom Buckets, Views, and Restricted-Field Configuration

A custom log bucket is a regional Logging container that centralizes or subdivides logs with its own retention, location, and encryption policy. Retention is 1 day to 3650 days for all logs in the bucket, location is fixed for latency and residency with a default resource location for new _Default and _Required buckets, and encryption defaults to Google-managed keys with CMEK via Cloud KMS for lifecycle control. Log views then determine which complete LogEntry objects a principal can read, which is distinct from field controls that leave the entry visible but remove sensitive fields.

Field-level controls hide paths such as jsonPayload, leaf fields like jsonPayload.data.ssn, and leaf fields of textPayload, protoPayload, httpRequest, labels, and sourceLocation. Configuration uses gcloud logging buckets create or update with --restricted-fields, and update replaces the full set so all retained fields must be relisted. Access requires both bucket log-view permission and logging.fieldAccessor for that path. Queries in Logs Explorer omit denied fields, live tailing is unsupported, and a linked BigQuery dataset does not honor field controls, so dataset readers can see all fields.

Exporting logs to external systems moves telemetry from Cloud Logging through sinks to Cloud Storage and then to Google Security Operations (Google SecOps), Splunk, Elastic, or other SIEMs. The pipeline depends on sink scope and filters, writer and reader identities, and storage protection working together. Every feed then normalizes raw logs into the Unified Data Model (UDM) for consistent detection.

5.1Aggregated Sink Scope and Inclusion Filter Design

An aggregated sink is a routing rule with a scope, destination, inclusion filter, and optional exclusions. Project scope routes that project, while folder or organization scope aggregates all child projects and folders into one destination. Data flows from Cloud Logging to the sink destination, then from the destination to the SIEM feed, so the destination must exist before routing starts. For Cloud Storage the destination is a URI such as gs://gcp-ids-logs, while air-gapped Google Distributed Cloud uses a SIEMOrgForwarder that must share its project namespace with the credential Secret, with separate resources for audit versus operational logs.

Inclusion filters select by resource.type, logName, and jsonPayload fields, and the effective export set is inclusion matches minus exclusion matches. Representative patterns pair gce_instance with audit activity, gce_subnetwork with vpc_flows or compute.googleapis.com/firewall, gae_app with request or stdout and stderr logs, and IDS or DNS Threat Detector types with cloud-ids or networksecurity.googleapis.com/DnsThreatDetector names. Payload conditions such as connection IPs or rule_details.action=("ALLOW" OR "BLOCK") keep only high-fidelity events. New Cloud Storage sinks deliver hourly batches with 2 to 3 hours before first delivery.

5.2Push Streaming Versus Pull Feeds for SIEM Ingestion

Push and pull models define who initiates transfer and how fast events become searchable. Push sends events directly to the SIEM Ingestion API or Webhook for low latency, while pull has SecOps poll staged storage to consolidate multicloud logs. Both normalize to UDM so identical behaviors from different clouds share one schema.

Real-time push creates a feed under SIEM Settings with source type, log type, feed ID, and customer ID, then posts to a feed-specific URL containing region, project number, location, customer ID, and feed ID. Batch V2 pull creates a globally unique Standard bucket with Uniform access, stages newline-delimited JSON, creates a V2 feed with bucket URL ending in a slash, deletion option, 180-day default Maximum File Age, namespace, and labels, then grants the unique Chronicle service account reader access and verifies Active status. As of April 15, 2026, v1 storage connectors are deprecated in favor of V2.

5.3Hardened Export Pipeline With Identity and Perimeter Controls

A secure pipeline separates a write-only logging identity, a read-only consumer identity, and a hardened bucket. The sink writer service-123456789012@gcp-sa-logging.iam.gserviceaccount.com needs only Storage Object Creator, while the per-instance SecOps reader such as chronicle-12345678@chronicle-gcp-prod.iam.gserviceaccount.com needs only Storage Object Viewer. Sink creation itself requires roles/logging.configWriter, so sink management, writing, and consumption remain distinct domains.

The bucket uses Uniform access, public access prevention lockable by organization policy, Standard class for hot logs, and selectable encryption, location, versioning, and retention. Deletion options trade hygiene for evidence: Never preserves evidence with Viewer only, while either Delete transferred files option requires Object Admin and lets a misconfigured feed destroy the authoritative copy. In air-gapped forwarding, the logging stack retries a failed SIEM connection five times by default, then drops the batch rather than queuing without bound.

Configuring and analyzing audit logs turns Cloud Audit Logs entries into measurable signals, timely alerts, and forensic timelines. Cloud Logging (opens in a new tab) collects and filters entries, Cloud Monitoring evaluates alerting policies, and notification channels deliver incidents to responders and SIEMs. The goal is to record who did what, where, and when, then separate immediate threats from routine noise.

6.1Audit Log Types and Forensic Field Reconstruction

Audit log types differ by trigger and enablement. Admin Activity logs record configuration changes and are always written and cannot be disabled or excluded, even if the Logging API is disabled. Data Access logs record reads and data operations and must be explicitly enabled in the IAM AuditConfig object. Policy Denied logs record denials by security policy, and System Event logs record Google system actions without user action.

Each entry is an immutable LogEntry with protoPayload containing identity, methodName, timestamp, request context, response success or failure, and service details. Investigators fix the time window, filter by logName such as cloudaudit.googleapis.com/activity, by resource.type such as project or service account, and by methodName such as SetIamPolicy, then pivot across caller, IP, resource, and time. One Cloud Storage request can generate multiple entries because each checked IAM permission can emit Admin Activity, ADMIN_READ, DATA_READ, or DATA_WRITE.

6.2Log-Based Metrics and High-Value Security Alerts

A log-based pipeline moves data in fixed order: first Cloud Logging filters entries into a log-based metric or alert condition, then Cloud Monitoring evaluates the alerting policy and fires an incident, then the incident flows to email, Pub/Sub, or dashboards. Policies should alert immediately on narrow high-risk patterns while aggregating routine reads for dashboard review. Centralizing Cloud Identity and Workspace login events with resource logs lets one filter cover logins and subsequent resource changes.

Dedicated metric filters should cover unauthorized compute creations, IAM grants including ownership and Service Account User or Token Creator, audit and custom-role tampering, VPC firewall openings, excessive failed logins and anomalous service-account key use, anomalous Data Access reads and exports, non-corporate accounts added to privileged groups, and billing spikes. Billing and budget alerts provide independent warning when log coverage is incomplete. Findings flow from sinks to Cloud Storage for preservation, BigQuery for analysis, and Pub/Sub to SIEM or Google Security Operations, with Essential Contacts as a monitored group alias so alerts reach an active team.

6.3Audit Sinks, Retention Controls, and Forensic Query Workflow

A log sink routes copies of matching entries to a supported destination without removing originals. Destinations divide by need: Cloud Storage for low-cost preservation, BigQuery for SQL analytics over large volumes, Pub/Sub for real-time forwarding to third parties, and central Logging buckets for Observability Analytics. An aggregated sink at organization or folder scope lets one security team own one destination and access controls while capturing the entire hierarchy.

Deployment follows an ordered dependency: first create the central bucket, dataset, topic, or Logging bucket, then create the aggregated sink with the audit filter, then grant the sink writer identity write access, then grant analysts read access only on the destination, then verify arrivals from multiple projects. Retention in Logging is governed by the bucket, not the log type, with custom retention from 1 day to 3650 days and Bucket Lock to prevent early deletion. Cost control estimates usage, alerts on billing, and excludes low-value Data Access logs, especially in development, while retaining authentication and production storage access. For IAM forensics, select the project in Logs Explorer, filter log name and resource, filter methodName to SetIamPolicy, CreateServiceAccount, and CreateServiceAccountKey, then expand time and add Data Access and Policy Denied filters. Reading Data Access logs in _Default requires Private Logs Viewer, while Logs Viewer reads only Admin Activity, Policy Denied, and System Event logs.

Log export architecture is the controlled pipeline that moves telemetry from Cloud Logging through sink filters to Storage, BigQuery, Pub/Sub, or central Logging buckets and then to SecOps or SIEMs. Entries that match the inclusion filter flow to the configured destination in hourly batches, land as sharded JSON organized by log type and date, then flow from the bucket to the feed reader. New Cloud Storage sinks can take several hours with 2 to 3 hours before first entries appear.

7.1Data Residency and Destination Selection for Exports

Bucket location determines where exported object data permanently resides. Location type (opens in a new tab) of Region, Dual-region, or Multi-region plus a specific Location such as us-central1 controls geography, so regulated workloads select the location closest to the compliance boundary or SecOps instance. Protection settings add Standard storage for hot logs, Uniform access for consistent IAM, versioning or retention policy, selectable encryption, and public access prevention lockable by organization policy.

Destinations divide by retention and use. Cloud Storage holds objects for low-cost retention and re-import under lock policies, BigQuery stores date-partitioned tables keyed to entry timestamp for SQL analysis with dataset or partition expiration, Pub/Sub streams to Elastic, Splunk, or Datadog for immediate ingestion, and a central Logging bucket provides query-ready investigation without workload-project access. Centralize when the security team needs a consistent restricted record, avoid centralization when project owners fully own their logs, and be selective about what leaves Google Cloud because egress plus external storage and integration work is expensive.

7.2Aggregation Scope, Copy Semantics, and System-Created Sinks

An aggregated sink created at organization, folder, or billing account collects from that resource and all children. Organization scope collects all folders and projects, while folder scope collects only nested projects. Flow from children depends on --include-children in gcloud logging sinks create, and the inclusion filter then selects Admin Activity, Data Access, or other hierarchical logs.

Routing copies rather than moves entries. A match is stored twice, once by the child project sinks and again in the aggregated destination, so duplicates and cost continue unless child _Default sinks exclude centrally routed entries and future projects disable _Default in organization defaults. System sinks guarantee local routing:

_Required matches only entries that originated in its own resource, so an entry routed from project A to project B is not reprocessed by _Required in project B.

7.3Inclusion Filters, Exclusions, and Sink Authorization Order

Filters in the Logging query language decide whether an entry flows from sink to destination. A sink with no inclusion filter matches every entry, while exclusion filters override inclusion when both match. The three governing rules are: no inclusion match means no routing, inclusion plus exclusion match means no routing, and inclusion without exclusion match means routing. Exclusions apply after receipt by the Logging API, so they do not reduce entries.write quota or calls. Every exported element must be scoped with log_id() or logName, filters are limited to 20,000 characters, and deeply nested AND and OR combinations can be rejected.

Create and authorize an aggregated sink in order:

1. Create the sink: Run gcloud logging sinks create with destination, --log-filter, --organization, --include-children, and --use-partitioned-tables for BigQuery daily partitioning.
2. Verify creation: Run gcloud logging sinks list at the organization scope.
3. Retrieve the writer identity: Run gcloud logging sinks describe and copy the serviceAccount: value.
4. Grant destination write access: Grant that identity write permission, then confirm arrivals and control duplicates with child exclusions.

When the destination is a Google Cloud project, sinks in that project can reroute received entries to any supported destination except another project. The sink writer needs Storage Object Creator for write-only export and the SecOps reader needs Storage Object Viewer, elevated to Object Admin only when the feed deletes transferred files.

Security Command Center is the cloud risk platform that centralizes vulnerability detection, threat detection, posture management, and compliance monitoring. Findings are records of threats, misconfigurations, vulnerabilities, or drift created by built-in detectors, integrated Google services, and Marketplace partners. Architecture is controlled by service tier for capabilities and activation level for coverage scope.

8.1Service Tiers, Activation Levels, and IAM Service Agents

Service tiers define available detection and operations capabilities. Standard (opens in a new tab) provides basic misconfiguration scanning through Security Health Analytics, Premium adds threat detection, vulnerability detection, compliance, attack-path simulation, and posture management, and Enterprise adds SecOps SIEM and SOAR plus multicloud support. Enterprise is deprecated and will shut down on May 21, 2027, with automatic movement to Premium on or after that date. Premium project activations offer a 30-day trial that becomes pay-as-you-go unless downgraded to Standard.

Organization activation covers all folders and projects and is required for Enterprise, data residency, CMEK, high-value resource sets, Workspace log scanning, and integrated Armor and Sensitive Data Protection sources. Project activation covers one project already in an organization and never gains organization features even on Premium. First full scan completes within 24 hours. Human activation needs Security Admin plus Security Center Admin and serviceusage.services.enable, while automated access flows through Google-managed service agents for Event Threat Detection and Health Analytics, Compliance, Container Threat Detection, and Data Security Posture Management, each requiring VPC Service Controls ingress and egress when perimeters isolate projects.

8.2Integrated Posture, Runtime, and Log-Based Detection Services

The four core services divide work by observed signal. Security Health Analytics reads configuration from Cloud Asset Inventory to find misconfigurations and leaked secrets without OS agents. Event Threat Detection applies intelligence and machine learning to Logging and Workspace streams to find malware, cryptomining, exfiltration, and malicious control-plane actions. Container Threat Detection watches Container-Optimized OS and Cloud Run second-generation runtimes for reverse shells and cryptominers, while Virtual Machine Threat Detection observes Compute Engine VMs from outside the guest OS for malicious binaries.

Enabling has explicit dependencies. Standard auto-enables Health Analytics, while Premium enables Health Analytics, Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection, Vulnerability Assessment, posture, and Web Security Scanner. Event Threat Detection scans Admin Activity immediately because it is always on, but cannot scan Data Access or Workspace logs until they are enabled. Container Threat Detection needs supported GKE versions, Cloud Run Threat Detection needs the Container Threat Detection API on every monitored project plus second-generation environment plus redeployment after enablement, and Vulnerability Assessment scans installed software for CVEs across VMs, containers, and Cloud Run. Posture findings feed attack-path simulations that show how minor issues chain from the internet to high-value resources.

8.3Finding Triage, Continuous Exports, and Automated Response

A threat finding names the affected resource, detector, and evidence needed to decide maliciousness versus misconfiguration. For example, Impact: GPU Instance Created from the Sensitive Actions Service flags a principal creating a GPU instance with no recent GPU history in that project, which maps to Resource Hijacking (T1496) for cryptomining abuse but can also be a legitimate new machine learning workload. Review preserves evidence first, then context, then cause:

1. Open finding details: Examine Summary for context and JSON for complete fields.
2. Correlate related findings: Identify same-resource findings at similar times.
3. Review resource settings: Determine whether the change was authorized.
4. Check resource logs: Reconstruct who acted, from where, and what changed.

Operations filter with custom queries and mute rules, then establish real-time pipelines with Pub/Sub and Cloud Functions to route alerts, integrate SIEMs, and trigger remediation. Visibility depends on granted SCC roles, detail panels expose MITRE ATT&CK and VirusTotal context, and all tier services should remain enabled so new resources stay protected.

Key Facts

• VPC Flow Logs samples packets before egress firewall rules and after ingress rules, so egress denies can appear while ingress denies never appear.
• Admin Activity audit logs are always written and cannot be disabled or excluded, while Data Access audit logs, VPC Flow Logs, and Firewall Rules Logging must be explicitly enabled.
• An aggregated sink copies logs from organization or folder children with --include-children and requires granting its writer identity destination write access; entries remain locally unless child _Default sinks add exclusions.
• Log views hide entire LogEntry objects while field-level access controls hide individual fields, and Observability Analytics cannot query buckets with field-level controls.
• Security Command Center Premium enabled at the organization level centralizes findings from Security Health Analytics, Event Threat Detection, Container Threat Detection, Virtual Machine Threat Detection, and Web Security Scanner.