Run a retrospective that reaches a design
Task
Apply objective 4.4: take one incident -- real, or one you stage in the lab -- and produce a root cause that names a control or a design, plus the specific review of your own exclusions.
Steps
- Write
lab/incident.mdwith the timeline, using the evidence discipline from the previous lab. - Run the analysis in
lab/root-cause.md, asking why at each level until you reach something that can be CHANGED. A root cause naming a person is a last link, not a root cause. - Answer both closing questions explicitly: what detected it and what SHOULD have; and which of your exclusions or suppressions covered any part of the attack path. Check
lab/exclusions.csvrow by row. - Write
lab/incident-actions.csvasaction,owner,due,artefact_updatedwith at least five actions, each naming which governance artefact it changes. - Actually make the updates: the risk register, a standard, the threat model, the coverage map, the CMDB, the RACI. Record which files changed.
Verify
grep -Eci 'why' lab/root-cause.md
grep -Eci 'should have detected|detection gap' lab/root-cause.md
grep -Eci 'exclusion|suppression' lab/root-cause.md
awk -F, 'NR>1 {n++} END {print n" action(s)"}' lab/incident-actions.csv
awk -F, 'NR>1 && $4=="" {n++} END {print n+0" action(s) changing no artefact"}' lab/incident-actions.csv
A root cause reached through several levels, both closing questions answered, five or more actions, and ZERO actions that change no artefact. An action that updates nothing is a recommendation, and recommendations are where most of this effort is lost.
This is an independent study companion for CompTIA SecurityX CAS-005 and is not produced by or endorsed by CompTIA.