Threat Modeling: Getting Started

Published in

Nerd For Tech

8 min readMar 6, 2024

In the ever-evolving realm of cybersecurity, understanding and mitigating potential risks are important. Threat modeling emerges as a crucial practice, providing a systematic approach to identifying, prioritizing, and addressing vulnerabilities within software systems. I wrote this article to help others that want to learn about how to get started with threat modeling. This article aims to demystify the process and reduce the barrier to entry and use the some complied resources to start learning about threat modeling!

What is Threat Modeling?

At its core, threat modeling is a process that brings the right people together to think about (and hopefully improve) the security of an application or IT system. Threat modeling is not a one time thing but rather an iterative process that improves overtime.

Technology should always be judged in its ability to support that process, and never as a goal in itself. Although software that can automate a significant parts of the work, interpreting the results and making risk decisions will require human judgement. Tooling can be implementing to help scale the effort but should not be the first step in threat modeling. Modern software systems are made of up complex systems of systems and clearly understanding the scope will be vital in successfully improving the resiliency and overall security posture of the software system.

Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.

It asks the questions:

What are we working on? → Aims to establish the project’s context and scope: project’s requirements and design, its components and their interactions.
What can go wrong? → Anticipate potential problems
What are we going to do about it? → Explore mitigations for the identified problems
Did we do a good job? → Reflect on the entire process — what does the software do, how it can go wrong, and how well we’ve mitigated and confirm that the system will be sufficiently secure. Repeat if unresolved issues remain if gaps are identified.

What is a Threat Model?

A threat model is a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through the lens of security.

Why should we Threat Model?

Threat modeling serves as a pivotal process in the software development lifecycle, providing a structured methodology for identifying and mitigating potential security risks. The primary goal of a threat model is to enable decision-makers to adopt an objective, risk-based approach in safeguarding a system against threats. This approach ensures that security measures are aligned with the actual risks the system faces.

Moreover, there are several other compelling reasons to conduct threat modeling

Creating Awareness with Stakeholders:

Threat modeling is an effective way to communicate security risks to stakeholders, including developers, management, and end-users. Raising awareness fosters a shared understanding of potential threats and the importance of implementing security measures.

2. Documenting Due Diligence:

By thoroughly documenting potential threats and mitigation strategies, threat modeling serves as evidence of due diligence in addressing security concerns. This documentation can be valuable for audits, compliance assessments, and regulatory requirements.

3. Serving as Documentation on the System:

Threat models act as living documents that capture the security posture of a system at a specific point in time. This documentation can be referenced throughout the development lifecycle and serve as a foundation for future security assessments.

4. Feeding Input into Other Practices:

Threat modeling provides valuable input for other security practices, such as security reviews and penetration testing. It guides these activities by focusing efforts on areas identified as high-risk during the threat modeling process.

5. Feedback Lessons Learned into Other Systems and Threat Models:

As part of a continuous improvement process, lessons learned from threat modeling exercises can be fed back into the development of other systems and threat models. This iterative approach helps organizations refine their security practices over time.

6. Sharing Threat Modeling Knowledge:

Threat modeling promotes knowledge sharing within development teams and across the organization. It empowers team members with an understanding of potential threats and encourages a security-aware culture, fostering collaboration among different roles, including developers, security experts, and business stakeholders.

When do we threat model?

To fully understand the threats to a system, process or application, you must do threat modeling as early as possible in the software development lifecycle (SDLC) to ensure that threats are identified and mitigated appropriately. When you do threat modeling earlier in the life cycle, security issues are less expensive to resolve and less likely to delay a project.

Threat modeling is a proactive and iterative process that can be initiated at various stages of the software development lifecycle. The optimal time to start threat modeling depends on your specific project and development methodology. Here are some key points to consider:

Early Design Phase:

Ideally, threat modeling should begin in the early stages of the design phase. As you start designing your system or application, identifying potential threats and vulnerabilities can help in integrating security measures from the outset.

2. Before Coding Begins:

Threat modeling should precede the coding phase. By identifying and addressing potential security risks before code is written, you can avoid implementing insecure design patterns or architecture.

3. During Sprint Planning (Agile/Scrum):

If you follow an Agile or Scrum development methodology, consider incorporating threat modeling into the sprint planning process. This ensures that security considerations are part of each development cycle.

4. At Key Development Milestones:

Conduct threat modeling at significant milestones in your development process, such as when major components are being integrated or when critical decisions are made regarding the architecture.

5. When Significant Changes Occur:

Whenever there are significant changes to the system, whether in terms of functionality, architecture, or technology stack, it’s a good time to revisit and update the threat model to account for the changes.

6. As Part of Code Reviews:

While threat modeling is not a substitute for code reviews, it can complement them. Integrating threat modeling considerations into code reviews ensures that the actual implementation aligns with the security design.

7. Regularly Throughout the Lifecycle:

Threat modeling should be seen as an ongoing process, not a one-time activity. Regularly revisit and update the threat model to account for changes in the threat landscape, technology, and the system itself.

8. Before Deployment:

Before deploying a system to production, perform a final threat model review to ensure that all identified risks have been appropriately addressed and that the security measures are in place.

Remember that threat modeling is most effective when it is integrated into the development process rather than treated as a separate activity. Starting early in the design phase and incorporating it into your development workflow helps create a security-conscious culture and reduces the likelihood of introducing vulnerabilities into your system.

Steps of Threat Modeling

The steps of the threat modeling are listed below and further detail can found on OWASP Threat Modeling Process.

Step 1 — Identify the assets: (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)

Step 2 — Describe Architecture: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).

Step 3 — Decompose Application: Break down the application regarding its process, including all the sub-processes that are running the application. We create a data flow diagram (DFD).

Step 4 — Identify Threats: List identify threats in a descriptive way to review to process further.

Step 5 — Document Threats: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.

Step 6 — Rates Threats: Rate the severity of the threat.

Threat Modeling Methodologies

STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege):

STRIDE is a threat modeling framework developed by Microsoft. It identifies six types of security threats that can impact software systems. Many organizations, including those in the defense sector, find STRIDE to be a practical and comprehensive approach to identifying and categorizing threats.

2. PASTA (Process for Attack Simulation and Threat Analysis):

PASTA is a threat modeling methodology that focuses on systematic attack simulations and threat analyses. It is risk-centric and aims to identify and prioritize threats based on their potential impact on business objectives. PASTA is widely used in various industries, and some organizations within the DoD may find its structured approach beneficial.

3. DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability):

DREAD is a simple threat modeling approach that uses a set of criteria to rate and prioritize threats. While it may not be as comprehensive as some other methodologies, it provides a quick and easy way to assess and prioritize threats based on specific criteria.

4. Attack Trees:

Attack trees are a graphical representation of potential attacks on a system. They illustrate the relationships between different attack steps and can be a valuable tool for visualizing and analyzing potential threats. Attack trees are often used in combination with other threat modeling methodologies.

Threat Modeling Software

Microsoft Threat Modeling Tool (Free)
OWASP Threat Dragon (Free)
Threatspec: Threat modeling as code (free)
IriusRisk
ThreatModeler

Here is a list of threat modeling examples

Here is a specific example of Kubernetes threat model:

Getting Started

There are a variety of free resources available and linked below. Finding a security partner that specializes in threat modeling is important to ensure you are implementing best practices and getting the most value of the threat modeling. Threat modeling is a continuous process and will mature overtime. There is value in creating a threat modeling process that meets the requirements of the organization. We get more value, reduce cost and resources if we have a established process how ever mature that it is when a threat model specialist is used to asses our process and provide insight into how to improve it. The Threat Model Playbook is great place to start.

I hope that you found this article insightful and helped demystify threat modeling gives you some foundational knowledge to gets started! I would love to hear your thoughts and comment below!

Cheers!