Threat Modeling Hands-On

Introduction

Threat modeling can feel intimidating, especially if you're unsure where to begin, don’t know the right tools, or are unfamiliar with the methodologies. In this article, I want to present the concept and apply it to a real-world scenario to demonstrate its value.

But before we dive into the example, it's important to address some questions why threat modeling is essential and why it often gets neglected despite the benefits.

Though it’s often linked with SSDLC and the shift-left approach to security, threat modeling is far more than just a trendy buzzword. In fact, it has been around for quite some time now, initially emerging through attack tree analysis and evolving into more formalized discipline with diverse tools and methods. Today, it is a critical practice for evaluating the security of any new system during its design phase.

But why is threat modeling so important when you already have penetration testing, code analysis, vulnerability scanning, and secure development practices in place? The answer is simple: the earlier you fix a security issue in the design stage the cheaper it is, and threat modeling is one of those tools that allows you to do so. If you can address potential issues before the system is built, you can avoid costly and complicated patches later on.

Of course, no threat model is perfect, nor is it static—it needs to evolve as the system evolves and be reviewed whenever a security incident happens. The goal isn’t to identify every possible threat at once, but to provide a structured and consistent way of thinking through potential risks. When security engineers participate in architecture discussions sitting around a table with other engineers, instead of raising random ad-hoc questions about logging, access management, or other controls that may be missed, threat modeling offers a more reliable, methodical way to anticipate threats.

So, why isn’t threat modeling used more widely? I believe there are several reasons here such as lack of education and practice or concerns about adding friction to the design process. Some teams view it as too complex, too time-consuming, not relevant for what they are doing in their industry or think it’s only for a certain security maturity level. But these are misconceptions.

Another challenge is choosing the right approach. Not all methodologies are appropriate for every scenario. Threat modeling for a software application is different from threat modeling a network architecture, and selecting the wrong tool or method can be painful. And of course, let’s not forget, creating diagrams digitally can be slow and tedious.

However, the true power of threat modeling lies in its collaborative nature. Working together, especially on a whiteboard, allows team members to express ideas, visualize threats, and revise the design in real-time. Everyone brings their unique perspective, and this collective effort captures a wider range of potential threats. Compared to relying on random ad-hoc questions, which can be inconsistent and incomplete, a structured and collaborative threat modeling session is far better to anticipate security risks.

Threat Modeling Basics

The Four Questions Framework

The Four Questions Framework are the foundations of threat modeling. If you cannot afford anything else, at least you should do this whenever you are going to implement a change, it can be a new feature or an architectural change. The Threat Modeling Manifesto defines the threat modeling process by answering these four questions:

1. What are we working on? (what are we building?)
2. What can go wrong? (what are the risks/threats?)
3. What are we going to do about it? (what are the mitigations?)
4. Did we do a good enough job? (what is the residual risk?)

Note: You could add for example these questions to a Jira ticket template for your software's new features to make sure threat modeling has been done and threats have been addressed with appropriate mitigations. You could even score the risk of what can go wrong (likelihood × impact) to prioritize tickets for your security team.

The Most Common Methodologies

STRIDE Methodology

Summary

STRIDE is an acronym that stands for six categories of threats:

• Spoofing: Impersonating another entity.
• Tampering: Unauthorized modification of data.
• Repudiation: Denying an action or event.
• Information Disclosure: Leak of sensitive data.
• Denial of Service: Disrupting service availability.
• Elevation of Privilege: Unauthorized escalation of access or permissions.

Developed by Microsoft, STRIDE is often used to identify potential threats during the design phase of software development. It is particularly effective in pinpointing and categorizing threats, making it easier to address specific security requirements.

Best Use Case

STRIDE is best used in the design and architecture stages of application development, especially for identifying potential vulnerabilities early on. It is ideal for projects where detailed threat identification and categorization are crucial, such as in financial systems, healthcare applications, or any environment where data integrity and confidentiality are paramount.

DREAD Methodology

Summary

DREAD is a risk assessment model that helps prioritize threats based on five factors:

• Damage Potential: The potential impact of the threat.
• Reproducibility: The ease of reproducing the threat.
• Exploitability: The ease of exploiting the threat.
• Affected Users: The number of users affected.
• Discoverability: The likelihood of the threat being discovered.

Each factor is rated on a scale, and the scores are combined to determine the overall risk level of each threat. This quantifiable approach aids in focusing on the most significant threats first.
Risk = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

Best Use Case

DREAD is best used when prioritizing threats and determining which ones need immediate attention. It is particularly useful in post-development phases or during penetration testing, where the focus is on understanding and mitigating risks in an already existing system.

Note: This methodology can resonate with you if you are familiar with the CVSS scoring.

PASTA Methodology

Summary

PASTA (Process for Attack Simulation and Threat Analysis) is a seven-step risk-centric threat modeling methodology:

1. Definition of Objectives: Understanding business objectives and security requirements.
2. Definition of the Technical Scope: Identifying technical assets and environments.
3. Application Decomposition and Analysis: Breaking down the application to understand its components.
4. Threat Analysis: Identifying and categorizing threats.
5. Vulnerability Analysis: Pinpointing vulnerabilities within the application.
6. Attack Modeling: Simulating potential attacks based on the identified threats and vulnerabilities.
7. Risk Analysis and Management: Assessing the risks and prioritizing mitigation strategies.
   PASTA focuses on aligning business objectives with security efforts, providing a comprehensive view of the threat landscape.

Best Use Case

PASTA is best used in complex environments where aligning security with business objectives is crucial. It is ideal for large enterprises with intricate systems, such as e-commerce platforms or multinational corporations, where understanding the broader impact of threats on business operations is essential.

Threat Modeling Drawing

The Five Elements

When creating a Threat Model, typically alongside a Data Flow Diagram (DFD) and an Architecture Diagram, there are five key elements you will usually find in the diagram (from the defender perspective):

• External Entities: Components outside our control.
• Processes: Code or activities under our control.
• Data Flow: Arrows indicating how data moves between entities and processes.
• Data Store: Where data is held.
• Trust Boundaries: Indicate areas where elements are in different entitles control (people or processes).

Scenario : Internet Banking System

The below diagram represents the architecture of a fictional online banking system I just took from the C4 model website. It describes the interaction between the bank customers and the various internal systems that enable online personal banking, including web and mobile banking. The 3 core systems are grouped within the bank's infrastructure, including a mainframe banking system that manages customer data, accounts, and transactions, an internal email system and the internet banking system. The internet banking system provides account viewing and payment services through multiple channels: a web-based single-page application (SPA), a mobile app, and backend applications. The API application mediates between the customer-facing components and the underlying mainframe. A dedicated Oracle database stores user credentials, logs, and registration details. The deployment environments are categorized into development and live (production), reflecting separate infrastructures for testing and production.

While the architecture includes multiple diagrams (system-context, component, class, deployment), the container diagram is the one I will choose for threat modeling as it best showcases the distinct components as containers. If I wanted a more specific threat model for the API, I would choose the component diagram where the API functionalities are more detailed.

Threat Modeling the Internet Banking System

Below, I have reproduced the system diagram in the OWASP's Threat Dragon tool – a great open-source tool for threat modeling. Alternatively, you could use other tools such as the Microsoft Threat Modeling Tool, draw.io (with threat modeling libraries), CAIRIS, or other proprietary software. The most important is to choose a tool that aligns with your work, where your models are portable, and where collaboration with your team is easy.

But before drawing on the diagram, I start by identifying key assets to protect and defining trust boundaries. This helps frame the potential threats and prioritize mitigations effectively.

Assets to Protect:

• Customer Data – Personal information, account details, transaction history
• Authentication Credentials – Hashed passwords, tokens
• Banking Services – Payments, account management
• Internal Bank Systems – Mainframe, email systems
• Communication Channels – Web, mobile app, APIs

Trust Boundaries:

• Between customers' devices (browsers/mobile apps) and the internet banking system
• Between internet-facing components (SPA, mobile app) and the API application
• Between the API application and internal systems (mainframe, database, email)
• Within the bank’s internal data center (live vs. development environments) – (Excluded for this model)

In the below updated diagram, I've drawn the trust boundaries and started documenting threats and mitigations I could identify. The list isn't exhaustive, but it highlights some critical concerns.

In Threat Dragon, threats are modeled using STRIDE by default, but the tool also supports other methodologies such as LINDDUN, CIA, DIE, and PLOT4ai. Depending on the system you're modeling, it may not be necessary to apply all these models. I let you judge based on your specific needs.

Threats and Mitigations (By Component):

Web Application:

1. Credential Theft
   • Type: Spoofing
   • Priority: High
   • Description: Phishing, brute force, or session hijacking targeting the sign-in process.
   • Mitigations: MFA, secure session management, password complexity policies.
2. Application Vulnerabilities
   • Type: Tampering
   • Priority: Medium
   • Description: Exploiting bugs in web/mobile applications or backend API.
   • Mitigations: Penetration testing, code reviews, automated vulnerability scanning.
3. Man-in-the-Middle (MITM) Attacks
   • Type: Information Disclosure
   • Priority: Medium
   • Description: Data interception between customers and banking systems.
   • Mitigations: HTTPS enforcement, HSTS, TLS 1.2/1.3.
4. Denial of Service (DoS)
   • Type: Denial of Service
   • Priority: Medium
   • Description: Overloading web endpoints to disrupt services.
   • Mitigations: Traffic filtering, load balancing, rate limiting.

Mobile Application:

5. Credential Theft
   • Type: Spoofing
   • Priority: Medium
   • Description: Phishing or session hijacking during mobile sign-in.
   • Mitigations: MFA, secure session management, password complexity policies.

API Application:

6. Data Breaches
   • Type: Information Disclosure
   • Priority: High
   • Description: Unauthorized API access exposing sensitive data.
   • Mitigations: API security (rate limiting, encryption, input validation), database encryption.

Database:

7. Data Breaches
   • Type: Information Disclosure
   • Priority: High
   • Description: Compromised database via API endpoint vulnerabilities.
   • Mitigations: Encrypt data, rate limiting, secure input validation.
8. Data Loss
   • Type: Denial of Service
   • Priority: High
   • Description: Failures in replication or backups.
   • Mitigations: Data backups, failover testing, database redundancy.

Mainframe Banking System:

9. Insider Threats
   • Type: Repudiation
   • Priority: Medium
   • Description: Malicious bank staff actions compromising sensitive systems.
   • Mitigations: Role-based access control (RBAC), audit logs, employee training.

Email System:

10. API Endpoint Spoofing for Password Resets

• Type: Spoofing
• Priority: Medium
• Description: Attackers trigger password resets to malicious addresses via API.
• Mitigations: MFA/CAPTCHA on reset, rate limiting, email validation.

11. Intercepting/Modifying Email Content

• Type: Tampering
• Priority: High
• Description: Attackers alter reset emails, injecting malicious URLs.
• Mitigations: Digital email signatures, non-modifiable email templates.

12. Admin Account Takeover via API Password Reset

• Type: Elevation of Privilege
• Priority: High
• Description: Attackers exploit API reset vulnerabilities for admin accounts.
• Mitigations: Restrict admin resets to manual processes, privilege separation in API logic.

Conclusion

To conclude this post, I would like to encourage anyone working in security or involved in systems design to give it a try – threat modeling is a valuable addition to your toolkit. Not only does it help you shift left the security and identify potential vulnerabilities before they arise but it helps you get a global understanding of the system’s architecture and its attack surfaces. It's also a great way to engage development teams in security from day one. And if you're looking to deepen your knowledge, there are plenty of excellent resources available online. Also, I can only recommend Adam Shostack’s books and the Threat Model Connect Community.

References

• Threat Modeling Manifesto
• OWASP Threat Modeling
• OWASP Threat Modeling Process
• OWASP Threat Modeling Cheat Sheet
• Cairis
• draw.io - see also threat modeling libraries for the tool
• Microsoft Threat Modeling Tool
• OWASP's Threat Dragon
• The Ultimate Beginner's Guide to Threat Modeling
• CMS Threat Modeling Handbook
• https://c4model.com/