Step 8 — scenarios and timelines
Multi-step attacks toward a crown jewel, assessed step by step: where the chain is visible, where it fires, where it is proven, and where it breaks.
What this step establishes
A technique detection that does not contribute to narrating a full attack scenario is telemetry, not defence. This step records the scenarios you have modelled or tested — an attack tree or emulation chain to a named crown-jewel objective — and reads each one the way the Scenario Coverage Score already defines. The assessment evaluates whether the capability exists. It does not correlate live events, reconstruct incidents or predict activity.
What a scenario records
A scenario identifier and name; the objective; the crown jewel or critical service it reaches; the actor or threat hypothesis; the ordered ATT&CK techniques with a stage for each; the identities, hosts, cloud resources, applications and networks involved at each step; the expected or tested time window; for every step, its visibility, detection and validation status and its correlation keys; whether each step’s detection can be joined to the previous one, with evidence; the test date and method; the named artefacts; and the result, exceptions and investigation notes. Templates are offered from the asset types you declared on the crown-jewel step; every step in a template is meant to be edited.
Three states that are never confused
| State | Meaning | How it is shown |
|---|---|---|
| Observed | Directly supported by telemetry you collect. | Filled marker and the word. If the technique’s required sources reach 0% of the estate the tool says so beside it, because a step cannot be observed on telemetry that does not exist. |
| Inferred | Supported by correlation and surrounding evidence. | Half marker and the word. Counts toward reconstruction, never as an observed fact. |
| Hypothesised | Possible or expected, but not observed. | Empty marker and the word. A blind step in the timeline. |
A predicted or inferred step is never presented as an observed fact: the timeline carries the state in a shape and a word, with colour secondary.
Detection, validation and joins
- Detected is read from the detection register (status 2 or 3) unless you record it on the step. A “Detected” you select counts towards coverage only with an evidence basis: register status 2 or 3 for the technique, or a complete scenario-test record (date, qualifying method, named artefact) in which that step fired. Without either it is shown as claimed detected — evidence not supplied, stays recorded, and never enters the coverage count. A step whose technique has no register answer and no step answer is not assessed.
- Validated needs either register status 3 for the technique, or a scenario test inside the recency window by a qualifying controlled adversarial method (atomic test, adversary emulation, purple-team exercise, breach and attack simulation, red-team exercise, or an evidenced penetration test) with a named artefact and an outcome of fired for that step. A test outside the window shows as expired; a production true positive or an unreviewed “other” method does not validate.
- Joined means the step shares at least one correlation key with the previous step — identity, host, process, session, cloud principal, IP or connection, workload, application trace, API request, or transaction identifier — and you have recorded evidence that the two detections can be assembled. Anything else is a broken transition.
What the timeline shows
Visible and blind steps; detected and undetected steps; validated detections; broken transitions; the earliest detectable stage; steps with no correlation key; whether the chain can be reconstructed in order; and the next evidence-based improvement, chosen in a fixed order — missing telemetry first, then unassessed steps, then undetected steps, then validation, then a second detected stage, then keys and joins, then expired validations.
Covered means the existing rule, applied as written. A scenario is covered only when it is detected with evidence at two or more distinct stages and at least one of those detections is locally validated by a qualifying method. One register-validated stage plus one claimed-but-unevidenced stage is not covered; two evidenced stages with one qualifying validation is. Covered, partially evidenced, not covered and not assessed are counted; the Scenario Coverage Score is reported only when the register has at least one scenario and every scenario has an assessed step. No scenario result is averaged into the maturity score, and no second maturity score is made from them.
What it feeds
The scenario status counts in Assurance at a glance, the broken-transition count in the bottlenecks view, and the TIR-CMM export, where each registered scenario travels as an attack path (SC-n) with its stages, techniques, the asset classes of its crown jewel and a note stating its status under the rule above.