Threat Modeling Wizard

Free STRIDE Threat Modeling Wizard with DREAD Scoring

Threat modeling is the practice of finding design flaws before they become incidents — asking what can go wrong with a system while it is still cheap to change. The obstacle is almost never willingness; it is that a blank page and the instruction “think like an attacker” produces nothing useful in a one-hour meeting. This wizard replaces the blank page with a six-step process: describe the system, map its data flow, generate candidate threats from a 39-entry STRIDE library filtered to your application type, score each on DREAD, assign mitigations, and export a complete threat model as a PDF.

It is aimed at developers and architects doing a first threat model, security teams running a design review, and anyone studying CISSP Domain 1 or a similar syllabus where STRIDE and DREAD appear. Everything runs in your browser — no architecture description is uploaded.

STRIDE, Accurately

STRIDE is a mnemonic developed at Microsoft that enumerates six categories of threat. Its value is that it is exhaustive at the category level: for any component in your system, asking all six questions is far more reliable than free-associating about attacks. Each category is the violation of a specific security property.

Repudiation is the one teams routinely skip, and it is usually the one that hurts during an investigation. A system with no audit trail cannot answer “who changed this?” six months later, which is a security failure even when no attacker was involved.

The Six Steps

1. Application profile. Name, type (Web App, Mobile App, API Service, Desktop App, IoT Device, Cloud Service, or Microservices), description, data sensitivity (Public, Internal, Confidential, Restricted), user base size, whether it is internet-facing, and authentication type (None, Basic, MFA, SSO, or certificate-based). The application type drives which threats the library proposes — firmware tampering and physical access escalation appear for IoT, CSRF appears for web applications, BOLA appears for APIs and microservices.
2. Data flow. List entry points with their protocol (HTTPS, HTTP, WebSocket, gRPC, MQTT, TCP, UDP, Bluetooth, USB, REST API) and trust level (Anonymous, Authenticated User, Privileged User, Admin, System); the assets worth protecting, typed as Data, Service, or Process and classified by sensitivity; external dependencies such as databases, cloud providers, third-party APIs, CDNs, auth providers, payment gateways, DNS, email services, and storage; and a description of your trust boundaries.
3. STRIDE threats. The wizard proposes threats from its library, grouped under the six categories and filtered to your application type. Accept the relevant ones, edit their wording, add your own, and link each to the assets it affects.
4. DREAD scoring. Score each threat 1–10 on five dimensions. The average determines the risk band.
5. Mitigations. Threats are presented highest-risk first. Each carries a suggested mitigation drawn from the library; record your actual plan, a status (including explicitly accepting the risk), and a priority.
6. Summary and export. Counts of total threats, critical and high threats, mitigated threats, and accepted risks; a STRIDE coverage radar chart; a DREAD bar chart of the top fifteen threats; a full threat table; and a PDF export of the whole model.

DREAD Scoring in Practice

DREAD turns a subjective sense of severity into five explicit questions, each scored 1–10:

• Damage potential — how bad is it if this is exploited?
• Reproducibility — how reliably can the attack be repeated?
• Exploitability — how much skill, access, or effort does it take?
• Affected users — how many people are impacted?
• Discoverability — how easily would an attacker find it?

The average maps to a band: 1–3 Low, 4–6 Medium, 7–8 High, 9–10 Critical. Worked example — SQL injection on an unauthenticated public search endpoint: Damage 9 (full database read), Reproducibility 10 (deterministic), Exploitability 8 (automated tooling exists), Affected users 9 (every record), Discoverability 8 (a scanner finds it). Average 8.8, which lands as High and sits near the top of the mitigation queue.

A caveat worth stating: DREAD is a prioritisation aid, not a measurement. The scores are judgements, and different people produce different numbers for the same threat. Its real value is forcing five separate conversations instead of one argument about whether something is “critical”. Discoverability in particular deserves scepticism — scoring a flaw low because it is obscure is security through obscurity wearing a number. Score consistently within a model, and compare threats to each other rather than to an absolute scale.

The Threat Library

The wizard ships 39 threat templates spread across all six STRIDE categories, each with a description, a suggested mitigation, and the application types it applies to. A sample of what is included:

• Spoofing — session hijacking, credential stuffing, token forgery, IP spoofing, phishing and social engineering, default credential abuse, certificate spoofing.
• Tampering — SQL injection, stored XSS, parameter manipulation, man-in-the-middle, CSRF, firmware tampering, API request tampering, local data tampering.
• Repudiation — insufficient logging, log tampering, transaction repudiation, anonymous actions, clock skew exploitation.
• Information Disclosure — error message leakage, directory traversal, insecure direct object reference, unencrypted transmission, excessive data exposure, insecure local storage, reverse engineering.
• Denial of Service — resource exhaustion, application-layer DDoS, XML bomb, regex DoS, rate limit bypass, signal jamming.
• Elevation of Privilege — broken access control, privilege escalation via IDOR, JWT manipulation, insecure deserialization, BOLA, physical access escalation.

Each template carries a concrete mitigation rather than a platitude — token forgery suggests RS256 or better with server-side claim validation and token rotation; ReDoS suggests auditing patterns for catastrophic backtracking, linear-time engines, and execution timeouts.

Getting Value from a Threat Model

Three habits separate models that change systems from models that sit in a drive.

Do it during design. A threat found on a whiteboard costs a conversation. The same threat found in production costs an incident, a patch, and possibly a disclosure. Threat modeling loses most of its leverage once the architecture is fixed.

Get the data flow right first. Almost every serious finding sits on a trust boundary — the point where data crosses from a less trusted context to a more trusted one. If step two is vague, steps three through six inherit that vagueness. Spend the time on entry points, assets, and boundaries.

Close the loop. Every threat needs an outcome: mitigated, in progress, or explicitly accepted with a named owner. “Accepted risk” is a legitimate result — an unresolved threat with no decision attached is not. The summary step counts accepted risks separately for exactly this reason.

Frequently Asked Questions

What does STRIDE stand for?

Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — six threat categories, each corresponding to the violation of a security property: authentication, integrity, non-repudiation, confidentiality, availability, and authorisation respectively.

What does DREAD stand for?

Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. Each is scored 1–10 and the average gives a risk band: 1–3 Low, 4–6 Medium, 7–8 High, 9–10 Critical.

Is DREAD still recommended?

It is widely taught, including in CISSP material, and it is genuinely useful for forcing structured comparison. It is also criticised for producing scores that look more precise than the judgements behind them. Use it to rank threats within one model; do not present a DREAD average as a measurement, and consider CVSS where an industry-standard score is required.

When should I threat model?

During design, before implementation, and again whenever the architecture changes materially — a new integration, a new trust boundary, a new data classification. Revisit annually for systems that are otherwise stable.

Do I need to be a security specialist?

No. The wizard proposes threats appropriate to your application type and supplies mitigations, so the developers and architects who understand the system can produce a solid first model without a security engineer in the room. Bring one in to review the result.

What is a trust boundary?

Any point where data or control passes between contexts with different levels of trust — the internet to your API, your API to a database, a mobile app to its backend, one microservice to another. Most exploitable flaws sit on one, which is why step two asks you to name them explicitly.

Is my architecture description sent anywhere?

No. Everything — the profile, the data flow, the threats, the scores, and the PDF generation — happens in your browser. Nothing about your system is transmitted or stored on a server.

How does STRIDE relate to MITRE ATT&CK?

They work opposite ends of the same problem. STRIDE is design-time and asks what could go wrong with a system you are building. MITRE ATT&CK is operational and catalogues what adversaries actually do to systems already running. Use STRIDE to shape the design and ATT&CK to test whether you would detect an attack against it.

What should I do with the finished model?

Turn high and critical threats into tracked work items, record accepted risks with a named owner, and feed the scores into your risk register — the risk matrix calculator handles likelihood-and-impact plotting, and the incident response playbook generator covers what happens if one of them materialises anyway.