Google Cloud and the Foundations of Cloud-Based Digital Forensics

Why Google Cloud Matters for DFIR

Most enterprise workloads still run on-premise, not because cloud platforms are weak, but because migration introduces architectural and operational complexity.

Unlike traditional environments, investigators in Google Cloud cannot rely on physical access, predictable network paths, or full host-level visibility.

Instead, identity events, service-level logs, and resource metadata become the primary evidence sources.

Today, most of the world's enterprise computing still happens on-premise. It hasn't moved to the cloud yet, because the path forward is complex and daunting, and full of difficult decisions.

• How do you modernize in-place without having to jump completely to the cloud?

• How do you bridge incompatible architectures while you transition? A

• nd how do you maintain flexibility and avoid lock-in?”

— Sundar Pichai, Google's CEO, Google Cloud Next 2019

And the scale behind it: at the time this curriculum was written, Google Cloud was the third-largest cloud provider by market share (behind AWS and Azure) but the fastest-growing of the three, with analysts forecasting overall public cloud spend to grow 18.4% that year. Faster growth means more new, less-mature deployments — exactly why cloud infrastructure keeps landing in threat actors' crosshairs.

------------------------------------------------------------------------------------------------------------

Google Cloud Global Architecture (DFIR Angle)

Google Cloud is built on regions and zones:

• Regions are geographic areas (e.g., Europe-West, US-Central)

• Zones are isolated deployment areas within regions

Why this matters for DFIR:

• Evidence may be generated in one zone and stored or processed in another

• Data residency and regulatory requirements apply when collecting evidence

• Network paths inside Google Cloud are abstracted and not traceable

You cannot reconstruct packet paths like on-prem networks. Investigations must focus on what happened, who did it, and which resource was affected, not how traffic flowed.

Worth naming the real scale here instead of leaving “regions and zones” abstract: Google Cloud runs 25 regions and 76 zones, with more added regularly.

And there's a concrete reason network paths are abstracted: Google interconnects those regions using a mix of its own dedicated network links and shared submarine cables. Redundancy varies a lot by geography too — the US has heavy ingress/egress redundancy, while regions like Australia have comparatively limited links. That's part of why you can't reconstruct a packet path the way you would on-prem — the routing is spread across infrastructure you don't get visibility into, by design.

------------------------------------------------------------------------------------------------------------

Core Google Cloud Services for Incident Response & Forensics

These five services provide the highest forensic value during cloud incidents:

1. Identity & Access Management (IAM)

2. Compute Engine (VMs)

3. Cloud Logging

4. Cloud Networking

5. Cloud Storage Buckets

Almost every cloud compromise touches IAM + Logging + Compute

------------------------------------------------------------------------------------------------------------

Google Cloud Resource Hierarchy (Critical for Investigators)

Google Cloud follows a strict hierarchy:

Organization
 └── Folder(s)
      └── Project(s)
           └── Resource(s)

Breakdown

Organization

• Highest level in Google Cloud

• Usually mapped to a company’s domain

• Often linked with Google Workspace

• Central point for IAM and security policies

From a DFIR perspective, this is where global controls and investigation-wide visibility are established.

Folders

• Used to group teams, environments, or functions

• Policies applied here affect everything beneath them

• Can have multiple layers (sub-folders)

DFIR benefit:

• Separate DFIR resources from production

• Apply investigation-specific policies

• Limit blast radius during incidents

Projects

• Where services actually run

• Billing and resource ownership boundary

• Minimum requirement for creating resources

Most compromises are identified inside projects, making them the primary focus during investigations.

Resources

• Compute, Storage, Networking, Logging, etc.

• Inherit permissions and constraints from above

• Generate most forensic artifacts

Example

• Organization: novaharbor.io (the company's primary domain)

• Folder: Incident-Response — isolates DFIR tooling from production

• Sub-folder: dfir-sandbox — a further split for one-off investigation VMs

• Project: evidence-processing-prod — where the actual acquisition/processing VMs and storage buckets live

• Resources: a Compute VM running Plaso, a Storage Bucket holding disk images

Policies applied at the Incident-Response folder level — read-only visibility for DFIR staff, a ban on disabling logging — automatically apply down through dfir-sandbox and evidence-processing-prod without touching each resource individually. That's the practical payoff of the hierarchy: set it once at the folder, and every project and resource under it inherits it.

------------------------------------------------------------------------------------------------------------

IAM vs Policies (Very Important Distinction)

Concept	Controls
IAM	Who can access resources
Policies / Constraints	What resources can do

Example:

• IAM: Who can access a VM

• Policy: Whether logging can be disabled on that VM

Use policies to:

• Prevent attackers from:

  • Disabling logs

  • Creating resources in rogue regions

• Lock down compromised assets instantly

------------------------------------------------------------------------------------------------------------

Google Cloud Organization Benefits for DFIR

What DFIR Teams Can Do Quickly

• Apply constraints globally

  • Allowed VM templates

  • Approved regions only

• Grant DFIR read-only visibility everywhere

• Prevent destructive actions:

  • Turning off logging

  • Deleting evidence

• Isolate compromised projects without downtime

------------------------------------------------------------------------------------------------------------

Key Google Cloud Resources Attackers Abuse

Focus first on these during investigations:

Compute & Platform

• Compute Engine

• App Engine

• Kubernetes Engine

Storage

• Cloud Storage

• Filestore

Ops & Visibility

• Logging

• Monitoring

Networking

• VPC

• Network Security Services

------------------------------------------------------------------------------------------------------------

Data Transfer Pricing (Why DFIR Teams Get Burned)

Important Cost Rules

• Same zone + internal IP → No cost

• Different zone or region → Cost

• VM-to-VM traffic can incur:

  • Egress

  • Response ingress (TCP)

Google Cloud was not charging for ingress traffic into a resource — only egress and cross-zone/region movement carried a cost. That's subject to change, so always check Google Cloud's current pricing page before assuming it still holds; don't bank an evidence-transfer plan on a pricing detail that could shift.

DFIR Best Practices

✅ Place DFIR VMs in:

• Same region

• Same zone

• Use internal IPs only

Avoid:

• Moving evidence across zones

• Exporting raw evidence unnecessarily

------------------------------------------------------------------------------------------------------------

Cost Reduction Options for DFIR

1. Preemptible VMs

• Cheaper

• No guaranteed CPU

• Good for:

  • Distributed tasks

• Bad for:

  • Single-VM processing (e.g., Plaso)

2. Keep Processing Local

• Same zone = free internal traffic

• Faster acquisition & analysis

3. Be Smart with BigQuery

• Charged per bytes processed

• Reduce cost by:

  • Fewer queries

  • Better SQL

  • Documenting results to avoid reruns

BigQuery actually bills on two separate axes: the cost of holding data in a table, and the cost of querying it. The tips above (fewer queries, better SQL, documenting results) only reduce the second one — there isn't much you can do to reduce storage/holding cost once evidence is sitting in BigQuery, so factor that in when deciding how long to keep large exported log sets there versus moving them to cheaper cold storage.

------------------------------------------------------------------------------------------------------------

Key Takeaways

• IAM + Policies = Cloud Incident Control Plane

• Folder & project structure directly affects response speed

• Logging enforcement is your strongest defense

• Data movement = cost + legal risk

• DFIR architecture planning matters before incidents happen

--------------------------------------------Dean-----------------------------------------------------------