Guidance to Mature Your Threat Modeling Program

July 4, 2023 | By IANS Faculty

For those just starting with threat modeling, try starting small and targeting low-hanging fruit as you begin integrating it into the security development lifecycle. As your program develops, we suggest moving from ad hoc models to reproducible assessments. Threat modeling requires resources; be ready to assign team hours to this process. As your organization gets started you should expect to see gains from performing informal STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege) tabletops with the development team. This piece provides guidance for reaching three levels of threat modeling maturity.

Threat Modeling Maturity Model Types 

While many threat modeling frameworks, such as STRIDE or PASTA (Process for Attack Simulation and Threat Analysis) exist, most are written as high-level guides for what to consider in a threat modeling exercise. There are, unfortunately, few references describing how to use these frameworks to rate an organization’s maturity. Admittedly, this is a bit of a “square peg, round hole” problem—these frameworks were never meant to be used for evaluating threat hunting maturity (or advancing it).

We find that the best existing model to adapt for general threat modeling maturity is the OWASP Software Assurance Maturity Model (SAMM). The SAMM is divided thematically into “streams,” each of which covers some component of software assurance. The SAMM is a natural choice for our purposes because it includes a threat assessment stream and evaluation criteria have been made public by OWASP. The roadmap section of the SAMM scorecard provides some maturity guidance that will be used in this piece.

OWASP SAMM Threat Assessment Streams 

The OWASP SAMM Threat Assessment practice is composed of two streams:

  • Application risk profile
  • Threat modeling

While the focus here will be on the threat modeling stream, organizations are encouraged to examine the application risk profile stream as well. It is difficult to adequately threat model when the risks the organization considers acceptable aren’t defined in advance.

READ: Creating an Effective Cyber Threat Intelligence Framework

Threat Assessment Maturity Levels 

The maturity levels defined in OWASP SAMM for the threat assessment practice are as follows, in increasing maturity order:

  • Best-effort identification of high-level threats to the organization and individual projects.
  • Standardization and enterprise-wide analysis of software-related threats within the organization.
  • Proactive improvement of threat coverage throughout the organization.

The maturity levels defined for the threat modeling stream are as follows, again, in increasing maturity order:

  • Perform best-effort, risk-based threat modeling using brainstorming and existing diagrams with simple threat checklists.
  • Standardize threat modeling training, processes and tools to scale across the organization.
  • Continuous optimization and automation of your threat modeling methodology.

In the remainder of this section, we will address action items for moving between maturity levels.

Achieving Threat Modeling Maturity Level 1 

In the starting state, the organization is yet to create any formal threat modeling program but recognizes the need to begin creating such a program.

In maturity level one, only those applications which are defined as “high risk” to the organization receive formal threat modeling. The organization creates a formal threat modeling checklist to standardize the process. The STRIDE framework works well for this checklist because it is easy to remember and high-level enough that it can cover risks from almost any application.

At this maturity level, new architectural and dataflow diagrams are not being generated. Instead, the organization makes use of existing documentation and applies frameworks like STRIDE. The outcomes of threat modeling sessions are captured and stored for later use. At this maturity level, most organizations will codify this in a document that is stored with other program management-related documents.

Threat Modeling Maturity Level 1 - Action Items 

  • Enumerate high-risk applications for which to perform threat modeling.
  • Choose a framework, such as STRIDE, for use in threat modeling.
  • Create a checklist document detailing the minimum activity performed for any application.
  • Choose a method for persisting the results of a threat modeling exercise.

Achieving Threat Modeling Maturity Level 2 

In this state, the organization has already completed the activities at level one and wants to mature to level two. Most organizations today do not fully embrace the activities at this maturity level.

The two key changes in this phase are expanding the scope of which applications receive threat modeling and formalizing the threat modeling process. Action items, including diagramming flaws and mitigations, are discussed below.

Threat Modeling Maturity Level 2 - Action Items 

  • Expand the list of in-scope applications for threat modeling.
  • Create training on threat modeling in the organization.
  • Identify stakeholders within the organization, including architects and security champions, to receive formal threat modeling training.
  • Begin building formal data flow diagrams for applications that do not have them already.
  • For those that have formal diagrams, validate they are correct.
  • Apply the chosen framework (e.g., STRIDE) to the application at the most granular level facilitated by dataflow diagrams.
  • Document mitigations to design flaws and attack vectors enumerated during threat modeling.
  • Monitor for changes to the application (or its use) that would render the existing threat model outdated.
  • Threat modeling artifacts are stored with tools that are integrated into the development process. 

Achieving Threat Modeling Maturity Level 3 

In this state, the organization has a fairly comprehensive threat modeling program and wants to mature to the highest level of threat modeling maturity. Very few organizations achieve this level of maturity. The resources required to mature to this level should only be expended if other streams in the OWASP SAMM are already at or approaching maturity level two.

The key changes in this phase are incorporation of feedback to facilitate improvement, implementation of periodic reviews to existing threat models and automation (where possible).

Threat Modeling Maturity Level 3 - Action Items 

  • Define a formal process to identify common design flaws identified through threat modeling.
  • Use previous findings to inform threat modeling checklists used by the organization.
  • Define a regular interval on which to revisit threat models, optionally targeting intervals based on the risk of the underlying application.
  • Revisit and reevaluate existing threat models for applications.
  • Identify opportunities for automation in the threat modeling process and implement where feasible.

Operationalizing and Maturing Threat Modeling 

Using the steps laid out in this piece, your organization can begin integrating threat modeling activities into its security development lifecycle. Those already performing threat modeling can use these steps to mature their process.

  • For those just beginning: Start small and don’t try to boil the ocean. Like many things, threat modeling follows the 80/20 rule: You’ll get most of the benefit from the low-hanging fruit.
  • For those maturing an existing program: Formal threat modeling diagrams are a logical step in moving from ad hoc use of models like STRIDE to reproducible assessments.
  • Be ready to commit resources: Your development teams are resource constrained. Be ready to chip in with security team hours to generate threat modeling diagrams for some applications.

Threat modeling has obvious benefits, but it can be hard to get a program off the ground. Start small and don’t let ‘perfect’ stand in the way of measurable progress. The largest security gains in any application will come from just performing an informal STRIDE tabletop with the development team.

Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.

Access time-saving tools and helpful guides from our Faculty.

IANS + Artico Search

Our 2024-2025 CISO Compensation and Budget Benchmark Survey is Live!

Get New IANS Blog Content
Delivered to Your Inbox

Please provide a business email.