What is threat modeling? | Definition from TechTarget

What is threat modeling in software development?

In terms of software security, threat modeling is the most important part of software design and development. In fact, it is now an inseparable aspect of the modern-day software development lifecycle (SDLC). It is virtually impossible to build applications and systems that comply with corporate security policies, and privacy and regulatory requirements without evaluating and mitigating threats. An understanding of threat modeling during application development is critical.

By adopting a structured threat modeling approach, software teams can identify potential security risks earlier in the SDLC. And by making threat modeling part of the DevOps process, developers can build security into a project during the development and maintenance phases — a security-oriented approach known as shift-left testing. This approach helps developers avoid common errors, such as failing to validate input, weak authentication, inadequate error handling and failing to encrypt data.

Threat modeling also enables development teams to determine what actions are needed to mitigate the risks of these errors. A threat model is very useful for creating a prioritized list of needed security improvements that can help in ensuring that the final software product is as secure as possible even before it is deployed and delivered to end users. Of course, threat modeling is an iterative process that teams should keep in mind throughout the SDLC.

Why is threat modeling important?

Threat modeling is a proactive method of uncovering threats and establishing the security requirements needed to ensure that an application or system can withstand cyberattacks. It is a systematic and structured process that aims to identify potential threats and vulnerabilities to reduce the risk to IT resources.

Adopting threat modeling early in the SDLC lets project team better understand the impact of threats, quantify their severity, determine which security controls are needed to protect an application against potential threats and how to resolve problems. Identifying the security requirements of a system (or process) early is particularly important if it is business- or mission-critical, or if processes are sensitive or involve valuable data. In addition to resulting in more secure applications, anticipating and then prioritizing threats by creating threat models also ensures that testing and development resources are used more effectively to create better quality applications.

5 steps of threat modeling

Almost all threat modeling efforts follow a standard five-step process:

1. Determine the scope of work. Before identifying or mitigating potential threats, it’s important for a development team to first understand the scope of the threat modeling process. To achieve that, they should create data flow diagrams (DFDs) to represent data flows in the application and to highlight privilege or trust boundaries, identify the assets that could be impacted by threats (create an assets inventory) and identify potential entry points that could allow threat actors to interact with and potentially compromise the application. In this initial step, teams may also create abuser stories or misuse cases to further clarify the scope of work for the threat modeling effort.
2. Gather threat intelligence. In this step, the threats that may potentially harm a business application are identified. Ask “what could go wrong” and anticipate how much damage could occur, by looking at the application and its threats from the perspective of a malicious actor, such as a cybercriminal or hacker. This what-if exercise helps teams to build broad, technical and even unexpected threat scenarios and attack trees, which can help them to identify possible vulnerabilities that may lead to compromise or failure. Threat modeling tools can help automate and streamline this step. Also, when gathering threat intelligence, teams often use standard or well-known threat categorization methodologies like STRIDE, PASTA or TRIKE.
3. Perform threat mapping. Once the potential threats are identified, it’s important to map them in the organization’s actual context. This involves assessing what potential path each threat could take through the organization’s systems. Threat mapping helps teams to understand the perspective of attackers and use this understanding to determine and implement stronger defenses.
4. Determine countermeasures for identified threats. In this step, teams consider and implement countermeasures and controls to reduce the risk of each identified threat. To support the effort, they may use mapping lists, consider factors such as likelihood of attack and potential for damage, and prioritize measures by considering the criticality of the asset, cost of fixes and whether a measure is the most effective way to mitigate a risk. They determine the level of risk each threat poses and rank them to prioritize risk mitigation, often by multiplying the damage potential of a threat by its likelihood of occurrence. Different risk mitigation measures may also be considered, such as avoid the risk, eliminate the risk, accept the risk, mitigate the risk or transfer the risk.
5. Validate the measures after implementation. At this point, teams assess if they have acted on the previous steps. They also check if records exist, such as DFDs and a threats list. Transparent and honest self-assessments are crucial to implement better defenses and countermeasures, which in turn are vital to strengthen the organization’s security posture.

In addition to the five steps, a threat modeling process may also include additional steps, such as the following:

• Form a team. The team may include stakeholders, such as business owners, developers, network architects, security experts and C-level execs. A diverse team helps to generate a more holistic threat model that will likely be more relevant to the specific organization.
• Document results. Document all findings and actions, so future changes to the application, threat landscape and operating environment can be quickly assessed and the threat model updated.

Threat modeling best practices

There are several steps to take to ensure an effective approach to threat modeling:

• Start early. Threat modeling can be done at any time during a project, but earlier in the SDLC is better, as the findings can help ensure that the design is secure from the outset. Also, identifying threats early makes it faster and cheaper to secure applications, since security controls can be added early in the build process to prevent errors later in the SDLC.
• Get inputs from multiple stakeholders. Soliciting input from a variety of stakeholders helps identify the widest range of potential adversaries, motives and threats, and where the most vulnerable components reside. This activity then guides the process for identifying and implementing appropriate countermeasures.
• Use threat modeling tools. Many tools are available that simplify threat modeling. Using these tools enables teams to discover threats and potential avenues of attack, including less common or novel ones. The tools also help to prioritize threats and determine the best way to respond to them.
• Create documentation. Detailed documentation is vital to ensure that the threat modeling process proceeds as desired and also to bring much-needed transparency and accountability to the process. Data flow diagrams, diagrams of all major system components, asset inventories, threat trees, traceability matrices, etc., are all useful documents that support and enhance threat modeling.
• Understand risk tolerance. Business owners must understand and communicate the organization’s risk tolerance level to the development and security teams. Doing this ensures that the correct threat mitigation approaches are chosen to mitigate risk and meet business goals.
• Provide security training. Train everyone involved in the different aspects of threat modeling, so their input can be maximized and the threat modeling effort optimized.

Threat modeling methodologies and frameworks

Early threat modeling methodologies relied mainly on data flow diagrams to visualize how data moves through an application or system and to highlight its privilege boundaries. However, since DFDs lack control flows due to the absence of loops and decision rules, they are often too limited for modern applications. This is because applications are often deployed in highly interconnected environments with multiple users and devices connecting to them. Also, if there are too many processes or systems, DFDs can become very complex to create and maintain. Furthermore, they may still not provide the detail needed to represent the system, application or process, and to identify, map or mitigate the threats affecting it.

Process flow diagrams are now commonly used. A PFD shows the relationships and interactions between the different components of an application or system. It also shows that application or system from the perspective of user interactions and how potential attackers may try to move through it in order to compromise it. Creating PFDs makes it easier to spot, prioritize and address potential threats before they can cause any damage to the organization’s applications or systems.

Attack trees are also used to visualize potential attacks on a system. In an attack tree, the root represents the goal of an attack and the leaves represent the various ways the attack might achieve that goal. Attack trees can be built for individual components of an application or to evaluate a specific type of attack.

A threat modeling methodology is a way to break down a complex process into smaller tasks, making it easy to spot weaknesses. In recent years, many methodologies and frameworks have been developed. These frameworks may be attack-centric or asset-centric. Attack-centric methodologies focus on the types of possible attacks, and asset-centric frameworks focus on the assets that need to be protected from attack.

The most popular threat modeling frameworks in use today include the following:

• Damage, Reproducibility, Exploitability, Affected users, Discoverability. DREAD is a quantitative risk analysis methodology that rates, compares and prioritizes a cyberthreat’s severity. Each letter of the acronym represents a category. Also, the methodology uses a scaled rating system, with threats issued a rating between 0 and 10 for each category. The average of these category ratings indicates the threat’s overall severity.
• National Institute of Standards and Technology Guide to Data-Centric System Threat Modeling. This book from the NIST explains data-centric system threat modeling that enables organizations to create threat models focused on protecting particular data types within systems. It models aspects of attack and defense for selected data. It’s best to use the guide as part of (or to complement) existing risk management processes rather than replacing them entirely.
• Operationally Critical Threat, Asset and Vulnerability Evaluation. OCTAVE provides an asset- and risk-based strategic assessment that is customizable for specific security objectives and risk management. Any organization can use OCTAVE to identify mission-critical assets and understand what information within those assets is at risk.
• Process for Attack Simulation and Threat Analysis. PASTA is a seven-step attack-centric framework designed to correlate technical requirements with business objectives, considering business impact analysis and compliance requirements. Unlike many other frameworks, PASTA is a strategic framework since it considers inputs from all stakeholders, including business users and managers, and not just security, development or IT teams. A score-based risk and impact analysis is an important element of PASTA.
• Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. STRIDE was developed by Microsoft and is part of the Microsoft Security Development Lifecycle. It identifies system entities, events and the boundaries, and then applies a set of known threats. Security teams can use this free tool to identify and analyze potential threats.
• TRIKE. TRIKE (also spelled as Trike) is an open source, risk-centric framework that ensures each asset’s assigned risk level is OK with all interested parties. It includes a requirements model and an implementation model. The requirements model, a conceptual framework for threat modeling, enables security teams to describe a system’s security features and acceptable levels of risk, and to create an actor-asset-action matrix that defines what actions (on the system) can be performed by which actors. The implementation model in TRIKE allows teams to create DFDs, discover potential threats and evaluate the risk level of each threat.
• Visual, Agile and Simple Threat. VAST is based on ThreatModeler, an automated threat modeling tool designed to integrate into an Agile software development environment and provide actionable outputs for developers and security teams. The results of the modeling effort can be used to compare and measure risk throughout the organization.

Threat modeling tools

Tools reduce the complexity of the threat modeling process, make it structured and repeatable, and help reduce the number of resources needed to create and maintain a threat model. The best threat modeling tools let users visualize, predict and plan for all sorts of potential threats, and include these key features:

• Ease of input for both system information and security rules.
• Threat intelligence feed to ensure the latest identified threats are considered.
• Threat dashboard with suggested mitigation strategies.
• Mitigation dashboard that integrates with an issue tracker like Jira.
• Reports for compliance and stakeholders.

Many threat modeling tools are now available; these are among the most popular:

• CAIRIS. An open source platform that uses intelligence about potential threats to measure the attack surface and validate designs for known security problems and potential compliance issues. CAIRIS enables development teams to build security and usability into their applications. They can do so by visualizing application design from multiple perspectives (people, risks, requirements, etc.), automatically generating threat models, discovering risks early in the SDLC and measuring the application’s attack surface.
• IriusRisk. IriusRisk provides AI-generated and automated threat modeling, so development teams can successfully shift security left and develop more secure applications. Users can generate threat model diagrams by using their user stories, documents and code. The tool also provides security controls (countermeasures) to speed up threat modeling, coding and deployment.
• Microsoft Threat Modeling Tool. This free resource from Microsoft provides a standard notation for visualizing system components, data flows and security boundaries, thus simplifying threat modeling, even for developers who are not security experts. It also provides guidance on creating and analyzing threat models.
• OWASP Threat Dragon. This open source threat modeling tool runs as a web or a desktop application. It records possible threats, shows threat model components and threat surfaces, and enables users to determine mitigation approaches.
• SD Elements. SD Elements is a commercial tool that collects and classifies system information based on vulnerabilities, providing audit-ready reports. It also generates security and compliance requirements by scanning a team’s GitHub or GitLab repository, or by importing or building diagrams. Teams can also customize the security and compliance requirements in the built-in library per their specific needs.
• Threagile. This open source toolkit incorporates threat modeling at the application codebase. Teams can use it to model an architecture in an Agile declarative fashion as a YAML file directly within the IDE or any YAML editor. The tool executes security checks against the architecture and then generates a report listing potential risks and mitigation recommendations.
• ThreatModeler. The ThreatModeler platform automates threat modeling and enables DevOps teams to visualize their attack surfaces and mitigate security flaws in the SDLC. The platform works in cloud, mobile and IoT environments. It also includes built-in regulatory compliance frameworks to simplify compliance and supports infrastructure as code (IaC) to provide continuous visibility into design flaws.

History of threat modeling

IT-based threat modeling gained traction in the 1990s with the development of threat and attacker profiles. Microsoft introduced its STRIDE threat modeling methodology in 1999. Over the years, many other threat modeling approaches have evolved. They all involve deconstructing the elements of an application or system to identify the assets to be protected and the possible threats to be mitigated.

More recently, in 2020, a group of threat modeling practitioners and researchers published the Threat Modeling Manifesto to help users develop or refine an existing methodology to best satisfy their unique requirements. The Manifesto contains five values and four principles that together provide a way to simplify threat modeling while also strengthening the security of systems.

Threat modeling is a necessary effort

Whichever tool is used, the threat modeling process should be repeated whenever the application, IT infrastructure or threat environment changes. It is important to keep threat models current as new threats emerge.

Analyzing threats involves time and effort. It is not a checklist exercise, but it is better to find a vulnerability and fix it before hackers discover it, and threat modeling methodology is the best way to achieve this.

Learn incident response strategies that you can use in our complete guide to incident response.