You re-attach one 'obtain an operator credential' subtree to three internal consoles - how do you parameterise it per console?

## The scenario An insurer has three internal consoles - claims adjudication, payments, and underwriting. Each has its own attack tree, and each root goal needs the same sub-goal met first: *obtain a working operator credential*. The adversary is a compromised or coerced operator, or someone who can take over an operator's session; the assets are the credential itself and the personal claims data sitting behind each console. That sub-goal is a textbook library subtree - so it is decomposed once and re-attached under all three roots. The interview question is what happens *at* the attachment. ## What is shared and what is local Shared: the sub-goal statement, the branch structure, the concrete leaf actions, and the AND/OR operators. Local, set per attachment: - **Applicability.** Prune branches this console does not offer. If underwriting has no self-service password reset, the branch that abuses reset flow comes out of that attachment. Leaving it in with a bad score is worse than pruning: it keeps a path in the tree that does not exist. - **Leaf values.** Whatever metric the tree carries - attacker cost, skill required, elapsed time, detectability, or a plain feasible/infeasible flag - is scored for *this* console. Pick one primary metric and stay consistent; mixed metrics in one tree make propagation meaningless. - **Existing controls.** A control the console already has does not delete a leaf, it raises that leaf's cost or drops its feasibility. Step-up authentication on the payments console does not make session theft impossible; it makes the stolen session insufficient on its own, which either raises that leaf sharply or turns the branch into an AND with a second child. ## Re-propagating, and why the answer differs Once leaves are scored per console, values propagate upward by the node operator. On a cost-like metric: ``` OR node -> min(children) the attacker chooses the cheapest branch AND node -> sum(children) the attacker must complete all of them ``` On a boolean 'is this achievable', an OR node is achievable if any child is, an AND node only if all are. Either way the attacker owns the choice at an OR node and the defender owns it at an AND node - which is why AND nodes are where a single added control can cut a whole path. Now the payoff. Suppose the shared subtree has three OR branches: phish a live session, abuse the password-reset flow, and get credentials from a shared workstation. On claims adjudication - no step-up authentication - the session-theft branch is cheapest and the OR node inherits that value. On payments, step-up authentication makes session theft cost far more, so the OR minimum switches to a different branch, and the whole tree's cheapest path to the root changes with it. Same subtree, same shape, different answer. That is the entire argument for parameterising rather than sharing values: **a shared structure with per-consumer values tells you the three consoles are not equally exposed**. A shared structure with shared values tells you they are, which is false, and it will quietly flatten your remediation ordering. ## Recording the parameters so they survive An attachment is worth writing down as more than a pointer. Useful to record, per consumer: which branches were pruned and why, the metric in use, each leaf value with a one-line justification, and which values came from a control that already exists (those are the ones that go stale first when the control changes). Values that are pure guesses should be marked as such - most attack-tree scoring is ordinal judgment, not measurement, and a tree that hides which numbers were guessed invites arguments it cannot win. ## Where parameterisation runs out Parameterisation handles *different values over the same shape*. It cannot handle a consumer whose branches are genuinely different. If one console is reached only through a jump host on a segmented network, its credential sub-goal has branches the others do not have and lacks branches they do. Bending the shared subtree to cover it - adding branches only one consumer uses, or scoring irrelevant branches as infeasible - degrades the subtree for everyone. Fork it. The signal to watch for is an attachment that prunes or neutralises most of the shared branches: at that point the consumer is not really a consumer. ## The common interview mistakes Scoring the subtree centrally 'so the numbers are comparable' is the big one - it produces comparability by fiat, not by measurement. Deleting a branch because a control exists is the second: the control belongs in the leaf's value, and if you delete the branch you lose the record of what happens when that control fails or is removed. Third is scoring in a mix of dollars, hours and vague high/medium/low within one tree, which makes the propagated minimum and sum meaningless.