How do you choose between OWASP Threat Dragon, the Microsoft Threat Modeling Tool and IriusRisk for a team?
answer
- Who has to keep the model current?
- Open file versus proprietary versus platform
- Generated threats versus elicited threats
- Licence, operating system, audit evidence
- JSON in repo, Windows stencils, countermeasure library
basics
~20 sMatch the tool to the team's ceremony budget. Threat Dragon is free and keeps models as plain JSON; the Microsoft Threat Modeling Tool generates threats from Windows-only stencil templates; IriusRisk is a commercial platform with a countermeasure library.
solid answer
~50 sI pick on who has to maintain the model, not on feature count. OWASP Threat Dragon is open source, runs in the browser or on the desktop, and stores the model as a JSON file — so it can live beside the code and a product manager can open it without a licence. The Microsoft Threat Modeling Tool is a free Windows desktop application whose stencil templates carry threat rules, so drawing a diagram produces a generated threat list; the cost is Windows-only tooling and a stencil set that fits some architectures better than others. IriusRisk is commercial: a questionnaire or diagram drives a pattern library that emits threats plus countermeasures mapped to control standards, with tracker sync. For a small charity donation platform handling donor payment data I would take Threat Dragon — ceremony above the team's tolerance means the model stops being updated.
go deeper
Be able to say what each of the three is: Threat Dragon is the free OWASP one that saves models as JSON, the Microsoft Threat Modeling Tool is a free Windows desktop app, IriusRisk is a commercial platform. Knowing the categories is enough here.
Explain how each one produces its threat list — drawn-and-elicited versus template rules versus a pattern and countermeasure library — and what the model file looks like when you close the tool.
Show that you choose on maintenance cost and who can open the model, and defend a concrete pick for a concrete team rather than listing features. Interviewers want the ceremony-versus-cadence argument.
Own the organisational consequence: a tool choice sets the per-change friction for every team for years, decides whether models are review artefacts or compliance artefacts, and creates or avoids lock-in on the model format.
## The three tools, in one paragraph each **OWASP Threat Dragon** is an open-source OWASP project. You draw a data-flow diagram — processes, data stores, actors, flows, trust boundaries — and record threats against the elements you drew, using STRIDE (or LINDDUN for privacy) as the prompt set. Its distinguishing property is the storage format: the model is a JSON document. It can sit in the repository next to the code it describes, be opened in a browser or the desktop app, and be read by a human without the tool present. There is no licence, no server to run, and no large built-in library of prescribed controls. **The Microsoft Threat Modeling Tool** is a free Windows desktop application. You draw a diagram from a *template*: a set of stencils (element types) with properties, plus threat *rules* written against those properties. Drawing is therefore also a data-entry step — mark a flow as HTTPS or not, mark a store as encrypted or not — and the rule engine turns the resulting graph into a generated threat list, categorised by STRIDE, with a state and a justification field per threat and an HTML report at the end. It runs on Windows and stores models in its own file format rather than an open one. **IriusRisk** is a commercial threat-modeling platform. Instead of starting from a blank canvas, you describe the architecture — through a questionnaire about the components and their properties, or a diagram — and a rules engine matches that description against a library of patterns and components. The output is threats *with* countermeasures: a prescribed control set, risk-rated, mapped onto recognised control standards, and pushable into an issue tracker so the countermeasures become team tickets with states. ## The axes that actually decide it 1. **Who maintains the model.** A model that only the security engineer can open decays the moment that engineer moves teams. An open JSON file in the repo can be edited by whoever changed the design. This is the axis that usually wins. 2. **Do you want threats generated or elicited?** The Microsoft tool and IriusRisk both *generate*: draw or answer, receive a list. Threat Dragon mostly *elicits*: the diagram plus STRIDE prompts, with humans naming the threats. Generation gives a floor for a team that has never done this; elicitation gives a shorter, more honest list from a team that has. 3. **Where the answer has to go.** If the deliverable is evidence for an auditor — countermeasures traceable to a named control standard, with an owner and a state — that is what a platform like IriusRisk sells, and rebuilding it around a JSON file is a project. 4. **Platform and cost constraints.** Windows-only desktop tooling is a real friction for a team on macOS and Linux; commercial licensing is a real friction for a five-person team or an open-source project. 5. **Ceremony versus cadence.** The best tool is the one whose per-change cost is below the team's tolerance, because the value of a threat model is in its *second* revision, not its first. ## A worked choice A charity donation platform, six engineers, no dedicated security staff, handling donor payment data. Threat Dragon: the model is a JSON file committed with the code; the product manager can open it in the browser after a payment-provider change and add the new flow; the STRIDE prompts carry enough structure for a team with no prior practice. Choosing IriusRisk here would buy a countermeasure library nobody has time to triage and a licence line the charity has to defend. Reverse the facts — a regulated payments product with an audit obligation and thirty teams — and the platform's library, standards mapping and tracker sync are exactly the thing you cannot build from a JSON file. ## What none of them do No tool on this list knows what your business considers a bad day. All three produce or hold *threats*; none of them decides that donor payment data leaking is existential while a stale cache is not. None of them can tell you the diagram is wrong — that the flow you drew as internal actually crosses a boundary, or that a control you marked present was never shipped. And none of them find a threat that depends on knowledge outside the drawn model: a business rule, an operational shortcut, an inherited assumption. A tool choice sets the friction; it does not set the quality.
- The team already keeps design docs in the repo. Does that change your answer?It strengthens it. A JSON model committed beside the design doc gets reviewed by the same pull request that changes the design, so the model ages with the code rather than drifting into a wiki nobody opens. The moment the model lives somewhere with a different update ritual — a separate platform, a desktop file on one laptop — you have added a second thing to remember, and that is the step teams skip.
- How would you migrate a team off a tool later without losing the work?Assume the diagram will not survive and the threat text will. Keep the threats, the assumptions and the decisions in a form you can export — an open model file, or a report you commit — so that a migration is redrawing pictures rather than re-eliciting judgment. Tools with proprietary model formats make this an export-and-retype exercise, which is a real cost to price in when you adopt one.
Choosing here is like choosing between a shared text file, a form with validation rules, and a full workflow system: the heavier the tool, the better the audit trail and the sooner it stops being updated.
saying these in an interview costs you the question
- Picking the tool with the most features
- Assuming a commercial platform finds better threats
- Ignoring who will update the model next quarter
- Treating a generated list as the finished model
- Recommending Windows-only tooling to a Linux team