Two attack-tree branches reach the same HR records — one bulk export, one 400 single lookups. Which annotations separate them?

## The setup An HR case-management tool holds employee personal data — grievances, medical accommodations, salary history. The attacker position is not an outsider: it is a caseworker with a legitimate caseload and a genuine business reason to open records. The goal node is "obtain the personnel files of a large group of employees". Two child branches reach it: 1. **Bulk export** — use the reporting or export feature once, take a file of several hundred records. 2. **Slow accumulation** — open four hundred records one at a time across weeks or months, each one individually unremarkable. Both reach the goal. Annotating them is what makes the difference visible. ## Annotating both branches ``` GOAL: obtain personnel files of ~400 employees OR-- bulk export money: none skill: low equipment: none required access: caseworker role with export permission elapsed time: minutes detectability: high (single large export is a discrete, loggable event) OR-- 400 individual lookups money: none skill: low equipment: none required access: caseworker role, ordinary read elapsed time: weeks to months detectability: low (each lookup resembles normal casework) ``` Four attributes are identical or nearly so. The insider buys nothing, needs no expertise, and already holds the access — which is exactly why an outsider-shaped cost model would rate this whole subtree as trivially cheap and stop there. The information is entirely in the two attributes that differ. ## What the difference means **Elapsed time is the currency the slow branch spends.** It is not a cost in the ordinary sense; it is what the attacker gives up to buy stealth. Whether that trade is acceptable to the attacker depends on their own constraints — an employee who has already resigned has weeks, not months — which is why elapsed time on a node should be read against a window, not in isolation. **Detectability is what the slow branch buys.** Note carefully what the attribute records: not whether an event is logged, but whether it is *distinguishable* from legitimate activity. Four hundred lookups are all logged. Every one of them looks like work. A branch can be perfectly recorded and still have low detectability, and conflating logging with detection is the most common error in filling this column in. ## Detectability is a defender-side attribute This is the subtlety worth raising in an interview. Money, skill, equipment and required access are properties of the attacker and the world. Detectability is a property of **my** system: my logging, my retention, my thresholds, whether anyone reads the output. Three consequences follow: - The value is only valid for the current control set. It changes when logging changes, and it should carry a date or a reference to the control it assumes. - It cannot be estimated by the modelling session alone. Someone who knows what is actually monitored has to supply it, otherwise the column is aspiration. - Detectability changes only *whether you find out*; it does not change whether the attacker succeeds. The bulk-export branch with high detectability still hands over the data — detection buys response time, not prevention. Recording a branch as "high detectability" and treating it as mitigated is a real and frequent misreading. ## What the comparison is for The annotated pair immediately says something about controls. A volume threshold on exports raises the bulk branch's detectability further and does nothing to the slow branch — a rational insider simply takes the other route. Something that addresses the slow branch is different in kind: a per-user baseline over time, mandatory case linkage on each record open, or periodic review of access breadth rather than access volume. Whether that is worth building is a separate judgment; what the annotation gives you is the honest statement that the cheap control does not touch the branch a patient attacker would choose. ## Filling the column honestly Use a short scale — say negligible / low / moderate / high — with anchors that describe the defender's position: "would appear in an existing alert", "visible in logs if someone specifically looked", "indistinguishable from normal activity". Mark unknown where nobody in the room actually knows what is monitored, and treat that as a finding in its own right, since it is common for a system to be assumed instrumented in a way it is not.