Leaf Actions and Depth

## What a leaf is, and why the wording matters An attack tree starts from one thing the attacker wants — the root goal — and refines it downward into sub-goals and then into the actions someone actually performs. The nodes with no children are the **leaves**. They are the only part of the artifact a defender can price, schedule, assign or mitigate. Every node above a leaf is effectively a heading. That is why leaf wording is not cosmetic: a tree of vague leaves is a diagram that looks like analysis and produces no work. Two shapes show up constantly in review. - A **category leaf** is a node that stopped at heading level: *obtain another user's cabinet credential*, *compromise the meter*, *bypass authentication*. It reads like a threat, so it feels finished, but it names a **class** of actions rather than an action. - A **concrete-action leaf** names one specific thing done against this particular design: *use the override code taped inside the cupboard door*, *dispense against a discharged patient's open order during handover*, *replay a captured reading frame from the parking lot*. ## The granularity test One question decides it: **could a competent engineer cost this line and act on it?** - *Cost it* — could someone argue about the access, skill and time the action needs? People may disagree on the number; the point is that the line must be arguable at all. *Obtain a credential* is not arguable, because it does not say which credential, held by whom, reachable from where. - *Act on it* — does a named control follow without another design discussion? A concrete leaf hands you one. *Improve credential security* is a programme, not a control, which is the tell that the node above it was never decomposed. ## Worked example: a pharmacy back-room dispensing cabinet Root goal: *dispense a controlled substance without a valid, attributable order*. The adversary is a shift technician with legitimate floor access — not an outsider — and the assets are regulated inventory and patient safety. ``` OR act at the cabinet as someone else - obtain another user's cabinet credential <- category leaf: stops here, buys nothing ``` Pushed one level, the same branch becomes: ``` OR act at the cabinet as someone else - use the override code taped inside the cupboard door - watch a colleague's PIN entry at the keypad during shift change - use a badge left in the shared workstation reader in the break room ``` Three leaves, three different mechanisms, three different controls with three different owners: retire and alarm the printed override; shield the keypad and shorten the credential's reuse window; auto-lock the workstation and stop badges resting in readers. The single category leaf above would have produced one vague action item and quietly hidden two of the three paths — which is the real damage a category leaf does. It does not merely under-specify; it makes an unexamined branch look examined. The same effect shows on a municipal smart-meter reading network. *Exploit the meter firmware* is a heading: which interface, reachable from where, and what does the attacker end up holding? Its concrete children are separable and sit at different attacker positions — replaying a captured reading frame from the parking lot needs radio range and no credential at all, while flashing a modified image needs physical possession of a unit. Those are not the same threat and they are not defended the same way. ## The opposite failure: decomposing past the point of decision Granularity has a floor as well as a ceiling. *Walk to the cabinet*, *stand at the keypad*, *press the first digit* are not leaves, they are choreography. The rule that catches both errors at once: > Keep decomposing while the children differ in **how you would stop them**. Stop when they do not. If every child of a node resolves to the same single control and the same owner, the split changes no decision and the parent should have been the leaf. This also keeps the tree readable, which matters because a tree nobody finishes reading defends nothing. ## Reading a branch of pure category leaves When a whole branch is category leaves, the usual cause is not that the branch is finished — it is that the team has run out of knowledge about the design. Treat it that way: record it as an open question or assumption against that node rather than as a completed branch, and give it back to whoever knows the component. A branch that is honestly marked *not yet understood* is far safer than one that is silently marked *done*. Finally, leaves are the interface to everything downstream in the artifact — annotation, prioritisation, control mapping, review. All of that inherits the leaf's precision, so a sloppy leaf is not a local defect; it degrades every use the tree is later put to.