Establishing a Timeline

Over the years, I have trained many students to become SOC analysts and, eventually, threat hunters. Timelines are one of the concepts people tend to underestimate. They are often imagined as a straight line from point A to point B.

An investigation timeline is more demanding. It is a reconstruction built from observations that were recorded by different systems, at different moments, with different clocks and retention limits. It should help us understand what happened, what may have happened, and where the evidence is incomplete.

What belongs in a useful timeline

A strong timeline is not just a timestamp and a sentence. I normally want these fields:

A compact case table might look like this:

The assessment column matters. Without it, interpretation tends to be written as fact.

A practical confidence scale

Confidence belongs to the assessment, not to the raw observation. Use the words consistently and record why a level was chosen.

Confidence describes how strongly the available evidence supports an assessment. It is separate from both severity and the assessed likelihood of the event. A high-confidence benign explanation and a low-confidence high-impact concern are both possible.

When evidence changes, update the confidence and preserve the reason. Do not quietly rewrite the earlier judgement.

Start with an anchor, not a beginning

Most investigations do not begin at initial access. They begin with an anchor:

• an alert
• an unusual sign-in
• a suspicious process
• a file
• a user report
• an outbound connection
• a change to an account or system

The anchor is where you start searching, not necessarily where the incident started. Move both backwards and forwards in time:

earlier context <- anchor observation -> later consequences

Backward pivots can reveal delivery, authentication, staging, or a parent process. Forward pivots can reveal execution, persistence, lateral movement, collection, exfiltration, or impact.

Phases are labels, not required boxes

A case may contain behaviours associated with initial access, execution, persistence, privilege escalation, lateral movement, collection, command and control, exfiltration, or impact. These labels can help readers navigate the sequence, but an investigation should not invent a phase merely to complete a familiar attack chain.

The sequence may branch, overlap, repeat, or remain incomplete.

An illustrative timeline

The following scenario is deliberately simplified. It demonstrates the shape of a reconstruction, not a universal attack path and not evidence from a live case.

The starting hypothesis is:

Outbound activity from a sensitive system may represent data exfiltration. Determine what initiated the connection, what data was involved, and how far back the supporting activity can be traced.

The hunter begins at the outbound connection and pivots in both directions. The resulting evidence supports this working sequence:

This diagram does not prove causality by itself. Each arrow should be backed by evidence and assessed separately. For example, a sign-in after a phishing message does not prove credential theft unless identity, session, user, and interaction evidence support that link.

Ordering problems to expect

Event, ingestion, and processing time

Several timestamps can describe the same record:

Use event time as the primary reconstruction axis when its quality is understood. Use ingestion and processing time to investigate collection delay, rule execution, alert timing, and pipeline behaviour. Preserve all available timestamps rather than replacing one with another.

Clock drift and timezone conversion

Endpoint, network, SaaS, identity, and email systems may use different timezones or have imperfect clocks. Preserve original values and document normalisation. Do not silently shift timestamps until the sequence looks plausible.

Collection and ingestion delay

An event can arrive in the SIEM minutes or hours after it occurred. Use event time for reconstruction and ingestion time to understand collection behaviour. They answer different questions.

Duplicate and transformed events

Forwarders, connectors, retries, and normalisation pipelines can duplicate or alter records. Deduplicate only when you understand which identifiers and transformations are stable.

Missing events

An absence may be consistent with an action not occurring, but it can also indicate collection gaps, retention limits, filtering, clock problems, parsing failures, or deliberate removal. State which explanation the evidence supports.

Reused identifiers

Process IDs, logon IDs, IP addresses, filenames, and cloud session values can be reused or scoped locally. Pair them with device, timestamp, boot or session context, and stronger identifiers where available.

Conflicting observations

Two sources can disagree because they observe different stages, use different clocks, transform fields, or attach time at different points. Preserve both observations. Compare source semantics, raw timestamps, identifiers, clock quality, ingestion delay, and collection path before deciding whether they describe the same activity.

If the conflict cannot be resolved, keep the competing interpretations in the case record. An unresolved contradiction is evidence about the limits of the reconstruction, not a reason to select the tidier version.

Building the timeline

1. Preserve the anchor event and its raw fields.
2. Convert time carefully while retaining the original timestamp and timezone.
3. Identify the source viewpoint and what the record can actually establish.
4. Add earlier and later observations without deciding the full story yet.
5. Correlate on stable identifiers where possible.
6. Separate observations from assessments.
7. Test alternative explanations for each important link.
8. Mark gaps, contradictions, clock concerns, and collection boundaries.
9. Summarise the supported sequence at the level of confidence the evidence allows.
10. Keep references that let another analyst reproduce every key event.

Evidence and narrative timelines

One timeline rarely serves every audience equally well.

Build the narrative timeline from the evidence timeline. Do not let the shorter report become the only record of the technical reconstruction. A reader should be able to trace every material narrative statement back to its supporting evidence.

Timelines in reports

A report timeline should help different readers answer different questions:

Avoid filling the report with every benign event. Include what explains the sequence, changes the assessment, defines scope, or documents a meaningful gap.

A good timeline does not make the case look cleaner than it was. It makes the reasoning inspectable.

Resources

• NIST IR 8354, Digital Investigation Techniques
• NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response
• ODNI ICD 203, Analytic Standards

Revision