Timelines, Sequence and Causality

What is it?

A timeline is the ordered sequence of correlated events on one axis of time, corrected for the fact that different sources keep different clocks. Sequence is the order events actually happened in; causality is the claim that an earlier event made a later one possible.

Why it matters

An intrusion is a story with an order: you cannot exfiltrate before you have access, and you cannot execute before you deliver. Getting the order wrong inverts cause and effect and produces a confident, false conclusion. Most weak Tier-2 reports fail here, not on the evidence itself.

Where you see it

Every log line carries a timestamp, but from different clocks: the SIEM's ingest time, the host's local time, a firewall in UTC, an application in a local zone. The true timeline lives after these are normalised to one zone and checked for skew.

What normal looks like

In normal operations, timestamps across sources agree within a small, consistent offset once time zones are aligned, because hosts synchronise to a time server. Small, stable differences are expected and harmless.

What suspicious looks like

A large or shifting clock offset on one host, timestamps that place an effect before its cause, or gaps where expected events are missing. Attackers sometimes tamper with host clocks or clear logs, so an impossible order is itself a finding.

How analysts investigate

Normalise every timestamp to one zone (UTC is the safe default). Anchor on an event whose time you trust, measure each source's offset against it, then rebuild the sequence. Only after the order is trustworthy do you argue causality — and only where one event genuinely enables the next.

Common beginner mistakes

Sorting events by their raw timestamps without normalising time zones, producing an order that never happened.
Assuming that because B follows A in time, A caused B — mistaking sequence for causality.
Ignoring a missing expected event, when the gap itself may be the most important part of the timeline.

What you will be able to do

Normalise timestamps from different sources onto one time zone.
Detect and quantify a clock offset on a host.
Tell sequence apart from causality, and recognise an impossible order as a finding.

Once you have gathered correlated events, the next job is to put them in the order they truly happened. That is harder than it sounds, because the timestamps you are handed come from clocks that do not agree. Normalise first; reason second.

Three sources, raw timestamps (before normalisation)

SIEM ingest   12:17:04Z   alert: beacon on WS-071
Endpoint      08:16:59    rt.exe started        (host local, UTC-4)
Firewall      12:17:01Z   WS-071 -> 45.9.148.200

Read raw, the endpoint event looks four hours earlier. It is not — the host clock is UTC-4. Normalised, rt.exe starts at 12:16:59Z, just before the firewall flow.

Worked example — before or after?

A host in zone UTC-4 logs rt.exe starting at 08:16:59 local time. Two UTC sources bracket it: a firewall flow at 12:17:01Z and a SIEM alert at 12:17:04Z. Before reading on, decide: in UTC, does rt.exe start before or after the firewall flow?

The answer: before, by two seconds. Add the +4 offset — 08:16:59 local is 12:16:59Z — which is just ahead of the 12:17:01Z flow. The order is coherent: the process starts, then it beacons out. Read raw, the endpoint event looked four hours early and impossible; normalisation put it back in its true place.

Recap

Normalise all timestamps to one zone before you reason about order.
Sequence is the order events happened; causality is the claim one enabled the next.
An impossible order after normalisation is itself a finding, not a data quirk to ignore.