Objective 3.1 · Lesson 2 of 2

Build a map that leads to useful action

A useful framework map ends with a decision or a collection task. This lesson turns a handful of uncertain observations into a clear investigation plan and a realistic detection improvement.

Create an evidence ledger first

Before assigning framework labels, write one short statement per observation. Include the source, event time and time zone, affected identity or asset, and the limitation of the record. A process-start log can show that a command was launched; it may not show whether the command succeeded. Keeping those distinctions visible makes your map reviewable and prevents a later summary from overstating the evidence.

Place interpretations beside the facts rather than inside them. For example, an unexpected archive file might support a staging hypothesis, while a scheduled export could explain it legitimately. List at least one plausible alternative and the evidence needed to distinguish it. This is especially valuable when multiple tools repeat the same original alert, because repeated presentation is not independent corroboration.

Map only the supported behaviour

Choose the framework view after deciding what the ledger establishes. Use ATT&CK when the team needs a shared behavioural description, the Diamond Model when relationships suggest another affected entity, and the Kill Chain when discussing interruption opportunities. You can use all three, but keep their meanings distinct. A stage, a technique, and an infrastructure address are different kinds of information.

Add confidence to individual claims rather than assigning one confidence score to the entire case. You may be highly confident that an account created a task but uncertain that the account holder authorised it. Preserve that uncertainty when describing intent. Where the mapping depends on a missing command line or cloud audit record, make obtaining that evidence an explicit task with an owner.

Turn gaps into measurable improvements

A map can reveal a visibility gap, a detection gap, or a response gap. Missing logs are a visibility issue. Available logs with no useful alert suggest a detection issue. A good alert with no accountable response points to a process issue. These problems need different fixes; adding another detection rule will not help if the relevant events never reach the monitoring system.

Validate improvements using approved synthetic activity or a controlled exercise. Define the expected record, alert, analyst interpretation, and response decision before the exercise starts. Evaluate whether the evidence supports the intended mapping and whether benign administrative activity creates noise. A coloured coverage matrix becomes meaningful only when its entries represent tested capabilities with known limits, rather than a collection of technique names.

Keep these points in mind

  • Preserve observations, interpretations, alternatives, and evidence gaps as separate items.
  • Identify whether a gap concerns visibility, detection, or response.
  • Treat framework coverage as something to validate with an exercise.

Pause and practise

An incident map marks command execution as fully covered because one rule exists. During an exercise, the endpoint event appears locally but never arrives in the SIEM. What should the improvement ticket say?

Show a worked response

Record a collection or ingestion failure, not a missing technique label. Assign an owner to trace the event through endpoint configuration, forwarding, parsing, and access controls. Repeat the approved exercise and require both the original event and an actionable analyst alert before declaring the coverage restored.

← Previous lesson