Threat Modeling Your Lab with OWASP Threat Dragon

Part of our free Tools & Targets series. Hands-on guides to the vulnerable practice apps and the security tools you will use on the job. Pair it with our Build Your Own Cyber Lab series for the lab to run them in.

1. Vulnerable practice apps: DVWA, bWAPP, Juice Shop, WebGoat, AI Goat and more
2. DVWA walkthrough: every module solved at Low, Medium and High
3. OWASP Juice Shop: beginner and intermediate challenges solved
4. WebGoat and bWAPP: key lessons solved
5. Threat modeling your lab with OWASP Threat Dragon (you are here)
6. Nessus Essentials: vulnerability scanning your lab
7. Snort and Suricata: network IDS and your first rules
8. Splunk in your lab: install, forward Windows logs, search with SPL
9. Wazuh deep dive: file integrity, vulnerability detection and custom rules

What Threat Dragon is (and is not)

Lists of "OWASP tools to practise with" often put Threat Dragon next to Juice Shop and WebGoat. It does not belong there. OWASP Threat Dragon is a threat-modeling tool, not a vulnerable application. There is nothing to hack. You use it to draw how a system works, ask "what could go wrong here?" for every part of the drawing, and record the threats and the mitigations you decide on.

That makes it the perfect companion to the vulnerable apps from parts 1 to 4. You have already attacked Juice Shop and DVWA; now you model them, predict the attacks before you run them, and check whether your model missed anything. Threat modeling is examined on CISSP, CSSLP and CCSP, appears in Security+ and CySA+ objectives, and is a standard interview question for application-security and architecture roles.

Desktop or web version?

Threat Dragon comes in two forms, and both are free:

For this guide, install the desktop app. Download the package for your OS from the releases page, verify it if a checksum is published, and install it like any other application. If you only want a quick look first, the demo site lets you open a local session and explore the bundled sample models without installing anything. Menu labels move between releases, so if a button below is named slightly differently, check the Threat Dragon documentation.

Step 1: Decide the scope

A threat model of "everything" never finishes. Pick one slice of your lab. A good first scope, using the lab from our Build Your Own Cyber Lab series:

• Kali (the attacker workstation) on the ATTACK network
• Juice Shop running in Docker on the Ubuntu server
• The Juice Shop database (it uses SQLite internally)
• The domain controller (DC01) on the CORP network, which authenticates lab users
• The firewall VM routing between ATTACK and CORP

Write the scope and your assumptions in the model's description field, for example "Lab only. Attacker has network access to ATTACK. No internet exposure."

Step 2: Create the model and a diagram

1. Open Threat Dragon and create a new, empty threat model. Give it a title ("Home lab - Juice Shop and AD") and an owner.
2. Add a diagram to the model. You will be asked for a diagram type: choose STRIDE. (Threat Dragon also supports LINDDUN for privacy, CIA, DIE and PLOT4ai for AI systems - worth revisiting later.)
3. Open the diagram to get the drawing canvas and the stencil of shapes.

Step 3: Draw the data-flow diagram

A data-flow diagram (DFD) has only five kinds of element. Learn them once and you can model anything.

Draw it in this order:

1. Drop an Actor called "Browser user" and another called "Attacker (Kali)".
2. Drop a Process called "Juice Shop web app" and a Store called "Juice Shop DB".
3. Connect them with data flows: Browser user to Juice Shop ("HTTP request"), Juice Shop back to Browser user ("HTTP response"), Juice Shop to DB ("SQL query"), DB to Juice Shop ("query results"). Flows are one-way, so draw both directions when data goes both ways.
4. Add a Process "AD authentication (DC01)" and a Store "NTDS.dit", with flows for "Kerberos/LDAP auth" from a Windows client actor.
5. Drag trust boundaries across every flow that crosses from one level of trust to another: the network edge between ATTACK and CORP, and the line between the Docker container and the host.

Select each element and fill in its properties panel. Mark flows as encrypted or not (Juice Shop over plain HTTP is not), mark the browser user as an external actor, and tick out of scope for anything you deliberately excluded, with a reason.

Step 4: Apply STRIDE to each element

STRIDE is a checklist of six threat categories. Not every category applies to every element type:

Select an element, open its threats, and add a threat for every category that fits. Each threat records a title, the STRIDE type, a status (open, mitigated or not applicable), a priority or score, a description and the mitigation. Recent versions can also suggest threats automatically from the element type; treat those as a starting list, not an answer.

Worked example: the Juice Shop web app (process)

Notice how many of these you already exploited in part 3. That is the point: a good threat model predicts the findings of a penetration test.

Worked example: the domain controller

• Spoofing: an attacker replays captured credentials (pass-the-hash). Mitigation: restrict NTLM, use tiered admin accounts, Credential Guard on clients.
• Tampering: malicious Group Policy changes. Mitigation: limit who can edit GPOs, alert on GPO modification events.
• Information disclosure: Kerberoasting reveals crackable service-account hashes. Mitigation: long random service-account passwords or managed service accounts, AES-only encryption types.
• Elevation of privilege: DCSync by an account with replication rights. Mitigation: audit replication permissions; alert on directory replication requests from non-DC hosts.

The data flows and stores

Do not skip the arrows. The unencrypted "HTTP request" flow across the ATTACK boundary gets an information disclosure threat (credentials sniffed in transit, mitigated by TLS) and a tampering threat (request modified in transit). The Juice Shop DB store gets tampering and information disclosure threats (database file copied out of the container).

Step 5: Record decisions, not just threats

For each threat, set a status:

• Mitigated - a control exists. Name it precisely ("WAF rule blocks UNION-based SQLi", not "security").
• Open - a gap you accept for now or will fix. Give it a priority.
• Not applicable - explain why, so the next reviewer does not re-raise it.

Then save the model. The desktop app writes a JSON file you can keep in Git alongside your lab notes, so the model evolves with the lab.

Step 6: Export the report

Open the model's report view. It lists every diagram, element and threat with status and mitigation, and lets you choose whether to include out-of-scope elements and mitigated threats. Print it or save it as PDF from the report view. A one-page summary plus this report is a strong portfolio piece: it shows you can think like an architect as well as an attacker.

Make it a habit

• Re-model when the lab changes: a new VM, a new trust boundary or a new data flow means new threats.
• After each attack exercise, check: did the model predict this? If not, add the missing threat and ask why you missed it.
• Try a second methodology on the same diagram, such as LINDDUN for the privacy view.

Keep it legal and contained

Only scan, probe or attack machines you own or have written permission to test. Keep vulnerable targets on an isolated lab network with no route to your home LAN or the internet, and never point a scanner or exploit at an address you do not control - even "just to see" is unauthorised access in most jurisdictions.

Next step

Part 6 turns predicted weaknesses into measured ones with Nessus Essentials vulnerability scanning. To practise threat modeling with guided scenarios and instant feedback, try our threat modeling lab, and use the network builder to sketch zones and trust boundaries before you draw them in Threat Dragon.