Many security problems are not implementation flaws but design flaws. A system that inherently places too much trust in its users, a data flow without validation between two components, or an authorization model that was never truly thought through: such weaknesses cannot be found by any scanner and are often expensive to fix afterward. Threat modeling is the structured method to identify these threats early, ideally before a single line of code is written. STRIDE is the most widely used framework for this. In this article we explain what threat modeling is, how to apply STRIDE in practice, and how it relates to a classic risk assessment and a pentest.
What threat modeling is
Threat modeling is systematically thinking about what can go wrong with a system, from an attacker's perspective. It revolves around four core questions, formulated by Adam Shostack in 2014: what are we building, what can go wrong, what are we going to do about it, and did we do a good job? The first question forces a clear representation of the system, usually as a data flow diagram with components, data flows, external entities, and trust boundaries. The second question is the heart of the matter: identifying threats. The third concerns countermeasures, and the fourth concerns verification.
The big win is timing. A threat you discover during design costs a conversation and an adjustment on the drawing board. That same threat exploited only in production costs an incident, remediation work, and possibly a notification obligation. Threat modeling shifts security to the left in the lifecycle, the well-known 'shift left'.
STRIDE: six categories of threats
STRIDE is a mnemonic developed by Microsoft that helps systematically brainstorm threats per component and data flow. The six letters stand for six categories, each the opposite of a desired security property.
Spoofing is impersonating someone or something else, the opposite of authentication. Think of an attacker using someone else's credentials or session token, or a service pretending to be a trusted counterpart. Countermeasures lie in strong authentication and multi-factor.
Tampering is the unauthorized modification of data or code, the opposite of integrity. Manipulating a request, a database, or a file in transit. Countermeasures include signatures, hashes, and input validation.
Repudiation is being able to deny an action, the opposite of non-repudiation. If a system does not record who did what, a user can deny their actions afterward. Reliable, tamper-resistant logging helps here.
Information disclosure is leaking information to unauthorized parties, the opposite of confidentiality. Think of overly verbose error messages, unencrypted storage, or an API returning more than necessary. Encryption and strict data minimization are the answers.
Denial of service is making a service unavailable, the opposite of availability. Resource exhaustion, missing rate limiting, or an expensive operation that can be called without limit. Countermeasures are throttling, quotas, and resilient design.
Elevation of privilege is gaining rights one is not entitled to, the opposite of authorization. An ordinary user reaching admin functions, or code running with excessive privileges. Strict access control and the principle of least privilege limit this threat.
Applying STRIDE in practice
A workable approach starts with drawing the system on a whiteboard. Place the components, draw the data flows, and mark the trust boundaries, the places where data moves from a less trusted to a more trusted zone. The interesting threats concentrate precisely on those boundaries. Then walk through the six STRIDE categories per component or data flow and ask each time: is this threat relevant here, and if so, what do we do about it? Record the outcomes: the threat, the estimate of likelihood and impact, the existing or planned countermeasure, and the owner.
Importantly, threat modeling is teamwork. The best result comes from a session with a developer, an architect, and someone with security expertise, not a document one person fills in afterward. The discussion itself often yields the most insight, because assumptions are tested out loud.
Threat modeling, risk assessment, and pentest
These three complement each other and are not substitutes. An organization-level risk assessment, such as within ISO 27001, looks broadly at threats to information provision and weighs risks against the organization's risk appetite. Threat modeling zooms in on one system or application and is far more concrete and technical. A pentest, finally, verifies after the fact whether the actually built software withstands attacks.
In the ideal order, threat modeling comes first: it drives the design and determines which countermeasures are needed. The pentest then verifies whether those measures work in practice. A good threat model also makes a pentest more targeted, because the pentester immediately knows where the sensitive spots and assumptions are. Conversely, findings from a pentest feed the threat model for the next iteration.
Common mistakes
The first and biggest mistake is doing threat modeling too late, when the design is already fixed or the software is already running. Then often only accepting or expensively repairing risks remains. The second mistake is taking it on too big: an attempt to model an entire platform at once gets stuck. Start small, with the most sensitive component or the newest functionality. The third mistake is treating threat modeling as a one-off exercise. Systems evolve, and a threat model that does not grow with them ages quickly. The fourth mistake is skipping the fourth question, did we do a good job? Without follow-up and verification, a threat model remains a list of good intentions.
Threat modeling requires no expensive tooling; a whiteboard, the right people, and an hour of focused time take you a long way. The method scales: from a lightweight session for a new feature to an in-depth analysis of a critical system.
Secure Audit helps organizations embed threat modeling in their development and risk processes, and combines it with risk assessments and pentests into a coherent security approach. Get in touch for a no-obligation conversation.
Frequently asked questions
What is threat modeling?+
Threat modeling is systematically thinking about what can go wrong with a system from an attacker's perspective. It revolves around four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job? The goal is to identify threats early in the lifecycle.
What does STRIDE stand for?+
STRIDE stands for six threat categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each category is the opposite of a desired security property, such as authentication, integrity, and authorization.
What is the difference between threat modeling and a pentest?+
Threat modeling identifies threats early, ideally in the design phase, and drives which countermeasures are needed. A pentest verifies afterward whether the actually built software withstands attacks. They complement each other: a threat model makes a pentest more targeted.
When do you perform threat modeling?+
Preferably as early as possible, during design and before code is written, and afterward at every significant change. Doing threat modeling too late, when the software is already running, limits the options to accepting or expensively repairing risks.
Do you need special tooling for threat modeling?+
No. A whiteboard, the right people (developer, architect, and security expertise), and an hour of focused time take you far. Tooling can help with documentation and repeatability, but the value lies mainly in the structured discussion.
About the author
Partner | IT Auditor