Construct Attack Trees for Security Analysis

Attack Tree Construction is a skill for building attack trees that visualize threat paths: systematic attack path visualization and analysis. It is meant for mapping attack scenarios, identifying defense gaps and communicating security risks to stakeholders. The skill is marked for authorized use only: educational purposes, defensive validation, controlled lab environments or authorized security assessments, with explicit written permission from the system owner.

The method has four steps. Confirm scope, assets and the attacker goal for the root node. Decompose that goal into sub-goals with an AND/OR structure. Annotate the leaves with cost, skill, time and detectability. Map mitigations per branch and prioritize the high-impact paths.

The playbook explains the structure of a tree: a root goal, sub-goals that are either OR nodes (any child achieves the goal) or AND nodes (all children are required), and leaves that are atomic attack steps. Each attack is described by four attributes: cost (from $ to $$$), time (hours, days or weeks), skill (low, medium or high) and detection (low, medium or high likelihood of detection).

Four Python templates implement the approach:

1. A data model with node types (OR, AND, leaf), enumerations for difficulty, cost and detection risk, and an AttackTree class that can find the easiest, cheapest and stealthiest paths, list leaf attacks and unmitigated attacks, and export JSON.
2. A fluent AttackTreeBuilder with goal, or_node, and_node, attack and end methods, shown on an account takeover example whose leaves carry mitigations such as security awareness training, email filtering, rate limiting, MFA and password breach monitoring.
3. Exporters that render a tree as a Mermaid diagram or a PlantUML diagram.
4. An AttackPathAnalyzer that enumerates all paths, calculates path metrics, identifies the critical nodes that appear in the most paths, runs a coverage analysis of how much a set of mitigations blocks, and ranks mitigations by the share of paths each one blocks.

The example account takeover tree has the root goal of taking over a user account, with three OR branches. Stealing credentials covers phishing, credential stuffing and keylogger malware. Bypassing authentication covers session hijacking and an authentication bypass vulnerability. Social engineering is an AND node for an account recovery attack, which needs both gathering personal information and calling the support desk. Each leaf carries mitigations, for example security awareness training and email filtering for phishing, rate limiting, MFA and password breach monitoring for credential stuffing, secure session management and HTTPS only for session hijacking, security testing, code review and a WAF for the bypass vulnerability, and support verification procedures for the support desk call. The model rates difficulty from trivial to expert, cost from free to very high, and detection risk from none to certain, and it flags attacks that require an insider or physical access.

Attack attributes in the data model look like this:

@dataclass
class AttackAttributes:
    difficulty: Difficulty = Difficulty.MEDIUM
    cost: Cost = Cost.MEDIUM
    detection_risk: DetectionRisk = DetectionRisk.MEDIUM
    time_hours: float = 8.0
    requires_insider: bool = False
    requires_physical: bool = False

Use it when visualizing complex attack scenarios, identifying defense gaps and priorities, communicating risks to stakeholders, or planning defensive investments or test scopes.

Do not use it when you lack authorization or a defined scope to model the system, when the task is a general risk review without attack-path modeling, or when the request is unrelated to security assessment or design. Before running any command that probes, exploits, changes, persists on, extracts data from or attempts credential access against a target, the skill requires a confirmation gate: ask for the exact target, ask for confirmation of written authorization and scope, show the exact commands and their expected effect, and wait for explicit confirmation. Without that confirmation it remains read-only and provides defensive guidance only, preferring a sandbox, disposable VM or controlled lab. Share attack trees only with authorized stakeholders and avoid sensitive exploit details unless required.

The playbook's guidance is to start with clear goals, be exhaustive, attribute every attack, update regularly and validate with experts through red team review. It warns against oversimplifying, ignoring dependencies (AND nodes matter), forgetting insider threats, skipping mitigations, and treating the tree as static.

The input is the system or scenario to model, its assets, and the attacker goal for the root node. The output is an attack tree with annotated leaves and mitigations per branch, optionally exported as JSON or as a diagram, plus path analysis that shows critical nodes, coverage and prioritized mitigations.

The playbook points to Bruce Schneier's attack trees paper, the MITRE ATT&CK framework and the OWASP Attack Surface Analysis cheat sheet as references.

Security engineers, architects and assessors who need to communicate threat paths and defense priorities to stakeholders, and who have authorization and a defined scope to model the system.