Be precise about both ends
Write down the starting actor’s real state: tenant, roles, network position and the identifiers or objects they can obtain. “Low privilege” hides too much. Do the same for the destination. Access to a host is different from the ability to approve a payment, change a trust policy or control a workload.
This removes paths that start from a privilege the test account never had or end at a machine that does not represent the business impact being discussed.
Turn an arrow into a sentence
For each important edge, write: “Actor A can use condition B to cross control C and obtain state D.” Add the knowledge, timing, trust, user action and configuration required. That sentence can be tested; “lateral movement” cannot.
Record how the starting actor gets each prerequisite. A secret entered by the tester can isolate an authorisation check, but it does not prove that an attacker can discover the secret. Keep that limitation attached to the edge and to any path that uses it.
- Reachable: the starting actor can obtain the prerequisite.
- Supplied for the test: it was provided to isolate another control.
- Unknown: acquisition has not been checked.
- Secret or capability: possession may itself be the security boundary.
Check edges before joining them
Establish the expected control, change the smallest relevant condition and verify the resulting state. Clean up before moving to the next edge. This keeps the failed boundary and its evidence easy to find.
A full chain may be justified when the order changes risk or tests interaction between controls. If so, carry the status of every prerequisite into the final claim. A path with a supplied secret is not an arbitrary-user path.
Count shared controls, not coloured lines
Graph tools may draw dozens of routes that all depend on one role assignment, trust policy or management interface. Treating them as separate problems inflates the count and hides the useful fix.
Group verified paths by their common control. Find the smallest practical change that closes the most important routes, then rerun the affected edges. The useful output is the change in reachability, not the size of the original diagram.
Sources
- Attack Flow projectCenter for Threat-Informed Defense
- Attack Flow specification and toolingCenter for Threat-Informed Defense on GitHub
- Adversary emulation and red teamingMITRE ATT&CK
The sources define or support the referenced methods. The examples and commentary are CYSTRIKE’s.