Build a full threat model in six steps: profile, data flow, STRIDE threats, DREAD scoring, mitigations, and PDF export. 39-threat library. Free in-browser.
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 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.
| Letter | Category | Property violated | Question to ask |
|---|---|---|---|
| S | Spoofing | Authentication | Can someone pretend to be a user, service, or device they are not? |
| T | Tampering | Integrity | Can data or code be modified in transit, at rest, or in memory? |
| R | Repudiation | Non-repudiation | Can someone perform an action and credibly deny it because we cannot prove otherwise? |
| I | Information Disclosure | Confidentiality | Can data reach someone not authorised to see it? |
| D | Denial of Service | Availability | Can the system be made unavailable or unusably slow? |
| E | Elevation of Privilege | Authorisation | Can someone gain capabilities beyond what they were granted? |
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.
DREAD turns a subjective sense of severity into five explicit questions, each scored 1–10:
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 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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Threat modeling is a structured approach to identifying, quantifying, and addressing security threats to a system. Rather than waiting for vulnerabilities to be discovered through penetration testing or real attacks, threat modeling proactively analyzes system architecture to find potential weaknesses before code is written or infrastructure is deployed.
Threat modeling answers four fundamental questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good job? This systematic process is recommended by OWASP, NIST, and Microsoft as an essential component of secure software development lifecycle (SSDLC) practices.
| Framework | Approach | Best For | Key Output |
|---|---|---|---|
| STRIDE | Categorize threats by type | Software applications | Threat list organized by S/T/R/I/D/E categories |
| PASTA | Risk-centric, 7-stage process | Business-aligned security | Risk-ranked threat library with attack trees |
| LINDDUN | Privacy-focused threat categories | Privacy-sensitive systems | Privacy threat catalog |
| VAST | Visual, agile, scalable | Enterprise and agile teams | Application and operational threat models |
| Attack Trees | Hierarchical decomposition of attacks | Specific attack scenarios | Tree diagrams showing attack paths and prerequisites |
| OCTAVE | Organizational risk assessment | Enterprise risk management | Risk profiles and protection strategies |
| Category | Threat Type | Example | Countermeasure |
|---|---|---|---|
| Spoofing | Pretending to be someone else | Forged authentication tokens | Strong authentication, MFA |
| Tampering | Modifying data without authorization | SQL injection, man-in-the-middle | Input validation, integrity checks |
| Repudiation | Denying an action was performed | Deleting audit logs | Secure logging, digital signatures |
| Information Disclosure | Exposing data to unauthorized parties | Unencrypted data in transit | Encryption, access controls |
| Denial of Service | Making a system unavailable | DDoS attacks, resource exhaustion | Rate limiting, redundancy |
| Elevation of Privilege | Gaining unauthorized access levels | Exploiting vulnerabilities for admin access | Least privilege, input validation |
STRIDE is a threat classification framework developed by Microsoft. Each letter represents a threat category: Spoofing (identity), Tampering (data integrity), Repudiation (deniability), Information Disclosure (confidentiality), Denial of Service (availability), and Elevation of Privilege (authorization). It helps systematically identify threats to a system.
DREAD scores each threat on five criteria from 1-10: Damage potential, Reproducibility, Exploitability, Affected users, and Discoverability. The overall DREAD score is the average of all five values (sum divided by 5). Higher scores indicate more critical threats that should be prioritized for mitigation.
Threat modeling should be performed during the design phase of any system or application, before significant code is written. It should be revisited when the architecture changes, new features are added, or new threat intelligence emerges. Regular reviews (at least annually) help catch evolving threats.
STRIDE focuses on threat categories and is best for application-level analysis. PASTA (Process for Attack Simulation and Threat Analysis) is risk-centric with 7 stages. VAST (Visual, Agile, and Simple Threat) scales for enterprise use. Attack trees map specific attack paths. This tool uses STRIDE for identification and DREAD for prioritization.
Use DREAD scores to rank threats numerically. Focus first on threats with high Damage and Exploitability scores, as these represent the greatest risk. Consider your risk appetite and budget when deciding which threats to accept, mitigate, transfer, or avoid. The tool generates a prioritized mitigation plan based on scores.
Create risk matrices and calculate risk scores. Prioritize risks by likelihood and impact. Free privacy-first risk assessment tool.
Calculate CVSS v3.1 vulnerability severity scores with Base, Temporal, and Environmental metrics. Generate vector strings and severity ratings.
Create customized IR playbooks for ransomware, data breaches, DDoS, and operational runbooks for deployments and outages. Includes compliance guidance (GDPR, HIPAA, PCI-DSS), team roles, and export to PDF/Markdown