1.10 Threat Modeling
Threat Modeling at a glance
Threat modeling is a structured way of thinking about how a system could be attacked, misused or otherwise fail from a security perspective.
Instead of waiting for vulnerabilities to appear in production, threat modeling asks security questions while a system is being designed — when architectural weaknesses are often easier to address.
Model
Understand the system, its assets, components and data flows.
What are we building?Identify Threats
Think about how the system could be attacked or misused.
What could go wrong?Mitigate
Design controls that reduce the identified risks.
What will we do about it?Threat Modeling thinking flow
1 What is Threat Modeling? Security analysis of system design
Threat modeling examines a system from a security perspective and attempts to identify potential threats before those threats become incidents.
It is particularly useful during system design because architectural security problems can be identified before large amounts of code and infrastructure depend on the design.
What could go wrong?
Threat modeling turns that broad question into a repeatable, structured security exercise.
Threat modeling can help teams:
- identify security weaknesses in architecture;
- understand attack surfaces;
- identify important trust boundaries;
- find missing security controls;
- identify dangerous assumptions;
- prioritise security requirements;
- communicate risk between architects, developers and security teams;
- design security into systems earlier.
⏰ When should Threat Modeling happen? Earlier is usually better
Threat modeling provides the greatest value when security can still influence architecture and design.
Threat model while architecture is being designed.
Review threats introduced by significant new functionality.
Reassess when data flows, components or trust boundaries change.
Assess new APIs, suppliers or external dependencies.
An application previously used username and password authentication.
The organisation changes the architecture so customers authenticate through an external identity provider.
The authentication architecture and trust boundaries have changed, so the threat model should be reviewed.A threat model created during the original design may become outdated as systems, integrations and threats evolve.
2 Define the Scope Know what is inside and outside the model
Threat modeling begins by defining what is actually being analysed.
Scope may include:
Define system boundaries
A model should distinguish between components that are part of the system and external components on which the system depends.
An online banking application uses:
- mobile application;
- web application;
- API gateway;
- application services;
- customer database;
- external identity provider;
- external payment network.
Some components may be controlled directly by the organisation while others are external dependencies.
External services may still represent important trust relationships and dependencies even when the organisation does not control them.
3 Identify Assets Understand what requires protection
Assets help establish what matters in the system and why an attacker might target it.
Customer records, credentials, financial data and intellectual property.
Important capabilities such as payments or account administration.
User accounts, administrator identities and authentication tokens.
API keys, certificates, passwords and cryptographic keys.
Services whose continued operation is important to the business.
Reputation and confidence in the system or organisation.
"If I were attacking this system, what would be valuable to me?"
4 Model the System Understand components and interactions
Effective threat modeling requires an understandable representation of how the system actually works.
The model may identify:
The goal is understanding the design well enough to identify threats.
🗺️ Data Flow Diagrams — DFDs See how information moves through the system
Data Flow Diagrams are commonly used in threat modeling to represent system components and the movement of information between them.
A user, organisation or external system interacting with the model.
A component that receives, processes or transforms information.
A location where information is stored.
Information moving between components.
Simple example
Every place where sensitive information is transmitted, processed or stored creates questions about confidentiality, integrity, authentication and authorisation.
5 Trust Boundaries Where assumptions about trust change
What is a trust boundary?
A trust boundary exists where data or execution moves between areas with different levels of trust or security authority.
Examples can include:
Data arriving from an internet user's browser crosses into an organisation-controlled web application.
The application should not automatically trust the data simply because the client sent it.Trust boundaries deserve attention
When information crosses a trust boundary, consider:
- authentication;
- authorisation;
- input validation;
- encryption;
- integrity protection;
- logging;
- rate limiting;
- assumptions about the sending system.
Whenever you see a trust boundary, ask: "What if the other side is compromised?"
🎯 Attack Surface Where can an attacker interact with the system?
The attack surface consists of the points through which an attacker may attempt to interact with, influence or compromise a system.
Internet-facing ports, services and protocols.
Public and internal application interfaces.
Forms, file uploads, messages and parameters.
Login interfaces and credential-recovery mechanisms.
Management portals, consoles and privileged APIs.
Integrations and external dependencies.
A component that does not need to be internet-accessible should not automatically be exposed to the internet.
STRIDE
STRIDE is a threat-classification approach associated with Microsoft's Security Development Lifecycle.
The acronym represents six categories of security threats:
Pretending to be another identity.
Unauthorised modification of data or code.
Denying an action without sufficient evidence to prove otherwise.
Exposing information to unauthorised parties.
Preventing or degrading legitimate use of a service.
Gaining capabilities beyond those legitimately authorised.
S Spoofing Attack the identity
What is spoofing?
Spoofing occurs when an attacker successfully pretends to be another user, system or trusted entity.
An attacker obtains a customer's username and password and logs into the application as that customer.
Security property
Can the system reliably establish who or what is communicating?
Possible mitigations
T Tampering Attack the integrity
Tampering involves unauthorised modification of information, code, configuration or communications.
An attacker intercepts a transaction request and changes the bank account number before the request reaches the payment system.
Can the system detect or prevent unauthorised modification?
Possible mitigations
R Repudiation Attack accountability and proof
Repudiation occurs when someone performs an action and can later deny having performed it because the system cannot reliably prove otherwise.
An administrator deletes important customer records.
The system uses shared administrator credentials and keeps no reliable audit logs.
It may be difficult to establish which individual performed the action.Can important actions be reliably attributed to the appropriate identity?
Possible mitigations
I Information Disclosure Attack confidentiality
Information disclosure occurs when data becomes available to someone who is not authorised to access it.
An API returns complete customer records to any authenticated user, regardless of which customer account they own.
Is sensitive information visible only to authorised parties?
Possible mitigations
D Denial of Service Attack availability
Denial of Service attempts to prevent legitimate users from accessing a service or to degrade that service significantly.
An attacker sends very large numbers of expensive API requests, exhausting application resources and preventing legitimate customers from using the service.
Can legitimate users access the service when required?
Possible mitigations
E Elevation of Privilege Attack authorisation
Elevation of privilege occurs when an attacker gains capabilities that should not be available to their current identity or privilege level.
A normal application user manipulates an API request and successfully invokes an administrator-only function.
Is every identity limited to the actions it is permitted to perform?
Possible mitigations
STRIDE memory aid
S T R I D E
STRIDE and the security properties it threatens
| STRIDE Threat | Security Property | Question |
|---|---|---|
| Spoofing | Authentication | Are you really who you claim to be? |
| Tampering | Integrity | Has information been changed? |
| Repudiation | Non-repudiation / Accountability | Can we prove who performed the action? |
| Information Disclosure | Confidentiality | Can unauthorised parties see the information? |
| Denial of Service | Availability | Can legitimate users still use the service? |
| Elevation of Privilege | Authorisation | Can someone perform actions they should not be allowed to? |
🏦 Worked STRIDE example: online banking Apply all six threat categories
System
A customer uses a mobile banking application to view balances and make payments.
S — Spoofing
An attacker steals customer credentials and authenticates as the victim.
Potential mitigation: strong MFA and session controls.
T — Tampering
A payment request is modified so money is sent to a different account.
Potential mitigation: integrity controls and secure communication.
R — Repudiation
A user denies having authorised a transaction and the system lacks reliable evidence.
Potential mitigation: reliable audit trails and transaction records.
I — Information Disclosure
An API exposes another customer's transaction history.
Potential mitigation: strong access control and data protection.
D — Denial of Service
An attacker overwhelms the login service, preventing customers from accessing accounts.
Potential mitigation: rate limiting, resilience and DDoS protection.
E — Elevation of Privilege
A normal customer manipulates an API and gains access to administrator-only functions.
Potential mitigation: server-side authorisation and least privilege.
🕵️ Think like an attacker Challenge the assumptions in the design
Threat modeling encourages teams to question assumptions made during system design.
A useful design mindset is to ask what happens if one security layer fails rather than assuming every existing control will always work.
😈 Abuse and Misuse Cases How could legitimate functionality be abused?
Traditional requirements often describe how legitimate users should use a system.
Abuse or misuse cases turn the perspective around and ask how the same functionality could be exploited.
A customer uses the password-reset function to regain access to their account.
An attacker abuses the password-reset function to take over another customer's account.
Useful questions
- Can functionality be called more often than expected?
- Can parameters be changed?
- Can steps be performed in the wrong order?
- Can the process be automated by an attacker?
- Can one user reference another user's objects?
- Can error messages reveal sensitive information?
🌳 Attack Trees Break an attacker objective into possible paths
An attack tree starts with an attacker objective and breaks that objective into possible ways it might be achieved.
Goal: Access customer account
Attack trees help reveal that a single security goal may be attacked through several completely different paths.
🧭 Threat Modeling Methodologies Different ways to structure the analysis
Threat modeling is a discipline rather than one single mandatory methodology.
Categorises threats into six security-threat classes.
Start with an attacker objective and identify possible attack paths.
Examine how legitimate system functionality might be abused.
Focuses strongly on attacker goals, techniques and possible attack paths.
Starts with important assets and identifies threats against them.
Starts with architecture and examines threats across system components and interactions.
Organisations can choose an approach that suits their architecture, development lifecycle, risk methodology and security maturity.
🔬 Threat Modeling vs Vulnerability Scanning Design analysis and technical scanning are different
Looks for potential security problems in architecture, data flows, trust relationships and design assumptions.
Looks for known or detectable weaknesses in deployed systems, software and configurations.
A customer API intentionally allows any authenticated user to request another customer's account number because object-level authorisation was never designed.
A traditional vulnerability scanner may not understand this business logic flaw.Threat modeling does not replace vulnerability scanning, penetration testing or code review.
Each technique finds different types of security weakness.
🧪 Threat Modeling vs Penetration Testing Design-time thinking vs testing implementation
Asks what could go wrong based on system design and architecture.
Actively tests whether weaknesses can be exploited in an implemented environment.
"If authorisation is not enforced server-side, one customer may be able to access another customer's records."
The tester manipulates the customer identifier in the API request and confirms that another customer's records are returned.
Identified threats provide useful scenarios for security testers to validate later.
6 Identify Mitigations Turn threats into security requirements
Finding threats is only useful if the organisation decides how they should be addressed.
Threats may result in security requirements such as:
Prove identity appropriately.
Restrict actions according to permissions.
Protect sensitive information.
Treat untrusted input appropriately.
Record important security events.
Reduce abuse and resource exhaustion.
Reduce movement between trust zones.
Limit the impact of compromise.
Threat modeling is particularly valuable when identified threats are translated into concrete design requirements rather than simply being recorded in a document.
📊 Prioritise the Threats Not every threat has equal business significance
A threat model may identify dozens or hundreds of potential threats.
Organisations therefore need to determine which require the greatest attention.
Consider factors such as:
Two systems contain similar technical weaknesses.
One is an isolated internal test environment.
The other processes millions of internet-facing customer transactions.
The business risk may be very different even though the technical weakness is similar.📝 Document and Track Threats A threat model should lead to action
Threats identified during the exercise should be recorded so they can be reviewed, assigned and tracked.
Threat: Customer may access another customer's record by changing the customer ID in an API request.
STRIDE: Information Disclosure / Elevation of Privilege
Mitigation: Enforce object-level authorisation on the server.
Owner: Application development team.
✅ Validate Mitigations Designed controls still need to work
Threat modeling identifies security requirements, but implementation still needs to be verified.
Validation may include:
Threat modeling identifies the need for server-side authorisation.
Developers add the control.
Security testing later verifies that changing object identifiers no longer provides access to another user's information.
The mitigation has now been tested rather than merely assumed.🔄 Maintain the Threat Model Architecture changes can introduce new threats
Threat models should be revisited when meaningful changes occur.
Creates additional entry points and data flows.
Introduces a new external trust relationship.
Changes architecture and security boundaries.
Changes identity and session threats.
Changes potential confidentiality impact.
May introduce elevation-of-privilege scenarios.
👥 Who should participate? Threat modeling works best collaboratively
Security professionals may facilitate threat modeling, but they rarely understand every detail of a system alone.
The security consultant understands common attack techniques.
The developer understands implementation details.
The architect understands the data flows.
The product owner understands how customers use the service.
Combining those perspectives creates a stronger threat model.⚠️ Common mistakes Threat-modeling concepts people often misunderstand
Threat modeling analyses potential security problems in design. Penetration testing actively tests an implemented system.
Diagrams help teams understand architecture. The important work is identifying and treating threats.
STRIDE provides categories that help teams systematically think about possible threats.
Significant architecture and feature changes can create new threats and trust boundaries.
External services may still create important dependencies and trust relationships.
Authentication establishes identity. It does not guarantee that the user is benign or authorised to perform every action.
Encryption can help protect confidentiality and sometimes integrity, but it does not solve spoofing, privilege escalation, denial of service or many other threats by itself.
Threat modeling complements code review, scanning, penetration testing and other security-assurance techniques.
Threats should be considered in the context of risk, business impact, existing controls and proportional treatment.
Think about design before implementation
Threat modeling questions often reward the answer that identifies security problems early and systematically rather than waiting until a system is deployed.
🗺️ Understand
🚧 Boundaries
⚡ Identify
📊 Prioritise
🛡️ Mitigate
🔄 Maintain
📝 Practice scenarios Apply threat-modeling thinking
Scenario 1
A team is designing a new customer payment application.
When should threat modeling ideally begin?
During design, while architecture and security requirements can still be influenced.
Scenario 2
An attacker logs in using credentials stolen from another user.
STRIDE category:
Spoofing.
Scenario 3
An attacker modifies an API transaction while it crosses the network.
STRIDE category:
Tampering.
Scenario 4
An administrator performs a sensitive action but the system has no reliable logs showing which administrator performed it.
STRIDE category:
Repudiation.
Scenario 5
An API exposes private customer information to another authenticated customer.
STRIDE category:
Information Disclosure.
Scenario 6
Thousands of malicious requests exhaust application capacity and prevent legitimate customers from accessing the service.
STRIDE category:
Denial of Service.
Scenario 7
A normal user manipulates an API request and successfully performs an administrator-only action.
STRIDE category:
Elevation of Privilege.
Scenario 8
Customer-controlled input crosses from the internet into a trusted application environment.
What deserves particular attention?
The trust boundary and the controls applied to the incoming data.
Scenario 9
A system architecture changes to use a new external identity provider.
What should happen to the threat model?
It should be reviewed because the architecture, dependencies and trust relationships have changed.
Scenario 10
A threat-model review identifies that one customer may be able to reference another customer's object through an API.
What should happen next?
Define an appropriate mitigation such as server-side object-level authorisation, assign ownership and later validate that the control works.
Scenario 11
A team claims a third-party payment API can be ignored because the API itself is outside the organisation's control.
Why is this problematic?
The API may still be an important external dependency and trust relationship within the system's threat model.
Scenario 12
The threat model identifies a potential attack but nobody is assigned responsibility for addressing it.
What is missing?
Mitigation ownership and tracking.
Threat Modeling memory aid
Model. Threat. Mitigate. Review.
STRIDE in six questions
Key takeaways
Threat modeling is a structured security analysis of system design.
It is particularly valuable early in development because security can influence architecture before weaknesses become expensive to change.
Start by understanding the scope, assets, architecture, components, data flows and trust boundaries.
Trust boundaries deserve particular attention because they represent places where assumptions about trust change.
STRIDE identifies six common threat categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege.
Spoofing attacks authentication.
Tampering attacks integrity.
Repudiation attacks accountability and non-repudiation.
Information Disclosure attacks confidentiality.
Denial of Service attacks availability.
Elevation of Privilege attacks authorisation.
Threat modeling may also use approaches such as attack trees and abuse or misuse cases.
Identified threats should be translated into security requirements and mitigations.
Those mitigations should later be validated through appropriate security assurance activities.
Threat modeling does not replace vulnerability scanning, code review or penetration testing — it complements them.
Threat models should be revisited when architecture, integrations, sensitive data or functionality changes.
Most importantly: understand how the system works, ask what could go wrong, and design the protection before the attack happens.
📚 Sources & Further Reading Authoritative references
- ISC2 — CISSP Certification Exam Outline
View official CISSP exam outline - Microsoft — Threat Modeling Tool
View Microsoft threat-modeling guidance - Microsoft — Getting Started with Threat Modeling
View Microsoft guidance - Microsoft — Secure Application Design
View Microsoft secure-design guidance