The Attack-Defense Tree (ADTree) Notation

Why Use Attack-Defense Trees (ADTrees)?

Attack-Defence Trees (ADTrees) model security scenarios as a two-player game: an attacker trying to compromise a system and a defender trying to protect it, with their strategies and countermeasures interacting at every level of the tree.

Classic attack trees, popularised by Bruce Schneier in 1999, model attack scenarios as tree-like structures where the root represents an attacker's goal and the leaves are the individual actions to achieve it. However, attack trees cannot capture the interplay between attacks and defenses. ADTrees overcome this limitation by introducing defense nodes as countermeasures to attacks, allowing you to model the arms race between attacker and defender in a single diagram.

ADTrees have two key structural features:

• Refinements: Every node may have one or more children of the same type representing sub-goals. Refinement is either disjunctive (any one child suffices) or conjunctive (all children are required, modelled using an And Junctor).
• Countermeasures: Every node may also have one child of the opposite type. An attack node can have a defense child representing a countermeasure, and vice versa. This alternation between attack and defense can continue to any depth.

The root of an ADTree determines whether the proponent is the attacker or the defender. When the root is a defense node, the overall goal is to protect the system, and attacks appear as threats to be countered. When the root is an attack node, the goal is to compromise the system, and defenses appear as obstacles.

When to Use ADTrees

Use ADTrees when you need to model the back-and-forth between attacker and defender. That's their defining advantage over plain attack trees or risk matrices. Specifically, ADTrees shine when:

• You're assessing the security of a system and want to evaluate defences alongside threats. Rather than listing attacks in one document and defences in another, ADTrees show the countermeasure relationship directly — "this defence counters that attack, but this attack can circumvent that defence."
• You need to communicate security trade-offs to stakeholders. The visual red/green attack/defence distinction makes it immediately readable for non-technical audiences. A CTO can look at an ADTree and see where defences are thin.
• You're doing threat modelling during design. Before building a system, you can map out anticipated attacks, plan defences, and then stress-test those defences by asking "how could an attacker get around this?" — the tree naturally supports this recursive thinking.
• Your security scenario has depth. ADTrees handle arbitrary nesting: an attack can be countered by a defence, which can be circumvented by another attack, which can be countered by yet another defence. If your scenario has this layered quality, ADTrees capture it naturally.

When NOT to Use ADTrees

• If you only care about attacks (no defences), a plain attack tree suffices.
• If you're doing root cause analysis of operational problems, use a CRT instead.
• If you need to model temporal sequences (attack step 1, then step 2), ADTrees are not ideal — they model goal decomposition, not workflows.

ADTree Notation Description

ADTrees use two primary node types — Attack and Defense — plus an And Junctor for conjunctive refinement. Edges between nodes of the same type represent refinement (breaking a goal into sub-goals), while edges between nodes of opposite types represent countermeasures.

The Node Types in detail:

The edges in an ADTree carry two distinct meanings depending on the types they connect:

• Same-type edges (Attack to Attack, or Defense to Defense): Represent refinement of a goal into sub-goals.
• Cross-type edges (Defense to Attack, or Attack to Defense): Represent countermeasures — the child node counters the parent.

Background Information

Attack-Defense Trees were formalised by Barbara Kordy, Sjouke Mauw, Saša Radomirović, and Patrick Schweitzer in their paper "Attack-defense trees" published in the Journal of Logic and Computation (2014, DOI: 10.1093/logcom/exs029). The paper is also available on ResearchGate.

ADTrees build on Bruce Schneier's original attack trees (1999), which provided a systematic way to evaluate the security of complex systems. By adding defense nodes, ADTrees generalise and unify existing approaches to extending attack trees, making them a more complete tool for security analysis.

Try ADTree Yourself

Create and visualise your own Attack-Defense Tree diagram right here in your browser. Edit the VGL (Vithanco Graph Language) text on the left and click "Render" to see your diagram:

Tip: Use Ctrl+Enter (or Cmd+Enter on Mac) to quickly render your graph while editing.

Want to learn more about the VGL syntax? Check out the complete VGL Guide for detailed documentation on creating graphs in text format, including syntax reference and examples for all supported notations.

Example

This example models data confidentiality in a hosting centre, based on the paper by Kordy et al. The root is a Defense node ("Data Confidentiality"), so the diagram tells the story from the defender's perspective.

An ADTree for protecting data confidentiality (from Kordy et al., 2014)

Reading from the top: Data Confidentiality requires both Network Security and Physical Security (linked through an And Junctor). Each defense is then challenged by attacks — for example, Passwords can be attacked via Dictionary Attack, which is countered by the defense Strong Passwords, which in turn faces its own attacks (Find Note, Same Password Different Account). Follow any branch downward and you'll see this recurring pattern of defense, counter-attack, and counter-defense — exactly the layered arms race that ADTrees are designed to capture.