Detecting and Responding to Cloud Security Incidents

Centralized security logging in Google Cloud is an enable, route, and analyze workflow that collects audit and network telemetry from every project, folder, and billing account into tamper-proof destinations. Cloud Logging (opens in a new tab) ingests the logs, an aggregated sink routes organization-wide copies to a single destination, and an analytics tool scans the centralized data for threats. This architecture creates one authoritative audit trail that no local project owner can delete or bypass.

1.1Enable Audit and Network Logs for Complete Coverage

Cloud Audit Logs are the foundation of the audit trail and record who did what, when, and to which resource. Admin Activity audit logs are enabled by default, while Data Access audit logs for data reads and writes, token generation such as GenerateAccessToken, and service-specific platform logs must be manually enabled because they increase ingestion cost. Each audit entry is a LogEntry whose protoPayload contains an AuditLog object with AuthenticationInfo for user identity, methodName for the event type, timestamp, request and requestMetadata for origination, response for success or failure, and serviceData for the affected service.

Comprehensive coverage requires network and workload logs beyond audit logs:

• VPC Flow Logs record network flows sent from or received by virtual machine instances and are enabled independently per VPC subnet for monitoring, forensics, and real-time analysis.
• Firewall Rules Logging records TCP and UDP connections evaluated by individual VPC firewall rules created by the administrator for auditing access and early warning of unapproved use.
• Kubernetes and GKE audit logs record API activity from Kubernetes and Google Kubernetes Engine (GKE) (opens in a new tab), with pod labels used to separate in-scope and out-of-scope workloads in metrics and logs.
• Cloud IDS logs record intrusion, malware, spyware, and command-and-control detections from mirrored north-south and east-west traffic, including VM-to-VM lateral movement.

Prioritize which logs to enable with threat coverage in mind, then limit volume by scoping expensive logs to sensitive subnets and workloads. Flow Logs combined with strict egress firewall rules make outbound traffic to authorized endpoints auditable and difficult to circumvent.

1.2Account for Google Personnel Access with Transparency and Approval

Access visibility in Google Cloud spans two trust boundaries: actions by the customer's own admins and actions by Google personnel. Cloud Audit Logs provide visibility into the customer's own administrator and data access activities but do not track manual access by Google support or engineering. Access Transparency (opens in a new tab) closes that gap with near real-time logs of targeted access by authorized Google personnel when they support the organization or maintain service availability.

Access Approval adds control on top of visibility by requiring explicit customer approval before an authorized Google administrator can access data or configurations. Approved requests are logged with Access Transparency logs linked to the approval request, and access must still be properly privileged inside Google before it is permitted. Use Access Transparency for detection of provider-side access and Access Approval when highly sensitive data requires prior authorization.

1.3Route Organization-Wide Logs with Aggregated Sinks

A Cloud Logging aggregated sink routes copies of logs from an organization or folder, including all contained folders, projects, and billing accounts, to a single centralized destination. Data flows from the source resources to the sink defined at the parent, then from the sink to the destination log bucket, BigQuery dataset, or Cloud Storage (opens in a new tab) bucket, where the analytics tool reads the aggregated data. The sink uses its own writer identity that must be granted write access to the destination, while analysts are granted separate read access only on the destination so source projects cannot alter the central copy.

Setting up security log analytics follows an ordered workflow:

1. Enable logs: Identify needed logs with coverage for MITRE ATT&CK tactics, CIS benchmarks, and Event Threat Detection dependencies, record the generated log filter, and enable Data Access and service-specific logs.
2. Route logs: Create the aggregated sink at the organization or folder with the recorded filter, grant the sink writer access to the destination, configure granular reader Identity and Access Management (IAM) on the destination, and verify that logs arrive.
3. Analyze logs: Query the centralized destination with Community Security Analytics (CSA) SQL queries, YARA-L rules, or security information and event management (SIEM) queries and correlate results with Security Command Center findings.

1.4Protect Destinations for Tamper-Proof Retention

Centralized destinations in Google Cloud must enforce immutability, encryption, and least-privilege access to satisfy audit and compliance retention. Cloud Storage bucket locks make stored audit objects immutable and non-deletable for a configured period from seconds to years for long-term, tamper-proof retention. Cloud Logging log buckets store logs for Observability Analytics with granular IAM-restricted read access, so only security operations roles can view sensitive logs. Retention policies on log buckets balance security and compliance needs against storage cost.

Protect the storage boundary with the same controls used for production data. VPC Service Controls (opens in a new tab) defines a security perimeter around Cloud Storage buckets, BigQuery datasets, and Bigtable instances to constrain data and mitigate exfiltration, while strict egress rules restrict internet-bound traffic. Optionally stream log copies to both Cloud Storage for immutable archiving and BigQuery for large-scale analysis, since BigQuery is optimized to query large datasets and supports near real-time export.

1.5Analyze Centralized Logs to Detect Threats

Analysis in Google Cloud turns the centralized trail into detection by establishing baselines for normal behavior and scanning for anomalies, suspicious flows, and policy violations. Google Security Operations (formerly Chronicle) correlates events from multiple sources for real-time analysis and incident response, while Security Command Center provides managed detectors for malware, cryptomining, port scans, brute-force SSH, and anomalous impersonation that rely on the routed Cloud Logging data. Network Analyzer, Cloud Intrusion Detection System (Cloud IDS), and Cloud Next Generation Firewall (NGFW) intrusion prevention monitor traffic for unusual protocols, unexpected connections, and spikes in transfer that can indicate attack.

The choice of analytics destination determines the query method:

Continuously analyze network traffic flows, firewall evaluations, and authentication events to identify suspicious patterns and potential attacks. Monitoring alerts based on intrusion attempts, firewall violations, and anomalous service account use notify the security operations center, which then investigates with the centralized, tamper-proof logs as evidence.

Continuous threat detection and security alerting is the practice of collecting logs and asset data centrally, scanning them automatically for vulnerabilities and active threats, and routing findings to alerting and response workflows. In Google Cloud, Security Command Center (SCC) provides the central detection findings, Cloud Logging provides the log stream and alerting, Cloud Monitoring tracks behavioral anomalies such as service account key usage, and Google Security Operations (opens in a new tab) (Google SecOps) correlates events for investigation and response.

2.1Establish Centralized Visibility and Network Baselines

Centralized logging and monitoring collects security logs from all cloud resources into one analysis point so normal behavior can be baselined and deviations can be detected. The baseline for normal network behavior is built from continuous analysis of network traffic flows, and suspicious patterns are flagged when traffic deviates from that baseline. Network Analyzer, part of Network Intelligence Center, provides insight into network performance and security by highlighting unusual protocols, unexpected connections, and sudden spikes in data transfer that can indicate malicious activity or anomalous egress. Assume an attacker is already inside the environment, so consistent security configurations are enforced with configuration management and infrastructure as code while monitoring continues for lateral movement and exfiltration.

2.2Detect Vulnerabilities and Misconfigurations with Security Command Center

Security Command Center (opens in a new tab) is the organization-level posture and threat platform that automatically creates findings for threats, vulnerabilities, and misconfigurations. SCC should be enabled at the organization level with the Premium tier to unlock full detection, attack simulation, and compliance capabilities, and all built-in services in the tier should be left enabled so new and changed resources remain protected. SCC findings come from multiple built-in detection services:

• Security Health Analytics detects common vulnerabilities and misconfigurations across Google Cloud resources.
• Attack path exposure simulates how an attacker could chain minor vulnerabilities from the internet to reach high-value resources or project billing permissions.
• Event Threat Detection applies threat intelligence, machine learning, and detection logic to logs to identify threats in near-real time.
• Container Threat Detection detects container runtime attacks such as reverse shell executions, evasive exploits, and unauthorized cryptomining binaries.
• Virtual Machine Threat Detection detects potentially malicious applications running on virtual machines, and Cloud Run Threat Detection extends runtime detection to Cloud Run.
• Web Security Scanner scans web-facing applications on Compute Engine, App Engine, and Google Kubernetes Engine (GKE) for OWASP Top Ten vulnerabilities.

Prioritize remediation by vulnerability severity and potential impact, and define a high-value resource set with resource value configurations so findings that expose the most important resources receive higher attack exposure scores. Until the first resource value configuration is created, SCC uses a default high-value resource set that is not customized to security priorities.

2.3Enable Required Logs and Extend Detection with Custom Modules

Event Threat Detection depends on logs generated by Google Cloud, and its coverage depends directly on which logs are turned on. Cloud Logging Admin Activity audit logs are always on and are scanned as soon as Event Threat Detection is enabled, while most Data Access audit logs and Google Workspace logs are off by default and must be enabled before scanning can occur. After a log is enabled, Event Threat Detection starts scanning it automatically, with logging ingestion and storage charges applying to enabled logs. Which additional logs to enable depends on the Google Cloud services in use and business security needs.

For organization-specific threats, SCC Premium supports custom detection that monitors the same Logging stream with organization-defined parameters. Custom modules for Security Health Analytics define rules for vulnerabilities, misconfigurations, or compliance violations, custom modules for Event Threat Detection define threat rules over log events, and custom cloud controls in Compliance Manager evaluate properties of scanned resources. Compliance Manager frameworks then monitor compliance continuously and alert on posture drift.

2.4Detect Unauthorized IAM Changes and Credential Compromise

Unauthorized IAM modifications and credential abuse are detected by combining Cloud Audit Logs alerts, Cloud Monitoring, and SCC threat findings. In Cloud Audit Logs, configure alerts on iamcredentials.googleapis.com methods such as GenerateAccessToken, GenerateIdToken, and SignJwt to audit service account token generation, which requires Data Access logs to be enabled. Configure alerts on protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail to audit user and service account impersonation, and on sts.googleapis.com exchange requests for anomalous identity assertions from Workload Identity Federation. Monitor service account key usage anomalies in Cloud Monitoring, monitor user logins in Google Workspace and Cloud Identity exported to Cloud Logging, and monitor Chrome Enterprise Premium and VPC Service Controls (opens in a new tab) logs for out-of-perimeter access attempts with stolen tokens.

In SCC, monitor Event Threat Detection findings that signal persistence, evasion, privilege escalation, and initial access:

• Persistence: New Geography, New User Agent, and New API Method
• Evasion: Access from Anonymizing Proxy
• Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity and Anomalous Service Account Impersonator for Admin Activity
• Initial Access: Leaked Service Account Key Used, Suspicious Login Blocked, and Account Disabled Hijacked, plus Persistence: Service Account Key Created

Each finding includes recommended investigation steps, and the security operations center (SOC) must be notified promptly with playbooks, tools, and cross-console access to respond to suspected compromise. Scan code repositories for leaked secrets with Anomaly Detection or secret scanning, and reduce persistent key risk by enforcing organization policy constraints for disabling service account key creation and upload (opens in a new tab).

2.5Alert, Export Findings, and Correlate Network Intrusions

Alerting connects SCC findings and log signals to notification and response systems without losing context. Set up alerts in Cloud Logging for SCC operational issues, including errors from the SCC service agent, and create log-based alerts for high-risk audit patterns such as IAM policy changes and anomalous egress. For network-layer threats, Cloud IDS (Intrusion Detection System) monitors traffic for malicious activity and generates alerts, while the Cloud NGFW intrusion prevention service can automatically block suspicious events. Strict egress firewall rules restrict internet-bound traffic, VPC Service Controls establish perimeters around sensitive APIs to prevent data exfiltration, and Google Cloud Armor protects the edge against distributed denial-of-service (DDoS) attacks, cross-site scripting (XSS), and SQL injection (SQLi).

Long-term routing of logs uses dedicated sinks that separate active analysis, retention, and external integration:

SCC findings flow from SCC to triage through Pub/Sub export, folder-level and project-level roles for scoped review, or direct ingestion into Google SecOps. Google SecOps provides security information and event management (SIEM) to search logs across clouds and define detection rules, plus security orchestration, automation, and response (SOAR) to manage cases and response workflows. When SCC service agents operate across VPC Service Controls perimeters, configure ingress and egress policies so Event Threat Detection, Security Health Analytics, Container Threat Detection, and related agents retain access to the services they protect. Secure enterprise foundations (opens in a new tab) define the baseline detective controls that make this triage consistent across folders and projects.

Execute incident response, forensics, and automated remediation is the end-to-end workflow that detects a security event, contains the damage, preserves evidence, and restores normal service. The workflow assumes an attacker is already inside the environment, so it relies on centralized logging, continuous monitoring, and predefined playbooks rather than perimeter trust alone. Detection feeds investigation, investigation drives containment and recovery, and every incident feeds threat indicators and improvements that strengthen future detection.

3.1Assume-Breach Detection and Continuous Monitoring

Assume-breach detection is the practice of collecting and analyzing security signals from all cloud resources to find anomalies even when no perimeter alert has fired. Cloud Logging manages and analyzes logs from services in Google Cloud, while Cloud Monitoring measures performance of services and resources and generates alerts from logs and metrics. Baselines for normal network behavior are established first, then network traffic flows are continuously analyzed to identify suspicious patterns and potential attacks.

Several Google Cloud services divide monitoring work by signal type:

• Network Analyzer monitors traffic for unusual protocols, unexpected connections, or sudden spikes in data transfer that could indicate malicious activity.
• Cloud IDS (Cloud Intrusion Detection System) and Cloud NGFW intrusion prevention service monitor network traffic for malicious activity and automatically block suspicious events or generate alerts.
• Web Security Scanner automatically identifies vulnerabilities in Compute Engine instances, containers, and Google Kubernetes Engine (GKE) clusters, with remediation prioritized by severity and potential impact.
• Security Command Center enabled at the organization level centralizes threat findings, vulnerability findings, and attack-path simulations for risk assessment.
• Google Security Operations (Google SecOps, formerly Chronicle) correlates security events from various sources, provides real-time analysis of alerts, and supports threat hunting and incident response.
• Wiz Defend with Wiz Runtime Sensor provides runtime threat detection for virtual machine (VM) and containerized workloads.

3.2Monitor Credential Compromise and Forensic Signals

Credential compromise monitoring is the focused detection of stolen or abused identities using audit logs, token telemetry, and threat findings. Cloud Audit Logs provide administrator activity and data access records, and Data Access logs must be enabled to audit service account token generation through iamcredentials.googleapis.com methods such as GenerateAccessToken, GenerateIdToken, and SignJwt. Impersonation is audited through protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail, while sts.googleapis.com exchange requests are monitored for anomalous identity assertions.

The security operations center (SOC) triages these signals alongside identity and perimeter telemetry:

• Scan code repositories for exposed secrets using Anomaly Detection or secret scanning, avoid hard-coding secrets, and store secrets in Secret Manager (opens in a new tab) or HashiCorp Vault with regular rotation and least privilege.
• Monitor Event Threat Detection findings in Security Command Center, including Persistence: New Geography, Persistence: New User Agent, Persistence: New API Method, Evasion: Access from Anonymizing Proxy, Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, Initial Access: Leaked Service Account Key Used, Persistence: Service Account Key Created, Initial Access: Suspicious Login Blocked, and Initial Access: Account Disabled Hijacked.
• Monitor user logins in Google Workspace and Cloud Identity, with export to Cloud Logging for centralized analysis, and monitor Chrome Enterprise Premium and VPC Service Controls logs for out-of-perimeter access attempts with stolen tokens.
• Monitor anomalies in service account key usage with Cloud Monitoring, monitor bulk API activity such as mass Cloud Storage downloads and BigQuery exports, and watch for export jobs to public buckets or unfamiliar projects outside the organization.

Enforce constraints/iam.disableServiceAccountKeyCreation and constraints/iam.disableServiceAccountKeyUpload organization policy constraints to reduce reliance on downloadable service account keys, and prefer more secure authentication alternatives such as Workload Identity Federation, OAuth 2.0, or signed JSON Web Tokens (JWTs).

3.3Contain, Eradicate, and Recover Compromised Workloads

Containment, eradication, and recovery is the response phase that limits ongoing damage, removes the attacker, and restores systems to a healthy state. When a ransomware attack is detected, the team first activates the incident response plan, confirms the incident is not a false positive and affects Google Cloud services, then opens a P1 support case with Cloud Customer Care (opens in a new tab). Customer Care responds under the Google Cloud Technical Support Services Guidelines and takes appropriate containment, eradication, and recovery actions within Google Cloud while the customer team coordinates internally.

The response plan removes the threat and restores the environment through coordinated operational steps:

1. Quarantine infected systems: Isolate compromised workloads first to limit lateral movement and ongoing damage.
2. Restore service: Restore from healthy backups or restore infrastructure to a previously known good state using the CI/CD pipeline, including infrastructure as code (IaC) with tools such as Terraform, Jenkins, and Cloud Build for consistent configuration and rapid rollback.
3. Eradicate the cause: Verify the vulnerability was removed, patch all systems vulnerable to a similar attack, and implement controls to prevent recurrence.
4. Close and learn: Inform Customer Care when the environment is restored, participate in a joint retrospective when scheduled, write detection rules and alerts that would trigger automatically if the attack recurs, and update the playbook.

A cryptomining or ransomware playbook must also define how to file the support case, how to distinguish legitimate high performance computing (HPC) workloads from mining through project tags and cost alerts, who must be notified, what must be logged for retrospective analysis, and how to verify remediation removed the malicious activity and closed the initial vulnerability.

3.4Follow the Formal Incident Lifecycle from Identification to Prevention

The formal data incident response lifecycle is the ordered process that moves an event from detection through triage, investigation, recovery, communication, and program improvement. The goal is to protect customer data, restore normal service quickly, and meet regulatory and contractual requirements. Independent security teams separate from core engineering provide oversight of the investigation.

The lifecycle proceeds in order, with each stage depending on the prior stage:

1. Identification and reporting: Automated and manual processes detect potential vulnerabilities and incidents, then report the issue to the incident response team.
2. Coordination triage: The on-call responder evaluates the nature of the report, assesses severity, and assigns an incident commander.
3. Response team engagement: The incident commander assesses known facts, designates leads from relevant teams, forms the incident response team, and evaluates the required response effort.
4. Investigation: The incident response team gathers key facts about the incident and integrates additional resources as needed for expedient resolution.
5. Containment and recovery: The operations lead limits ongoing damage, fixes the underlying issue, and restores affected systems and services to normal operations.
6. Communication: Key facts are evaluated to determine whether notification is appropriate, and the communications lead develops a communication plan with appropriate leads.
7. Closure and continuous improvement: The team retrospectively reviews the incident and response, designates owners for long-term improvements, maintains teams, training, processes, resources, and tools, and improves the program based on lessons learned.

Detection sources that feed identification include automated network and system log analysis, behavioral anomaly detection, penetration tests and intrusion detection, internal code reviews, product-specific tooling, privileged access monitoring of Google personnel access to customer resources, data center alerts, and employee reports. Machine learning correlates separate low-volume signals that share operational signatures to expose coordinated campaigns that simple rule-based filters might miss. Google's security overview (opens in a new tab) describes how this lifecycle fits within layered platform protections.

3.5Handle Forensics, Evidence, and Threat Learning

Forensics and evidence handling is the disciplined collection, analysis, and preservation of logs and system state to determine scope, intent, and attacker technique. Dedicated incident response staff are trained in forensics and handling of evidence using third-party and proprietary tools. Activities involving access to user data, source code, and sensitive information are logged with a required business justification or exception, and strong authentication allows logs to distinguish human events, service events, and service impersonation events.

When a policy violation is detected, the security team reviews whether access was intentional, unintentional, accidental, caused by a bug or misconfiguration, or caused by inadequate controls such as stolen employee credentials. If access was unintentional, the team takes immediate remediation such as recovering intellectual property. If malicious behavior is suspected, the team escalates, collects data and system access logs to determine scope and impact, and refers the case for additional investigation, documentation and resolution, or to outside authorities in extreme cases. All incidents are documented and metadata is extracted to identify specific tactics, techniques, and procedures, which are then used to develop new threat indicators, reinforce protections, or request security improvements. AI tools auto-populate a postmortem draft from timelines, chat logs, and metadata, and follow-up work is tracked with assigned owners until remediation concludes. Privileged access controls (opens in a new tab) ensure forensic access to sensitive data remains justified and auditable.

3.6Manage Notifications, AI Guardrails, and Program Assurance

Incident notifications and AI guardrails are the controls that route alerts to the right people and keep automated assistance auditable. Notifications about data incidents are sent through Essential Contacts, with the Google Admin console providing additional account, service health, and mandatory announcements. If Essential Contacts is not configured, messages go to organization administrators, project owners, or billing administrators depending on scope. Senders use an @google.com address and messages typically include affected services and projects, issue description, detection time, unique incident identifier, and links to dashboards or support resources.

To ingest notifications into response workflows, configure an incident response group email for the Security or All category in Essential Contacts, grant security administrators the Advisory Notifications Viewer role (roles/advisorynotifications.viewer) to view advisories in the Google Cloud console, and create Cloud Monitoring alerts from logs and metrics. During response, AI enriches context under strict limits: machine learning correlates signals during identification, AI agents suggest potential root causes and resolutions during investigation, and AI is prohibited from executing commands directly during resolution. AI instead generates structured action payloads that must pass validation checks and receive explicit human-in-the-loop confirmation, with all AI actions recorded in immutable audit logs. Zero trust principles (opens in a new tab) require this explicit verification instead of implicit trust in automated actions.

Key Facts

• Cloud Audit Logs record administrator and data access activity, with Admin Activity logs enabled by default and most Data Access logs requiring explicit enablement before Event Threat Detection can scan them.
• A Cloud Logging aggregated sink routes copies of logs from an organization or folder to a centralized log bucket, BigQuery dataset, or Cloud Storage bucket using a writer identity that must have write access to the destination.
• 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.
• VPC Service Controls defines a security perimeter around Cloud Storage buckets, BigQuery datasets, and sensitive APIs to constrain data and mitigate exfiltration.
• Containment isolates compromised workloads first, then restores service from healthy backups or infrastructure as code, eradicates the vulnerability, and updates detection rules and playbooks.