Threat-Model a Feature with STRIDE and Attack Trees Using AI

An LLM is a strong brainstorming partner for exactly this: it can enumerate STRIDE threats across a data-flow diagram far faster than you can, propose attack trees, and — critically — run a completeness pass that hunts for the threats your first draft missed. Your job shifts from generating threats to judging them: pruning the implausible, catching what the model overlooked, and turning the survivors into mitigations you will actually build.

When to reach for this

• •
  A new feature or architecture is entering design and you want a threat model before code exists.
• •
  An existing system is getting a significant change (new trust boundary, new external integration, a new AI feature) and the old model no longer fits.
• •
  You need a repeatable, defensible artifact — threat list plus mitigations — for a design review or an audit.

Skip the full ritual for a change with no new trust boundary and no new data flow; the value is proportional to how much the attack surface moved.

The workflow

1. 1.

   Describe the system as a data-flow, not prose. List external entities, processes, data stores, and every trust boundary crossed. Precision here determines the quality of everything downstream.

2. 2.

   Prompt for a STRIDE enumeration per element. Force structure:

   Copy

   You are a threat-modeling assistant. Here is a data-flow description of
   a feature I am designing (my own system). Enumerate threats using STRIDE.
   
   For EACH element and EACH data flow that crosses a trust boundary,
   list threats under all six STRIDE categories that apply. For each threat:
   - the STRIDE category
   - the element/flow it targets
   - a concrete attacker scenario (one sentence)
   - the security property it violates
   Do not skip a category just because it seems unlikely — say "none
   credible" explicitly if so, so I can see you considered it.
   
   SYSTEM:
   - External entity: unauthenticated web client
   - Process: /api/export handler
   - Data store: Postgres (customer records)
   - Trust boundary: internet -> app; app -> database
   

   Expected output: a threat table where every trust-boundary crossing has been examined under all six categories, with explicit "none credible" entries rather than silent gaps.

3. 3.

   Build attack trees for the top threats. For the two or three highest-impact threats, ask for an attack tree — root goal, branching sub-goals, leaf techniques — so you can see the paths and pick where a single control cuts the most branches.

   Copy

   Build an attack tree for: "attacker exfiltrates customer records via
   /api/export". Root = the goal; branches = distinct paths; leaves =
   concrete techniques. Mark which leaves a single control would block.
   

4. 4.

   Run a completeness pass — the step that catches what you missed. Start a fresh angle:

   Copy

   Here is my current threat list. Act as a skeptical reviewer: what threats
   are MISSING? Specifically check for trust boundaries I did not list,
   assumptions I am relying on that could be false, and threats that emerge
   from combinations of elements rather than any single one.
   

5. 5.

   Turn survivors into a mitigations table. For each retained threat: mitigation, owner, and whether it is designed-in, needs a control, or is an accepted risk. This is the artifact you carry into review.

Verify before you trust it

• Confirm each threat is real for your architecture, not generic. Models emit boilerplate ("DoS via resource exhaustion") that may not apply. Tie every retained threat to a specific element and a plausible attacker who can reach it.
• Confirm the completeness pass actually added value. Re-run it from a second angle (e.g., "assume the attacker is an authenticated low-privilege user") — if it surfaces nothing new across angles, you have reasonable coverage; if each angle finds more, keep going.
• Prove a mitigation addresses the threat. For each mapping, state the exploit path the control breaks. A mitigation you can't tie to a specific attack path is decoration.
• Check for empty STRIDE categories. If Elevation of Privilege is blank across the whole model, that's a smell — either genuinely N/A (state why) or a gap the model glossed.

Pitfalls

• Garbage in. A vague system description yields a generic threat list. Invest in the data-flow diagram first.
• Treating the list as complete. The first pass is a starting point; the completeness/skeptic passes are where real coverage comes from.
• Threat theater. A long list nobody prioritizes or mitigates is worse than a short one you act on. Prune hard.
• Missing emergent threats. STRIDE is per-element; some attacks live in the interaction between elements. The completeness prompt is specifically there to catch these — don't skip it.
• Over-trusting severity. Let impact and reachability, not the model's adjectives, drive which threats get mitigations now.

Tools

• An LLM (Claude-class)the enumeration and completeness-check engine; the core of this workflow.
• OWASP Threat Dragonfree, open threat-modeling tool for drawing the data-flow diagram and recording threats/mitigations in a shareable artifact.
• MITRE ATT&CKa technique catalog to ground attack-tree leaves in real adversary behavior rather than invented ones.

Client-safe variant

Threat models describe architecture, which is often client-sensitive. Before prompting, abstract the design: replace product names, real hostnames, and proprietary logic with generic roles ("payment processor", "customer data store") and keep only the structure the threat model needs — entities, boundaries, data flows. That abstraction usually loses nothing for STRIDE, which cares about shapes not names. Where a client prohibits external tools, run a local model for enumeration and keep the artifact in the client's own Threat Dragon instance. Confirm tool approval before the first prompt and never paste real credentials, endpoints, or customer data into the model.