Timeline Reconstruction

Timeline reconstruction turns scattered observations into an evidence-backed account of a security incident. Investigators identify relevant events, normalize their timestamps, connect identities and resources, and explain the sequence from the earliest supported activity through containment and recovery. The objective is not simply to sort logs: it is to determine what the evidence establishes, what remains uncertain, and which conditions allowed the incident to occur.

In cloud environments, evidence usually spans multiple accounts, Regions, services, and operating systems. Control-plane audit logs show API activity, workload logs show application and operating-system behavior, network flow records describe communications, and configuration histories show resource state changes. A useful timeline preserves each event's source, original timestamp, normalized time, principal, resource identifier, action, result, and reference to the original evidence. Investigators should also record their own containment actions so that response activity is not mistaken for attacker behavior.

Begin with a known event, such as an unexpected access-policy change or a suspicious credential-use finding. Search backward to identify preceding authentication, role assumption, resource discovery, and permission changes, then search forward to determine impact and persistence. Expand the investigation window when earlier evidence suggests that the initial alert occurred well after compromise. Correlate stable identifiers such as access key IDs, role session identifiers, resource IDs, and request IDs where available; a shared source IP address alone does not establish that two actions came from the same actor.

For example, an investigator might connect an AWS Security Token Service AssumeRole event to subsequent API calls made with the resulting temporary credentials, followed by a bucket policy change and object reads. AWS CloudTrail can provide the relevant API evidence, but object-level reads require applicable data-event logging to have been enabled. AWS Config can help establish how the recorded bucket configuration changed, while workload and network evidence may clarify how the credentials were exposed. If evidence begins with use of a stolen credential, that proves credential use, not necessarily how the theft occurred.

Time handling requires particular care. Normalize timestamps to UTC while retaining original values, distinguish event time from ingestion time, and account for clock skew on workloads. Logs can arrive late, contain duplicates, or represent activity over an interval rather than a precise instant. Network flow records, for example, aggregate traffic and do not reveal packet contents. Treat events with overlapping uncertainty windows as potentially concurrent rather than forcing an unsupported exact order.

Amazon Detective supports this process by presenting relationships and activity across entities such as principals, IP addresses, and resources. These views help investigators explore hypotheses and scope an incident, but they do not independently prove causation or replace underlying evidence. A configuration change immediately before an alert might explain the alert, or both might result from an earlier compromise.

Completeness depends on preparation. Enable appropriate logging, centralize evidence across account and Region boundaries, establish retention, and protect access to original records. Preserve provenance and use integrity controls where available; CloudTrail log file integrity validation can help detect changes to delivered log files when configured. More detailed collection improves investigative coverage but increases storage costs, query costs, and sensitive-data handling requirements. Missing events are not proof that an action never occurred. A defensible root cause analysis explicitly separates confirmed observations, supported inferences, evidence gaps, and corrective actions addressing the underlying control failure.