Threat modeling is the engineering practice of reviewing the architecture and/or design of a system and its environment with the goal of identifying, prioritizing, and addressing potential security and privacy risks before they are exploited. Threat modeling, sometimes referred to as "whiteboard hacking," is a collaborative process where participants put themselves in the mindset of an attacker and analyze the system's design and architecture from an adversarial perspective, asking "what-if" questions with the goal of uncovering security risks and their potential impact.

Threat modeling involves creating system models, data flow, and sequence diagrams of the under-review system, and documenting the attack surface, the threat actors, and the in-scope risks. If created manually, this process can create an additional workload for security and software teams, often delaying the release of software, creating friction between teams, and eventually becoming a tedious activity if it is not approached and managed properly. To address these challenges, the use of automation tools is becoming increasingly crucial, especially as the complexity of modern software systems grows due to numerous components, intricate interactions, and diverse trust boundaries.

Why Organizations Need Threat Modeling 

Designing insecure software has always been a concern in software development; however, the complexity of modern software designs has amplified the problem. In 2021, OWASP recognized "insecure design" in its 2021 Top Ten list. Over the last few years, more and more standards and regulations have required organizations to systematically apply secure software design practices and threat modeling or security risk analysis processes. Standards such as the Application Security Verification Standard, IEC/ANSI 62443, and NIST 800-53/NIST 800-63/NIST 800-218 recommend threat modeling as a standard activity for every design change or sprint planning. Additionally, the recent US Government's Executive Order (EO) on Cyber Security requires organizations to prioritize software risk management efforts, including threat detection and analysis. With the increasing focus on security and regulatory compliance, organizations must provide evidence of the measures taken to ensure robust security throughout development.

Beyond standards and regulations, threat modeling enables organizations to determine the most appropriate and cost-effective security controls and countermeasures to mitigate identified threats as early as possible. Organizations often integrate threat modeling into their risk management process. This aligns security investments with potential security risks, optimizes resource allocation, and strengthens the overall cyber resilience strategy. It also provides a competitive advantage in the face of stricter regulations. 

Threat modeling can also be a great way for organizations to "shift left" and to embark on a Secure-by-Design approach. By following a Secure-by-Design approach, organizations can incorporate suitable security controls into system designs preventing the higher costs that would result if these security gaps were only discovered during or after implementation, testing, or, worse yet, in production. This approach aligns with auditing and review requirements, as organizations can demonstrate the steps taken to ensure security from the outset of development. 

Keys to a Successful and Secure SDLC 

Gartner’s "Integrating Security Into the DevSecOps Toolchain" report suggests that threat modeling should be a core activity within the planning phase of the DevSecOps toolchain.

Treating security requirements and specifications for threat modeling as design activities gives security the same priority as other business and technical requirements that need to be addressed in the design stage, such as business logic, scalability, resiliency, testability, and efficiency. By considering security during the design stage, security controls can be integrated seamlessly into the architecture and environment of the software, reducing the likelihood of vulnerabilities being introduced later in the development lifecycle. Effectively, threat modeling during the design stage encourages cross-functional collaboration between security and software engineers/architects and product managers. This cross-team collaboration and shared understanding fosters a culture of security awareness, ensuring that security considerations are embedded throughout the SDLC. To achieve effective cross-team collaboration and communication of the identified threats, automation tools are also highly encouraged.

Threat Modeling Tools 

Performing a threat model review is not an exercise that happens without proper preparation and background work. Software and security teams need to collaborate closely to define the threat modeling process, identify system assets, gather threat intelligence information, create threat modeling artifacts/diagrams, and log identified threats. Additionally, cyber security regulations and standards require organizations to demonstrate evidence showing conformance with the use of audit trail reports and dashboards. All of these pose challenges to software and security teams that could render the whole endeavor effectively impractical at a big scale if there were no tools to automate and streamline the threat modeling activities and processes.

Benefits of Threat Modeling Automation 

Threat modeling tools allow software and security engineers to easily create and maintain data flow diagrams of their systems, regardless of their complexity and architecture. Without such tools, threat model reviewers would not be able to consistently capture all aspects of the ever-increasing attack surface of their software architectures.

Effectively, the way modern threat modeling tools manage the process allows all stakeholders to quantify the security risks and have better visibility, reporting, and understanding of the security posture of their systems.

Modern automation tools have:

• Simplified and accelerated the traditionally slow threat modeling processes by reducing time spent on repetitive tasks, resulting in substantial cost savings
• Simplified communication and improved collaboration between development and security teams
• Streamlined the threat modeling reviews and approvals workflows
• Ensured thorough attack surface coverage
• Created consistency in the way security findings are recorded, mitigated, and managed
• Allowed the threat modeling process and results to be more measurable
• Upleveled the overall quality of the process and security findings

Selecting a Threat Modeling Tool 

Selecting the right threat modeling tool involves considering key factors to meet organizational requirements. The most important factor is the tool's capabilities and ability to accurately identify security risks within a system with as few false positives as possible, taking into consideration its components, assets, trust boundaries, and attack surfaces.

Second, because security is not static, the tool should regularly update its security risk registry with newly identified threats and zero-days. Third, threat modeling tools should be compatible and integrate with the organization's existing architectural design tools to avoid duplication of designs and diagrams. For cloud-based systems that define their cloud resources via Infrastructure as Code (IaC), consider selecting a tool that can consume JSON/YAML resource files to further accelerate threat modeling of the system's cloud infrastructure. Additionally, integrating with DevOps tools and workflows for CI/CD facilitates automated threat model updates, saving additional valuable engineering time and accelerating threat modeling.

To facilitate the management of security findings within the SDLC, emphasis should be placed on the tool's integration capabilities with issue-tracking systems and collaboration platforms. This integration is critical for the overall user experience and promotes efficient teamwork.

Finally, when performing threat modeling at scale, there will be challenges around handling, analyzing, alerting, and reporting security findings. Thus, organizations should consider the threat modeling tool's capabilities on data analytics, reporting, custom dashboard creation, and compliance adherence against open standards such as the OWASP ASVS.

Figure 1: Key factors when selecting a threat modeling tool

Fundamental practice in threat modeling is the adoption of an established approach and methodology, and a structured and well-defined threat modeling review process. A solid understanding of the core approaches, methodologies, and review processes is critical for the success of a threat modeling program.

Approaches and Methodologies 

In threat modeling, a one-size-fits-all approach is not suitable for addressing the varied security needs of organizations. Instead, organizations should carefully select a threat modeling methodology and approach that aligns with their unique characteristics and security requirements. Adopting a tailored approach is key in ensuring that threat modeling remains practical and impactful in different organizational contexts.

Core Approaches 

There are four distinct approaches that provide different perspectives on analyzing and mitigating security risks:

Table 1: Comparison table highlighting the key characteristics of each threat modeling approach.

Core Methodologies 

Although there are several threat modeling methodologies, here we will examine STRIDE, PASTA, TRIKE, and OCTAVE due to their popularity in the community:

Table 2: Comparison table highlighting the key characteristics of popular threat modeling methodologies

"Four Question Framework" 

Although there are several threat modeling methodologies and approaches, asking the following high-level four key questions can help even the most inexperienced teams to launch threat modeling and maintain consistency in their threat modeling reviews.

This concise Four Question Framework, originally introduced by Adam Shostack, can be effectively utilized either independently or in combination with other threat modeling approaches and methodologies:

1. What are we building? To answer this question, teams are typically expected to produce architecture or design documents, data flow diagrams, asset inventories, and data classifications.
2. What can go wrong? Identify the main security and privacy threats that could compromise your system components or assets. Teams typically use a threat list such as STRIDE or OWASP Top 10 to answer this question.
3. What are we going to do about it? Identify what needs to be done to mitigate the impact of these threats. Teams typically implement security controls or defense-in-depth mechanisms to answer this question.
4. Did we do a good enough job? It is imperative to conclude the process by conducting a retrospective analysis and identifying any lessons learned. The primary objective is to continuously improve the effectiveness of the implemented mitigations and enhance the overall threat modeling process.

 Figure 2: Four Question Framework

Threat Model Reviews 

A core activity in threat modeling is a review meeting with stakeholders — with the goal of identifying, prioritizing, and addressing potential security and privacy risks.

Defining Processes and Expectations 

To perform threat modeling successfully, key stakeholders should define the end-to-end processes, expectations, and KPIs. This process must be well-accepted by both business leaders and security and software stakeholders.

The process should ensure that the following are defined:

• When reviews should be conducted – Some teams conduct threat modeling after sprint planning, while others conduct it on a specific cadence. If done on a specific cadence, the frequency should be defined.
• Who should participate in the review meetings – Define the responsibility of each participant. Threat modeling is a collaborative activity and should not be conducted only by a single team.
• Proper communication channels – Assign communication channels for planning and threat recording, reporting, and alerting.
• The scope of each review– This includes:
  1. Which aspects of the system should be reviewed
  2. Which risks should be assessed
  3. Breadth and depth of the review
• Categorization and prioritization of risks – This is how individual risks should be categorized, prioritized, and accepted.
• Top threats for the organization – Keep in mind threat intelligence is important at this stage.
• Security controls (remediations and mitigations) available
• Preparation expected from all stakeholders 
• SLAs for each identified threat
• What artifacts are expected to be created before each review 

Creating Threat Modeling Artifacts 

Before conducting threat modeling reviews, the following artifacts must be created and communicated to the review team in advance. Once again, the creation of these artifacts should be a collaborative effort among all stakeholders.

• Inventory of assets, components, and trust boundaries – This provides a comprehensive identification of the various elements involved, including any sensitive data and any other valuable resources that may be targeted by attackers.
• Data flow diagrams (DFDs) – These are visual representations that illustrate how data flow between the components and through the trust boundaries. They can be created using any diagramming tool; however, there are many advantages in using a threat modeling tool. Such tools analyze the DFDs and help identify potential vulnerabilities and attack vectors by highlighting the paths data takes through the system.
• Design diagrams – These optional artifacts, such as UML sequence diagrams, could be useful when threat modeling complex sequences and interactions, such as authentication and authorization protocols.
• Identification and documentation of security requirements, use cases, and abuse cases – This ensures that the focus remains on addressing specific security concerns and invariants of the system under review. 

Threat modeling automation tools offer significant time-saving benefits by importing system components from resource files, such as Terraform configurations. This eliminates manual entry and enables quick generation of diagrams illustrating assets, components, and trust boundaries. The tools identify shared components, libraries, and patterns, reducing effort and identifying risks affecting multiple areas. They establish trust boundaries by identifying interfaces and interactions, thus enhancing the accuracy and consistency of artifacts.

Figure 3: Sample Data Flow Diagram that illustrates a simple AuthN/AuthZ process in a web application

Figure 4: Sample threats identified by OWASP Threat Dragon

Assessing and Documenting Identified Threats 

Once threats have been identified, they should be assessed based on their likelihood and impact. This evaluation helps in determining the severity of each threat. It is critical to analyze both internal and external elements that may influence the likelihood and impact of any threat.

Threat documentation should be clear and unambiguous. It should include the classification of the threat, its attack vector, possible impact on the system, and any existing vulnerabilities that may be exploited. Importantly, threat documentation should be actionable and development teams should include their mitigation as part of their "definition of done." Information about the recommended mitigations or security controls to address each threat must be included, such as details about the feasibility, implementation considerations, and dependencies of each mitigation.

Automation tools also provide significant business value in assessing and documenting identified threats. By automating the risk assessment process, organizations can obtain consistent and objective risk ranking, facilitating better decision-making. Additionally, via the tool's integrations, risks from many sources can be assessed automatically, such as from vulnerability scanners and pen testing vulnerability reports. Risk acceptance can also be accelerated via integration with information risk and governance registers. Finally, tools can automate the consistent documentation of findings via their templates and their integration capabilities with bug-tracking systems.

Measuring Success 

Threat modeling can become an expensive investment in money and time for an organization. Thus, it must produce results for the organization. Measuring its success and evaluating its effectiveness is critical both to confirm that the process produces value as well as for process improvement. Automation tools with reporting and regulatory compliance capabilities, along with live dashboards, play a significant role in this regard.

Key performance indicators (KPIs) are vital in measuring success as they provide metrics to assess the success of a threat modeling process. Example KPIs include:

• Number of identified threats
• Closure rate of high-risk threats
  • I.e., average human hours saved if these vulnerabilities were fixed post-release
• Reduction of security incidents
• Number of security controls implemented as a result of threat modeling
• Operating costs

 Automation tools facilitate the collection and analysis of KPIs, enabling a comprehensive assessment of the threat modeling process. They provide reports and visualizations that highlight the performance against KPIs, making it easier to track process metrics and identify trends in security risks. Additionally, automation tools can help evaluate the adequacy of mitigation strategies. Coverage and completeness metrics highlight the thoroughness of the threat modeling process, ensuring critical areas aren't overlooked.

Automation tools also measure time and resource savings, quantifying the efficiency gains achieved. The automatically generated compliance reports demonstrate regulatory adherence to meet legal and regulatory obligations as well as ensuring that best practices are adopted. Tools that offer live dashboards provide real-time insights into threat status, mitigation progress, and overall security posture. Monitoring these metrics over time enables tracking of improvement and success in overall threat management.

Threat modeling is a critical practice in secure software design, offering proactive risk mitigation. As software systems become more complex and vulnerabilities increase, organizations must embrace a proactive security approach. Automation tools are vital for streamlining and enhancing the threat modeling process, ensuring consistency, accuracy, and improved team collaboration. Successful threat modeling necessitates selecting the appropriate tool, adopting suitable methodologies, and asking key questions. By integrating threat modeling tools into the DevSecOps toolchain, following a Secure-by-Design approach, and proactively managing security risks, organizations can establish a robust security foundation throughout the software development lifecycle.

It is essential to recognize that threat modeling is an ongoing process that adapts to evolving systems and the ever-changing security and privacy threat landscape. Staying up to date with the latest threats and adhering to Secure-by-Design standards and regulations are crucial for maintaining an effective threat modeling program.

When diving deeper into threat modeling, it is strongly recommended to study the Threat Modeling Manifesto and connect with other threat model practitioners in communities such as Threat Modeling Connect. Additionally, the following resources provide valuable information and insights on threat modeling:

• Threat Modeling: Designing for Security by Adam Shostack
• Threat Modeling: A Practical Guide for Development Teams by Izar Tarandach and Matthew J. Coles 
• OWASP Threat Modeling Cheat Sheet
• OWASP Application Security Verification Standard