Temporal Correlation

Temporal correlation connects observations according to when they occurred and how they relate over time. In security investigations, it helps answer questions such as whether an unusual role assumption preceded a permissions change, whether suspicious API activity coincided with application errors, or whether outbound network traffic followed access to sensitive data. The objective is to build a defensible timeline, not merely to collect records with similar timestamps.

Start with a known event and identify its event time, affected resource, account, Region, principal, and available request or session identifiers. Search a bounded interval before and after that event across relevant logs. In AWS, these sources can include CloudTrail events, application logs, load balancer access logs, DNS query logs, and VPC Flow Logs. Expand the interval when evidence suggests earlier preparation, delayed execution, or continued activity. Investigations spanning multiple accounts and Regions require appropriate log coverage and access to those records.

Distinguish event time from ingestion time. Event time describes when an activity occurred according to the producing system, while ingestion time describes when a logging platform received the record. A delayed delivery can make an earlier action appear after a later action if records are sorted by arrival time. Normalize timestamps to a common time zone, usually UTC, preserve their precision, and synchronize clocks on systems under your control. Record uncertainty rather than assuming clocks are perfectly aligned.

For example, an investigator might find a suspicious AssumeRole event at 10:00 UTC, a security-group change at 10:02, and unexpected application access at 10:04. Correlating the assumed-role identity and session context with the API change strengthens the connection between the first two events. Application and network evidence can then help assess subsequent access. A shared source IP alone is weaker evidence because NAT gateways, proxies, and shared infrastructure can cause unrelated users to appear behind the same address.

Choose correlation windows according to the behavior and the source's timing characteristics. A short window reduces noise but can miss slow-moving activity or records affected by clock skew. A broad window improves coverage but increases query cost and false associations. Some records describe intervals rather than individual instants: VPC Flow Logs aggregate network observations, so their start and end times should be considered instead of treating each record as one precisely timed connection. Such records do not establish application-level actions or reveal payload contents.

Reliable correlation also depends on collection configuration. CloudTrail Event history provides recent management events, not a complete history of every data access. Relevant data events, such as S3 object-level operations, must be explicitly configured for collection through an appropriate trail or event data store. Missing records may reflect disabled logging, retention limits, delivery delays, or unsupported visibility rather than proof that an action never occurred.

Preserve original logs and document query boundaries, filters, timestamp conversions, and assumptions. For ongoing detection, account for late-arriving records by reevaluating overlapping windows and deduplicating results using suitable source identifiers. Most importantly, temporal proximity does not prove causation. Validate a proposed sequence with identity, resource, request, and network context before using it to justify containment or remediation.