Last reviewed:
How SOC teams can use Google Cloud audit records to detect IAM change, sensitive data access, policy denial and platform-generated system events without pretending every audit entry proves attacker behaviour.
Google Cloud Audit Logs record activity across Google Cloud resources. The four audit-log types are Admin Activity, Data Access, System Event and Policy Denied. A detection plan should name the type it uses, because each type answers a different review question.
Admin Activity logs record API calls and administrative actions that change the configuration or metadata of resources. Google Cloud writes them by default for supported services, and teams cannot disable them. They are the first place to look for IAM policy change, service-account key creation, logging sink change and high-risk resource administration.
Data Access logs record API calls that read configuration, read user data or write user data. They are usually disabled by default, apart from specific Google Cloud defaults and service exceptions, so a coverage report must not count Data Access detections until the organisation has enabled the right services, projects and log types.
System Event logs record Google Cloud actions that change resource configuration. Policy Denied logs record when Google Cloud denies access because of a security policy. Neither source proves compromise on its own, but both can explain why an investigation saw a resource change or blocked request without an obvious user-initiated API call.
A practical GCP audit-log programme starts with detection families, not a flat list of method names. Keep IAM and organisation-policy changes in an Admin Activity lane. Put sensitive object, dataset and secret access in a Data Access lane. Keep platform-generated System Event changes separate from human or workload identity actions.
This split keeps the analyst review honest. An Admin Activity event for SetIamPolicy can support a privileged-access investigation when it changes a broad role at project, folder or organisation scope. A Data Access read against a storage object or BigQuery table needs resource sensitivity, caller identity and expected workload context before it becomes an alert worth paging on.
Policy Denied logs are useful for attempted access and control validation, but they are not proof that the same actor reached the data. Treat them as blocked-behaviour evidence unless another source shows successful follow-on access.
Cloud Audit Logs can support ATT&CK mappings, but the mapping should say what the audit record proves. A suspicious IAM binding for a broad primitive role can support T1078.004 Valid Accounts: Cloud Accounts and T1098 Account Manipulation. A logging sink deletion or exclusion change can support T1685.002 Disable or Modify Cloud Log, as can an audit-config change that turns logging off through SetIamPolicy. The field that proves that last case, serviceData.policyDelta.auditConfigDeltas, is deprecated, so keep the T1685.002 mapping in review until the export path is confirmed. The event still needs tenant context before the SOC calls it malicious.
Use evidence labels beside the technique mapping. Direct detection evidence means the log event and resource context are enough to alert. Correlation context means the event matters only when joined with another signal, such as an unusual sign-in, a new service-account key and a project-level IAM grant in the same window. Posture context means the log shows exposure or readiness, not attacker behaviour by itself.
This stops GCP coverage from becoming inflated. The report can show that Cloud Audit Logs support valid-account abuse, account manipulation and cloud-log tamper review, while the backlog still names where Data Access logging, parser coverage or asset sensitivity is missing.
def gcp_audit_evidence_kind(event):
if event.method_name.endswith('SetIamPolicy') and event.scope_is_broad:
return 'direct-detection:T1098'
if event.method_name.endswith('CreateServiceAccountKey') and event.identity_is_unusual:
return 'direct-detection:service-account-key-risk'
if event.method_name.endswith(('DeleteSink', 'UpdateSink')):
return 'direct-detection:T1685.002'
if event.log_type == 'DATA_ACCESS' and event.resource_is_sensitive:
return 'correlation-context:sensitive-data-access'
if event.log_type == 'POLICY_DENIED':
return 'correlation-context:blocked-access'
return 'posture-context'
Most GCP audit detections break when the SIEM parser hides the fields the reviewer needs. Keep logName, resource.type, resource.labels, protoPayload.serviceName, protoPayload.methodName, protoPayload.authenticationInfo.principalEmail, protoPayload.authorizationInfo, protoPayload.requestMetadata.callerIp, protoPayload.status, insertId, timestamp and severity visible in the analyst note or case view.
For each detection, record the Google Cloud source log, the SIEM table or parser, the resource hierarchy covered and the fields required for review. A rule that works for one project can fail silently if another project sends logs through a different sink or excludes Data Access entries to cut cost.
Deprecated payloads make this worse. Google's AuditLog reference marks protoPayload.serviceData deprecated in favour of metadata, yet IAM still carries policyDelta and its auditConfigDeltas inside serviceData, and Google's own IAM audit-logging guidance points defenders at protoPayload.serviceData.policyDelta.auditConfigDeltas to catch audit-config changes on SetIamPolicy. Security researchers at Permiso report that this serviceData payload is often dropped when audit logs are exported to a SIEM, so a detection that separates enabling from disabling audit logging can fail silently while the same SetIamPolicy event still arrives. Treat a serviceData.policyDelta that reaches the SIEM present but empty as a review signal in its own right, and confirm whether each service populates serviceData or metadata before trusting the mapping.
CloudSigma belongs in the CVE and advisory-to-Sigma workflow. GCP audit-log guide work should point operators towards their own Google SecOps, Splunk, Sentinel, Elastic or OpenSearch queries and test data. The coverage claim comes from reproducible audit evidence and field mapping, not from a product label.
Review GCP audit-log detections when a new project or folder joins the organisation, when a service starts sending Data Access logs, when logging sinks or exclusions change, or after an incident shows that a useful audit event was collected but unmapped. Collection scope is part of the detection, not a separate plumbing issue.
A quarterly GCP review should ask which broad IAM changes lack alerts, which sensitive resources do not emit Data Access logs, which detections depend on parser fields that are not present in every SIEM route and which ATT&CK mappings are still marked as correlation context. Those answers give the backlog a useful shape.
DCV records the technique mapping and evidence class beside the Google Cloud source. That lets reviewers separate direct audit-log detections from posture gaps, blocked-access evidence and correlations that need identity or asset context before they deserve an alert.