Three log sources disagree by minutes about one intrusion - how do you produce an ordering you can defend?

## The account is only as strong as its weakest clock At the end of an investigation you have to say what happened and in what order. Three sources - an identity provider, a network appliance and an endpoint agent, say - will typically disagree by seconds to minutes about the same moment. Someone will read your account who was not there, possibly under legal privilege, possibly a regulator, possibly opposing counsel. The goal is not the prettiest sequence; it is an ordering whose every step you can still justify when the person opposite has an incentive to break it. ## Step 1: name the clocks For each source, write down whose clock produced the timestamp and what its format tells you. An identity provider or cloud control-plane record is stamped by the provider's own infrastructure, which is usually well synchronised and explicitly UTC. An endpoint agent's records come from the host's clock. A network appliance may be emitting local time with no offset at all. These are three different levels of trust and they should not be averaged together as if they were measurements of the same quantity. ## Step 2: measure the offsets with anchor events An **anchor event** is one occurrence that two sources independently recorded. Examples that actually work: - a single authentication logged by both the identity provider and the device that consumed the resulting session; - one outbound connection recorded by both the proxy and the network flow exporter; - a name lookup in the DNS query log followed by the connection to the address it concerns. The difference between the two timestamps for that single occurrence is the offset between those two clocks. Repeat over several anchors spread across the incident window: a flat offset is a configuration error you can subtract with confidence, a growing offset is drift, and a step of exactly an hour is a timezone or daylight-saving transition. Record the *spread* of your anchor measurements too - that spread is your uncertainty, and it is the number that will limit your claims. When no event appears in two sources at all, you have two fallbacks. Generate one, if the systems are still live and you are permitted to: perform an action both sources must record and read the offset from the pair. Or fall back on collector receipt time, which at least comes from a single clock and therefore orders *arrivals* consistently - but say so explicitly, because arrival order is not occurrence order and only approximates it when the sources' lags are comparable. ## Step 3: let causality beat the clocks Where two events sit inside each other's uncertainty band, the timestamps cannot order them, but the world often can. A VPN session cannot begin before the authentication that authorised it. A response cannot precede its request. A connection to an address cannot precede the lookup that produced it. A token cannot be used before it is issued. These constraints are not estimates; they hold regardless of what any clock says, and they let you order events that your measurements alone leave ambiguous. This is also the cheapest skew detector you have. Any causal violation in your normalised data - an effect before its cause - is a signal that an offset is still wrong, not a discovery about the intrusion. ## Step 4: write the uncertainty into the account The failure mode this whole discipline exists to prevent is false precision. An account that says *at 02:43:17 the archive was written and at 02:44:02 it was uploaded* reads authoritatively and collapses the moment someone asks how the appliance's clock was validated. Write instead in UTC with the band attached: *the upload is recorded by the proxy at 02:44 UTC; the appliance's clock was measured seven minutes behind UTC across five anchor events over the incident window, so the session it attributes to 02:41 falls at approximately 02:48 UTC, plus or minus the 40-second spread of those measurements.* Nobody has ever been criticised for that sentence. Three habits go with it: - **Everything in UTC in the narrative**, with the raw local values kept in the underlying data rather than deleted. - **Offsets stated once, near the top**, per source, with how they were measured and over what period they are valid. - **Concurrency admitted.** If two events are three minutes apart and the relevant offset uncertainty is seven, they are concurrent as far as you can tell. Say that, and say what would resolve them - a source with a trusted clock, a causal link, an artefact that can only exist after both. ## Step 5: separate the claims that depend on ordering Finish by sorting your conclusions into two piles. Most survive the uncertainty entirely: the account was used, the archive was staged, data left the estate. A few *depend* on ordering inside the band - whether the data left before or after the credential was reset, whether the intruder acted before or after the containment step, whether an employee's action preceded a notification they received. Those are the ones that carry consequences for people, and they are exactly the ones a weak account asserts and a strong one flags. If a claim of that kind rests on a three-minute gap between two clocks that are seven minutes apart, the honest answer is that the evidence does not settle it - and saying so early is far cheaper than having it dismantled later.