Threat modelling is one of the highest-leverage activities a security team can perform. Done well, it catches entire classes of vulnerabilities before a single line of code is written. Done poorly, it produces a spreadsheet that nobody reads. This guide walks you through running a STRIDE-based threat modelling workshop that delivers actionable results.
Why STRIDE Works
STRIDE was developed by Praerog at Microsoft in the late 1990s, and it remains the most widely used threat classification framework for a reason: it is simple enough for developers to internalize, yet comprehensive enough to surface threats across your entire attack surface. Unlike more abstract frameworks, STRIDE gives you a concrete checklist. For every trust boundary, data store, or data flow in your system, you ask six specific questions. That structure eliminates the "blank page" problem that derails so many threat modelling sessions.
The real power of STRIDE is that it maps directly to security properties. Spoofing violates authentication. Tampering violates integrity. Repudiation violates non-repudiation. Information disclosure violates confidentiality. Denial of service violates availability. Elevation of privilege violates authorization. When you frame threats this way, developers can immediately understand why each category matters and how it relates to the system they are building.
The Six Categories
Each STRIDE category represents a specific threat pattern. Understanding what falls under each one is critical for consistent results across team members.
Spoofing
Spoofing is when an attacker pretends to be someone or something else. This covers everything from stolen session tokens to DNS spoofing to phishing emails that impersonate a legitimate service. In a web application, common spoofing vectors include weak authentication mechanisms, predictable session identifiers, and missing mutual TLS between services. During a workshop, ask: "Who or what could an attacker impersonate in this flow, and how would the system detect it?"
Tampering
Tampering is the modification of data without authorization. This includes both data in transit (intercepting and modifying an API request) and data at rest (changing a value in a database). For every data flow in your architecture, consider whether the integrity of the data is protected end-to-end. Look for missing signature validation, unprotected database writes, and insufficient input validation on API endpoints.
Repudiation
Repudiation occurs when a user can deny having performed an action, and the system cannot prove otherwise. This is often overlooked but critical for audit trails and compliance. Ask: "If a user claims they never placed this order or never sent this message, can we prove them wrong?" Insufficient logging, missing audit trails, and unsigned logs are common findings.
Information Disclosure
This category covers any situation where information is exposed to someone who should not have access. It includes verbose error messages that leak stack traces, unencrypted data in transit, side-channel attacks that reveal timing information, and overly permissive access controls. During a workshop, trace every data flow and ask: "Who can see this data, and should they?"
Denial of Service
DoS threats cover anything that degrades or disrupts service availability. This is not limited to network-level floods. Resource exhaustion through expensive queries, missing rate limiting on authentication endpoints, unbounded file uploads, and recursive data parsing are all valid DoS threats. For each component, ask: "What is the most expensive operation this component performs, and what happens if an attacker triggers it repeatedly?"
Elevation of Privilege
Elevation of privilege is when an attacker gains capabilities they should not have. This includes vertical escalation (a regular user becoming an admin) and horizontal escalation (accessing another user's data). Look for missing authorization checks, insecure direct object references, and privilege assumptions in service-to-service communication. This category often produces the highest-severity findings.
How to Run a Workshop
Preparation (1-2 weeks before)
A successful workshop starts with preparation. Identify the right participants: at minimum you need a system architect or tech lead, a backend developer, a frontend developer, a security champion, and a product owner. Send participants the STRIDE reference sheet at least three days in advance so they arrive with context. Most importantly, request a Data Flow Diagram (DFD) or architecture diagram in advance. The workshop will stall without one.
Prepare the DFD by identifying the key elements: external entities (users, third-party services), processes (application components), data stores (databases, caches, file systems), and trust boundaries (network zones, authentication borders). Each element and flow between them is a potential threat target.
Execution (2-4 hours)
Start with a 15-minute walkthrough of the architecture so everyone shares the same mental model. Then, walk through the DFD element by element. For each process, data store, and data flow, systematically ask the six STRIDE questions. Write every threat on a sticky note with a consistent format: "An attacker could [threat action] by [method], resulting in [impact]."
A practical technique is to use a threat table. Create a matrix with your DFD elements as rows and STRIDE categories as columns. This ensures you do not skip any combination. For a typical web application with five to eight major components, you will typically surface 30 to 60 threats in a two-hour session.
After enumeration, rank threats using a simple risk matrix: likelihood versus impact. This gives you a prioritized list that maps directly to your backlog. Assign each critical or high threat an owner and a remediation deadline before the workshop ends.
Follow-Up (within one week)
The workshop is only valuable if the findings reach the people who can act on them. Within 48 hours, distribute a summary document that includes the DFD, the threat list, the risk ratings, and the assigned owners. Track remediation items in the same ticketing system your team uses for bugs. Schedule a 30-minute check-in two weeks later to review progress.
Practical Web Application Example
Consider a standard SaaS web application with a React frontend, a Node.js API, a PostgreSQL database, and a Redis cache. Here are sample threats from a STRIDE walkthrough of the login flow:
- Spoofing: An attacker uses a credential stuffing list against the login endpoint. No account lockout or anomaly detection is in place.
- Tampering: The session token is stored in a cookie without the
Secureflag, allowing modification over HTTP. - Repudiation: Failed login attempts are not logged, so brute-force activity cannot be correlated to an attacker.
- Information Disclosure: The login endpoint returns "invalid password" rather than "invalid credentials," confirming that an email address is registered.
- DoS: No rate limiting on the login endpoint allows an attacker to attempt thousands of passwords per minute.
- Elevation of Privilege: The password reset flow does not invalidate existing sessions, allowing an attacker who compromises email to hijack an active session.
Each of these is a concrete, actionable finding that maps directly to a remediation task.
Common Mistakes
The most frequent failure mode in threat modelling workshops is scope creep. If you try to model the entire application at once, you will produce shallow results. Start with the highest-risk feature or the one undergoing the most change, and expand from there.
Another common mistake is treating threat modelling as a one-time event. Applications evolve, and new threats emerge with every feature release. The most effective teams run lightweight threat modelling sessions as part of their sprint planning or design review process, not as an annual compliance exercise.
Finally, avoid the trap of only considering external attackers. Insider threats, compromised third-party dependencies, and misconfigured cloud services are all valid threat sources that STRIDE can surface if you ask the right questions.
Tools and Templates
You do not need expensive tooling to run an effective workshop. A whiteboard, sticky notes, and the threat table template described above are sufficient for most teams. For remote sessions, tools like Miro or Excalidraw work well. For ongoing tracking, integrate your threat list into Jira or GitHub Issues with a "threat-model" label.
For more mature programmes, consider tools like Microsoft Threat Modeling Tool (free), OWASP Threat Dragon, or IriusRisk for automated threat generation from architecture diagrams. These tools can accelerate enumeration but should supplement, not replace, the human judgment that makes threat modelling effective.
The goal of a STRIDE workshop is not to produce a perfect document. It is to build a shared understanding of threats across your team so that security becomes a design constraint, not an afterthought.
Ready to run your first threat modelling session? RedStrike offers facilitated STRIDE workshops and architecture reviews led by experienced penetration testers. Get in touch to learn how we can help your team identify threats before they become vulnerabilities.