After a control kills an attack tree's cheapest branch, why might the root cost barely rise?

## Displacement is a property of the OR node An attack tree's root value is the minimum over the alternative paths beneath it. When a control makes one path infeasible, that path drops out of the minimisation and the next-smallest value takes its place. The improvement you bought is exactly the **gap between the branch you removed and the runner-up** — never the removed branch's whole value, and never a general reduction in risk. That arithmetic is why an attack tree is worth drawing at all. Without it, a control that demonstrably defeats a real attack technique reads as a fix. With it, the same control reads as a small number, and the interesting question becomes *where does the attacker go now*. ## Worked example: keyless unlock A car-sharing operator models *unlock a vehicle you have not rented*. Assets are the vehicles themselves and the availability of the fleet. ``` GOAL unlock a vehicle without a rental [OR -> minimum] | +-- A. relay the key credential from range = 4 +-- B. get the support console to remote-unlock = 5 +-- C. physically defeat the door and immobiliser = 12 Root = min(4, 5, 12) = 4 ``` Add a distance-bounding handshake so a relayed credential fails the round-trip timing. Branch A goes to infeasible. Re-propagate: the root is now 5. The proposal that removed an entire attack class bought **one unit**, and the cheapest attack is now a social-engineering call or a compromised support operator. Notice what changed alongside the number. The adversary moved from a **local attacker within radio range of a parked car** to a **compromised or manipulated operator with legitimate console access**. That is a different threat actor, a different control family, a different detection strategy and, usually, a different owning team. Reporting only the cost delta hides the more consequential half of the result. ## Displacement can still be a win A flat or nearly flat root value does not automatically mean wasted effort. Ask three further questions before you judge the control: - **Did the attacker population shrink?** Anyone with a radio kit could attempt the relay branch. Far fewer people can drive the support console, and every one of them is identifiable. - **Did detectability improve?** A relayed unlock leaves nothing behind. A console-issued unlock leaves an operator identity, a session and a ticket — evidence that supports both detection and non-repudiation. - **Did the blast radius change?** A branch that scales to a whole fleet is worse than one that unlocks one car per phone call, even at the same cost. If your annotations carry more than cost — skill, time, required access, detectability — displacement often shows up as a large improvement in a column other than money. Say so explicitly, rather than quietly hiding a zero cost delta behind a strong-sounding control name. ## Predicting displacement before you build You do not have to ship a control to find out where the attacker moves. Set the target branch to infeasible on paper and re-read the minimum: **the second-cheapest path is your displacement target**, and it was in the model all along. That turns the mitigation decision from "is this control good" into "which pair of controls raises the root", because covering the top two branches together is frequently the only combination that moves the number at all. A second, quieter use: displacement pressure exposes an incomplete tree. A research institute protecting a genome dataset added egress filtering, then per-record access logging, then an analysis clean room, and each time the cheapest path moved further toward a departing postdoc carrying data out on their own authorised laptop. The tree had that branch, but under-costed and unloved, because early modelling had focused on the anonymous outsider. Successive displacement is a reliable way of finding the branches your first pass treated as uninteresting — and, here, of noticing that the asset at risk was as much research IP and study-participant privacy as it was a network perimeter. ## What weak answers look like The common failure is to re-cost only the branch that changed, then present the control as closing the attack. The second is to treat the removed branch as evidence of progress — "we eliminated relay attacks" — with no statement of what the cheapest path now costs or who now has to run it. The third is to assume displacement is always bad; sometimes moving an attacker from an anonymous, unattributable path onto an authenticated, logged one is precisely the outcome you wanted, and you should be able to argue that with the same tree.