Someone opens an attack tree with the root 'stored XSS in the profile page' - what is wrong with it?
answer
- the attacker's objective, not the flaw
- threat versus vulnerability
- ask: so what does that get them?
- the finding becomes a branch, not the root
- too broad is malformed too
basics
~20 sThat root names a vulnerability, not an attacker objective. An attack tree's root must state what the attacker wants to achieve - post as a moderator to the whole membership - leaving the flaw as one branch beneath it.
solid answer
~50 sA root goal is a threat - something the attacker wants - while `stored XSS in the profile page` is a vulnerability, the flaw that might enable it. Rooting the tree at the flaw pre-commits you to one technique and hides every other route to the same outcome. On a fan-community forum, ladder it upward by asking "so what does that get the attacker?" until you reach something a stakeholder would recognise as bad: `post as a moderator to the whole membership`. Now the tree can show the alternatives beside the flaw - steal a live moderator session, get a real moderator to run something, abuse a self-service role change - and the original finding sits as one branch. Watch the other direction too: a root like `compromise the forum` is unbounded and gives you a tree nobody can finish or compare.
go deeper
Be able to say a root goal is what the attacker wants to achieve, not the bug that lets them, and to restate one bad root out loud as an objective.
Explain the cost of the mistake: a tree rooted at a flaw enumerates one technique instead of the alternative routes to the same outcome, and it dies the week the flaw is patched.
Show the laddering method under pressure and know when to stop. Expect to be handed a bad root on a whiteboard and asked to fix it, then to sketch the first OR level beneath the corrected root.
Own the choice of which objectives get trees at all. A system supports several roots; deciding which assets justify the modelling effort, and refusing over-broad roots that produce unfinishable trees, is the lead's call.
## Threat, vulnerability, risk, control Four words that a weak answer blurs and this question exists to separate: - **Threat** — what could go wrong, stated as something an adversary achieves. *Post as a moderator to the whole membership.* - **Vulnerability** — the specific flaw that lets it happen. *A profile field that is stored and rendered without escaping.* - **Risk** — the rated consequence: how bad, how likely, worth what. - **Control** — what you do about it. An attack tree's root must be a **threat**. `Stored XSS in the profile page` is a vulnerability, so the tree is malformed before a single branch is drawn. ## Why the malformed root actually hurts 1. **It hides alternatives.** The whole value of the tree is that it enumerates *routes to one outcome*. If the root is the route, there is nothing left to enumerate — you get a decomposition of one bug rather than a map of how the outcome can be reached. The alternatives the fixed root exposes (a stolen moderator session, a moderator persuaded to act, a self-service role change that is not checked) are precisely what you miss. 2. **It cannot be prioritised.** A root goal names an asset and a consequence, which is what lets somebody decide whether this tree is worth building at all. A flaw name carries neither. 3. **It biases the defence.** Fix the flaw and the tree is "done", even though the objective is still reachable three other ways. 4. **It ages badly.** Flaws are patched; objectives persist. A tree rooted at an objective stays useful across releases and is worth re-visiting; a tree rooted at a bug is scrap the week the bug is fixed. ## Laddering upward The repair is mechanical. Ask "**so what does that get the attacker?**" and take the answer as the new root; repeat until the answer stops being a technical capability and starts being an outcome someone in the organisation would call bad. ``` stored XSS in the profile page -> so what? run script in another member's browser session -> so what? act with that member's privileges -> so what? POST AS A MODERATOR TO THE WHOLE MEMBERSHIP <- root goal ``` Stop at the level where the impact is something the owning team already cares about protecting. Going one rung too far — `damage the community's reputation` — produces a root so abstract that everything in the system hangs beneath it. ## What a well-formed root looks like - Written **in the attacker's voice** as an objective: *divert a scheduled payout to an account I control*, *change a posted final grade so no one notices*, *travel without a valid fare being recorded*. - **One** objective, not a bundle joined by "and". - Names or clearly implies the **asset or consequence** at stake — money, record integrity, availability, privacy, audit truth. - **Technique-free.** It says what, never how; every how belongs to a branch. - Bounded to a system you can actually decompose. ## The four malformed roots you will be shown | malformed root | what it really is | fix | |---|---|---| | `stored XSS in the profile page` | a vulnerability | ladder up to the objective it serves | | `defeat the login rate limiter` | a control bypass, i.e. a step | make it a sub-goal under the objective it unlocks | | `ensure profile input is escaped` | a defensive requirement | invert: what does the attacker want that escaping prevents? | | `compromise the forum` | too broad, no asset | split into several rooted trees, one objective each | That last row is worth as much as the first. An over-broad root is malformed for the mirror-image reason: with no asset and no boundary, the branches are not comparable to one another, no level can be argued exhaustive, and the tree never terminates. One tree per objective, several trees per system, is the normal shape. ## Where the finding goes Nothing is lost by re-rooting. The original XSS finding reappears as a branch under a sub-goal like *run code in a moderator's browser session*, now sitting beside its siblings so you can compare what each costs the attacker — which is exactly the comparison the malformed tree could not support.
- How do you know you have laddered up far enough, and not too far?Stop at the first rung that a stakeholder would recognise as a bad outcome for a named asset - money moved, a record falsified, a service down, an identity impersonated. One rung further usually gives you something like `harm the brand`, which has no boundary: every threat in the system hangs under it, no level can be argued complete, and the tree never terminates.
- What is wrong with the root 'compromise the forum'?It names no asset and no objective, so it is unbounded. Branches under it are not comparable - defacing a page and stealing member emails end up as siblings - and no OR level can be argued anywhere near exhaustive. Split it into several trees, each rooted at one concrete objective, and build the one whose asset you most care about.
- Once the root is restated, where does the original XSS finding live?As a branch under whichever sub-goal it serves - typically `run code in a moderator's browser session` - alongside the other ways to reach that same sub-goal. That placement is the payoff: you can now compare what each route costs the attacker and see that fixing the one finding leaves the objective reachable by its siblings.
saying these in an interview costs you the question
- Roots the tree at a specific finding or scanner output
- States the root as a defensive requirement rather than an attack
- Uses a technique name as the objective
- Picks a root so broad every threat hangs beneath it
- Cannot separate the flaw from what the attacker gains by it