Incident reconstruction & forensics
Incident reconstruction is what your logging program is ultimately for: the ability to take a suspected compromise and rebuild exactly what happened — which principal acted, on which resources, from where, and in what order — into a timeline that holds up in front of an insurer, a regulator, or a court. That is a harder bar than simply having logs. It depends on the right sources having existed before the incident, on clocks and identities lining up across accounts and providers, on a place to query the data quickly while an attacker may still be active, and on capturing volatile evidence from ephemeral compute before it is destroyed. This sub-topic assesses forensic readiness specifically — not whether logging is on, but whether you could actually reconstruct an incident from what you retain. We look for the gaps that only surface at 2 a.m. during a real investigation, when it is too late to add a log source retroactively.
Overview
What this check looks like in practice
When something goes wrong the question is always the same: what did they touch, when, and from where. Answering it requires that the right logs existed before the incident, are correlated across accounts, and can be pieced into a defensible timeline. We assess whether you could actually rebuild an incident rather than assuming the data is there.
Why it matters
In a cloud intrusion the logs are usually the only witness, and the reconstruction is what determines the real questions: what data was reached, whether notification obligations were triggered, and how far the attacker got. An adversary who understands this works to break the timeline — assuming roles to blur identity, operating from short-lived instances that terminate and take their evidence with them, and moving across accounts to defeat correlation. If flow logs, DNS logs, or data-plane events were never captured, or if timestamps and principals cannot be joined across sources, the investigation stalls at "something happened here" without ever proving scope — which forces the most expensive assumption, that everything was exposed. Auditors and cyber-insurers probe forensic readiness directly, because the ability to produce a defensible timeline is the clearest evidence that an incident-response program is real rather than aspirational, and it maps straight to NIST CSF Respond and Recover, PCI-DSS Requirement 10, HIPAA audit and review controls, and ISO 27001 incident-management requirements.
What we assess
What we look for
- Source breadth sufficient to trace lateral movement end to end — control-plane audit logs plus VPC/VNet/NSG flow logs, DNS query logs, and service and data-plane logs — so an intrusion can be followed hop by hop rather than only at the API surface
- A pre-provisioned query surface (CloudTrail Lake or Athena, Sentinel KQL, BigQuery log analytics or Chronicle) that investigators can run cross-account queries against under pressure, instead of standing up tooling mid-incident
- Consistent UTC timestamps and clock synchronization across accounts, regions, and providers, so events from multiple sources merge into one coherent, ordered timeline
- Identity attribution preserved end to end — principal, assumed-role session name, source IP, and user-agent captured — so each action maps back to a specific human or workload and its origin
- A forensic-capture path for ephemeral compute: automated snapshot or disk acquisition (and, where feasible, memory capture) of instances and containers before they are terminated and their evidence is lost
- Evidence isolation and chain of custody — a dedicated, access-controlled forensics account or project holding immutable copies — so acquisition neither tips off the attacker nor contaminates the original
- Retention that provably exceeds realistic attacker dwell time, so the earliest foothold is still inside the queryable window when the investigation actually begins, not aged out
- Evidence that reconstruction has been exercised — a tabletop or replayed scenario confirming the sources correlate and the queries return — rather than an untested assumption that the data is there
Across your clouds
AWS, Azure & Google Cloud
AWS
Trace end to end with CloudTrail (management and data events), VPC Flow Logs, and Route 53 Resolver query logs; retain and query at scale using CloudTrail Lake or Athena over S3, and correlate identity, network, and finding data into an investigation timeline with Amazon Detective. Acquire volatile evidence via EBS snapshots and SSM-driven capture, held in a dedicated forensics account reached by cross-account roles.
Azure
Reconstruct across subscriptions with Microsoft Sentinel, using KQL hunting and the investigation graph over Activity logs, resource Diagnostic settings, and VNet flow logs (the successor to the retiring NSG flow logs), with Log Analytics archive tiers extending the queryable window. Defender for Cloud correlates alerts into incidents, and VM disk snapshots captured to an isolated subscription or immutable storage preserve host evidence.
Google Cloud
Query retained Cloud Audit Logs (Admin Activity plus Data Access), VPC Flow Logs, and Cloud DNS logging through Log Analytics (BigQuery-backed) or a BigQuery log sink for timeline analysis, with Security Command Center and Google SecOps (Chronicle) for cross-source correlation and long retention. Persistent-disk snapshots taken to a separate forensics project preserve instance evidence before deletion.
Example finding
Control-plane audit logs are retained, but VPC Flow Logs and DNS query logs are disabled, and no cross-account query tooling exists
Risk: An investigator could see which API calls a compromised principal made, but not what the attacker's instances connected to, whether data was exfiltrated, or which command-and-control domains were resolved — leaving the intrusion's network path and blast radius unprovable. With no pre-built query surface, responders would also lose hours standing up tooling while the attacker may still be active.
Fix: Enable VPC/VNet/NSG flow logs and DNS query logging across all production accounts and route them to the central logging store, then stand up a queryable investigation layer (CloudTrail Lake, Sentinel, or BigQuery/Chronicle) with a saved set of reconstruction queries so a timeline can be built from network, identity, and audit data in one place.
Remediation
How to close it
- 1 Inventory the log sources an end-to-end investigation actually needs — control-plane audit, data-plane, VPC/VNet/NSG flow, and DNS query logs — and enable the ones missing across every account, subscription, project, and region.
- 2 Consolidate those sources into a single queryable investigation layer (CloudTrail Lake or Athena, Microsoft Sentinel, or BigQuery log analytics with Google SecOps) so cross-account, cross-source correlation is possible without assembling tooling during an incident.
- 3 Normalize time and identity: confirm all sources emit UTC timestamps and that principal, assumed-role session, source IP, and user-agent fields are preserved so events join into one attributable timeline.
- 4 Build a forensic-acquisition capability for ephemeral compute — automated disk snapshots and, where feasible, memory capture for instances and containers — delivering copies into a dedicated, access-controlled forensics account or project with immutability enabled.
- 5 Set retention on the reconstruction-critical sources to exceed realistic attacker dwell time, using archive tiers where available so cost stays manageable while the earliest foothold remains queryable.
- 6 Validate the whole chain with a tabletop or a replayed scenario, confirming the queries return, the timeline holds together across accounts and providers, and evidence handling preserves chain of custody.
Questions
Isn't reconstruction the same as having audit logs?
No — audit logs are a necessary source but not sufficient. Reconstruction also depends on network and DNS logs to trace movement, on synchronized time and preserved identity fields so events correlate, on a place to query the data quickly, and on capturing volatile evidence from short-lived compute before it disappears. We assess whether those pieces line up into a defensible timeline, not just whether logging is enabled.
Can you reconstruct an incident for us during this assessment?
The health check is read-only and focused on forensic readiness — whether the sources, retention, correlation, and capture capability exist so that you could reconstruct an incident if one occurred. Actively investigating a live or suspected breach is separate incident-response work; the assessment tells you whether you are equipped for it before you need it.
How much log retention do we actually need for forensics?
Enough to cover realistic attacker dwell time plus your longest audit or regulatory window, because attackers frequently establish a foothold well before discovery. If the earliest activity has already aged out when an investigation starts, the timeline is incomplete no matter how good the tooling is — so we check retention against dwell time, not just the provider default.
More in logging & monitoring
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
