Home › Methodology › Correlation & timeline

Cross-domain correlation and adversary timeline reconstruction

A single alert is a fact about one event. An intrusion is a sequence of them, across identities, hosts, sessions and clouds, in an order that matters. This page sets out what the model expects when it asks whether related alerts are assembled into a narrative of adversary progress, how that expectation rises with maturity, and which of the several things called a “path” is which.

TID-CMM assesses whether the organisation has this capability. It does not perform it. The assessment tool is not a SIEM, an XDR or a live correlation engine. It does not ingest alerts, correlate events, reconstruct incidents or predict adversary activity, and nothing on this page describes something the tool does to your data. It describes what a correlation capability must be able to do, and what evidence shows that it does.

The capability, and what supports it

The primary sub-capability is AA.2, correlation and attack-chain assembly: are related alerts assembled into a single narrative of adversary progress, or triaged as isolated events? Five others decide whether AA.2 has anything to work with.

Sub-capability	Role in correlation and reconstruction
`AA.2` Correlation and attack-chain assembly	The capability itself: from isolated alerts, through entity and time correlation, to tactic progression, to a reconstructed path against the real estate. The progression below is its level ladder.
`AA.1` Triage enrichment and context automation	Supplies the attributes correlation joins on and ranks by — asset criticality and owner, identity role and privilege, recent related activity, exposure state, prior case history. Without enrichment, correlation groups events by string equality and calls it a chain.
`AA.6` Case management and knowledge capture	Where a correlated incident, its timeline and the analyst’s corrections are recorded in a structure that can be analysed later. A reconstruction that lives in one analyst’s notebook is not evidence.
`TM.4` Attack path and exposure analysis	Provides the computed paths through identity, network and cloud relationships that a reconstructed timeline is compared against, and that a predicted next step is drawn from.
`DC.2` Telemetry quality, completeness and timeliness	Decides whether the timeline can be trusted. Ingestion latency, clock accuracy and known-gap periods are all timeline defects; at level 4 the gaps are recorded so a reconstruction can mark its blind periods.
`DC.3` Normalisation and data model discipline	Makes the join possible. Entity resolution — the same user, host, process and identity carrying the same key across sources — is defined at level 3, and without it cross-domain correlation is a bespoke search per incident.

The maturity progression

Correlation matures in recognisable steps. Each one changes what the analyst is looking at, and each one has a level on the AA.2 ladder it corresponds to.

Stage	What exists	What the analyst sees	`AA.2`
Independent events	Telemetry is collected. Nothing relates one record to another.	Search results.	0
Individual alerts	Detections fire on single events. Each alert is a case, or a dismissal.	A queue, ordered by arrival.	0–1
Entity and time correlation	Alerts on the same host or user within a window are grouped.	A cluster, with a count.	2
ATT&CK tactic progression	Grouped alerts are annotated with the tactic each represents, in order.	How far along the chain the adversary is: initial access, then execution, then credential access.	3
Correlated incidents	Alerts are assembled into incidents along entity and temporal relationships, and the incident, not the alert, is the unit of work.	One case with a narrative, not eleven alerts.	3
Adversary timeline reconstruction	Weak signals are aggregated into scored entities; the incident is ordered into a timeline with observed and inferred steps marked, and correlation quality — false grouping, missed grouping — is reviewed.	What happened, in what order, with what confidence, and where the record is silent.	4
Cross-domain graph reconstruction	Graph-based correlation spans identity, endpoint, cloud and network and reconstructs the path taken against the estate’s real topology.	The route: which identity reached which host through which session to which store.	5
Likely next-step prediction	The reconstructed position is compared with attack-tree and computed-path data to predict where the adversary goes next.	The two or three edges the adversary is most likely to take from here.	5
Pre-emptive containment handoff	The prediction is handed to response with enough context to act before the next step is observed.	A containment decision framed as a choice, with the evidence attached.	5 → TIR-CMM

The last two rows are where the boundary sits. Predicting the next step is analytics; deciding whether to sever the path, with what authority and inside what window, is response, and it is assessed by TIR-CMM. The boundary page draws the line.

An illustrative multi-step attack, as an assessment reads it

The assessment does not draw this picture from live data. It records, for each step of a scenario you have modelled or tested, whether the activity is observable, whether a detection is deployed, whether it was locally validated, and whether the step can be joined to the previous one on a shared key. The figure shows one such reading.

Illustrative multi-step attack toward a crown jewel, and what an assessment records at each step
The assessment records	1 · Initial access	2 · Identity compromise	3 · Execution and persistence	4 · Lateral movement	5 · Data access or operational objective
Observable activity	● Observed	● Observed	○ Blind: required telemetry not collected	◔ Inferred from surrounding evidence	● Observed
Deployed detection	✓ Deployed and evidenced	✓ Deployed and evidenced	✗ None possible without telemetry	✗ None deployed	✓ Deployed and evidenced
Locally validated	✓ Validated within the window	⌛ Validation expired: counts as deployed, not proven	– Nothing to validate	– Nothing to validate	✗ Not validated
Transition from the previous step	▸ Start of the chain	→ Correlated on a shared identity key	⋯ Broken: no shared key, nothing observed	⋯ Inferred, not evidenced	→ Correlated on a shared host key

How this chain reads. Detected at two distinct stages with one validated detection, so it is covered under the Scenario Coverage Score rule. It is not reconstructible in order: step 3 is blind and the transition into it is broken, so an analyst would see the start and the end without the middle. Earliest detectable stage: 1. Next evidence-based improvement: collect the telemetry step 3 needs.

An illustrative assessment example, not a claim that every attack follows this sequence. Shapes and words carry the state; colour is secondary. Observed is directly supported by telemetry, inferred is supported by correlation and surrounding evidence, and a hypothesised or inferred step is never shown as an observed fact.

The scenario register

Step 8 of the tool holds the register. Each scenario carries an identifier and name, an objective, the crown jewel it reaches, the actor or hypothesis, the ordered techniques and their stages, the entities involved at each step, the time window, the test date, method and artefacts, and the result. Each step carries three separate states — observed, inferred or hypothesised; detected or not; validated or not — and its correlation keys: identity or account, host or device, process and parent process, session, cloud principal, IP or network connection, container or workload, application trace, API request, or transaction or case identifier. A transition is joined only when the two steps share a key and the join is evidenced; everything else is a broken transition, and a chain with a broken transition or a hypothesised step is not reconstructible in order. The timeline distinguishes observed, inferred and hypothesised by shape and word, and a predicted or inferred step is never shown as an observed fact. Coverage uses the existing Scenario Coverage Score rule unchanged: two or more distinct stages detected, at least one locally validated. The scenarios step.

Five things that are related, and not interchangeable

The word path is doing five jobs on this site. Each is legitimate; confusing them is how a hypothesis ends up in a board report as a fact.

	What it is	Where it comes from	What it can and cannot support
A modelled attack path	A route an adversary could take to a crown jewel, drawn as an attack tree or computed from identity, network and cloud relationships. Prospective.	Threat modeling (`TM.3`, `TM.4`) and the attack-path step of the assessment, which marks the Tier A techniques.	Supports scoping, choke-point instrumentation, deception placement and hunt hypotheses. Is not evidence that anything happened.
A derived TIR-CMM export path	A path the assessment tool builds for the TIR-CMM handoff: one per selected actor, from the Tier A techniques that actor is documented using, stages mapped from tactics, asset classes from the declared crown jewels. Derived, and the file says so.	The TIR-CMM export.	Supports pre-filling a response assessment. Is neither a modelled tree nor an observation; it is a projection of the scope into TIR-CMM’s lattice.
An observed incident timeline	What the telemetry actually recorded, in order, about a real intrusion. Retrospective, and only as complete as the collection was.	Correlated incidents (`AA.2` level 3–4), case records (`AA.6`).	Supports a verdict, a response decision and a detection gap analysis. Cannot show what happened in a blind period.
A reconstructed adversary path	The analyst’s account of the route taken, built from the observed timeline plus topology, with inferred steps and confidence marked. Retrospective and interpretive.	`AA.2` level 4–5, checked against `TM.4` paths.	Supports lessons, model updates and emulation plans. Every inferred edge must carry its evidence or be marked as inference; it is not a recording.
A predicted next step	Where the adversary is likely to go from the reconstructed position. Predictive, and a hypothesis.	`AA.2` level 5, from attack-tree and computed-path data.	Supports pre-emptive containment as a decision framed with uncertainty. Is not something the adversary has done, and must never be recorded as if it were.

What the capability needs

Correlation joins on entities and orders by time. Both have to exist in the data in a form that can be joined and ordered, which is why DC.3 is in the table above. The inputs the model expects to find, normalised and resolvable across sources:

User and service identities, including the mapping between a human, their accounts and the service principals they can assume.
Cloud principals: roles, managed identities, OAuth applications and the trust relationships between them.
Authentication sessions: the token, ticket or session that links a logon on one surface to activity on another.
Hosts and endpoints, with stable identifiers that survive re-imaging, renaming and address changes.
Processes and parent–child relationships, so execution can be traced back to what launched it.
IP addresses and network connections, resolved to hosts and principals at the time of the connection, not at the time of the query.
Applications and workloads: containers, functions, jobs and the services they run as.
Email and collaboration identities: mailboxes, shared mailboxes, collaboration accounts and their delegations.
Asset criticality, from the crown-jewel register, so the graph can be ranked as well as drawn.
Crown-jewel relationships: which identities, hosts and workloads can reach which jewel, from TM.4.
ATT&CK behaviours, so each observed step carries a technique and a tactic and the progression can be read against the chain.
Normalised timestamps and clock quality: one time base, recorded ingestion latency, and a known clock skew per source. A timeline built on unsynchronised clocks orders events wrongly and does so confidently.

What it must produce, and what counts as evidence

A correlation capability is scored on its outputs, and the outputs are the evidence C3 asks for at level 4 and above. Each item below is something an assessor should be able to open.

Output	Why it has to be recorded
Correlated incident	The unit of work. Its existence, with its member alerts, shows assembly happened; the alert-to-incident ratio over time shows how much.
Ordered timeline	Observed steps in sequence on one time base. The first thing a response decision, a lessons-learned review and a regulator will ask for.
Entity relationship graph	Which identities, hosts, sessions, processes and workloads are connected, and how. The structure the path is read from.
ATT&CK tactic progression	Where in the chain the adversary was at each step. Makes the incident comparable with the threat model and with emulation results.
Confidence and uncertainty	Per relationship and per step. Without it an inferred edge and an observed one look identical, and the reconstruction overstates itself.
Source evidence behind every relationship	The record or records that justify each edge. A graph edge with no source is an assertion.
Crown-jewel proximity	How close the adversary came, on which path. Turns a timeline into a risk statement.
Missing evidence and blind periods	Where the record is silent and why — a source not onboarded, a known-gap period from `DC.2`, a retention limit. Silence marked is a finding; silence unmarked is a false negative waiting to be reported as a clean bill.
False-grouping review	Alerts that were assembled into an incident and did not belong. Measures over-correlation.
Missed-grouping review	Alerts that belonged to an incident and were left out. Measures under-correlation, and is only findable by looking.
Analyst corrections	What the human changed in the automated assembly, recorded as data. The best available measure of correlation quality, and the training set for improving it.
Investigation and containment decisions	What was decided, on what evidence, at what point in the timeline. The record TIR-CMM reads when it asks whether the decision was made inside the breakout window.

Two telemetry defects corrupt a timeline silently. A known-gap period — a source that stopped reporting for six hours, a pipeline that dropped events above a volume threshold — produces a timeline with a hole in it that reads as “nothing happened”. DC.2 at level 4 records those periods so a reconstruction can mark them as blind rather than quiet. Clock skew produces a timeline in the wrong order: a credential dump timestamped before the logon that enabled it, because two sources disagree by ninety seconds. DC.2 scores time-source accuracy, and DC.3 scores whether the timestamps are normalised to one base. A correlation capability that does not know its own clock quality reports its ordering with unearned confidence.

What this page does not claim

None of the above is performed by the assessment tool, and none of it should be read as a product requirement. The tool derives a technique scope, computes telemetry reach, scores eight domains and writes an export. It does not ingest alerts, correlate events, reconstruct incidents or predict adversary activity. AA.2 level 5 may be implemented through different technology architectures; the evidence requirement is the same whichever is chosen: a reconstructed path against the estate’s real topology, with source evidence and confidence recorded for every relationship, that an assessor can open.

Known-Threat Assurance and Unknown-Threat Readiness · Prevention, protection and the TIR-CMM boundary · What counts as evidence · The 58 sub-capabilities