​Update (Spring 2023): v2.0 of the template released, along with the recording of a workshop that includes a full demo of how to use this template.

Introduction: What is Threat Modeling

A structured and repeatable process to identify threats and mitigate them against valuable assets in a system. We cannot build secure systems until we understand the applicable threats to our applications/ systems/platforms/infrastructure/services/APIs etc. Threat Modeling involves (i) visually modeling a system (ii) identifying potential threats (iii) validating and/or designing security controls to mitigate risk(s).

Threat Modeling versus Threat Intelligence

While both Threat Modeling (TM) and Threat Intelligence (TI) focus on identifying threats in order to act on them or mitigate them, Threat Modeling aligns well with the Security architecture/design portion of Secure Development Lifecycle, whereas Threat Intelligence aligns well with security operations. Threat Modeling is relevant to identifying threats in a particular system/application/platform/service that we are building before that system is deployed in production, whereas Threat Intelligence is relevant to a comprehensive list of Threats to a whole organization with reference to systems that are already in production/non-prod/pre-prod/laptops/desktops, etc.

Threat Modeling alignment to NIST CSF

Both Threat Modeling (TM) and Threat Intelligence (TI) maps into NIST CSF Identify (ID) → Risk Assessment (ID.RA) category

A Simple, Six-Step Approach to Threat Modeling

The following describes a simple six-step approach to perform threat modeling:

1. Create an architecture diagram of the application/system by:
   1. depicting each architectural component as one of the four threat modeling elements. Any architectural component which is not an actor/data flow/data store would be a process from the threat modeling perspective.
   2. assign a number to each architectural component for each reference in later steps.
2. List down each architectural component matching the assigned numbers or identifiers in the diagram (eg. as rows in a spreadsheet) along with mapping to the corresponding threat modeling element those components fall into. 
3. For each such architectural component, duplicate the row as many times as there are applicable threats based on the STRIDE applicability matrix and assign an applicable threat for that component in each row. For example, for an actor, there would be two rows (one for Spoofing threat and second row for Repudiation threat as there are two applicable threats as per STRIDE applicability matrix. Similarly, there would be four rows for a database, as there are four applicable threats for a data store).
4. Think about how such a threat could make a contact or exploit a vulnerability in the component and manifest into a real risk to the application/system that is being threat modeled. Write down or explain the threat description in a simple sentence or two
5. Think about if the threat is real or not and how a set of security controls (one or many) that are already in place or going to be implemented could mitigate the potential risks. Propose such mitigation plan in a simple sentence or two
6. Identify the appropriate security control(s) from NIST CSF. Each such security control should be placed in the next column on the same row. Note that there could be many-to-many relationships between potential threats and possible mitigation controls. (one security control may mitigate multiple threats and one threat may need multiple controls for risk mitigation).

Let's take a simple internet facing web application architecture to walk through the six (6) steps described above.

Step 1: Create an architecture diagram and label the artifacts

Step 2: List down each architectural component

Step 3: Identify and assign potential threats from STRIDE applicability matrix

Step 4: Describe threat description

‍

Step 5: Propose risk mitigation plan

Step 6: Identify appropriate security controls from NIST CSF

For full threat model, refer to “Threat Model for 2-tier web app” worksheet at: 

🔗 Template: Creating a Manual Threat Model in Six Steps (by Shankar Chebrolu) v2.0

Architecture diagrams are on the first worksheet “Architecture diagrams” for additional reference.

Manual Threat Modeling Tool Using a Spreadsheet (Template)

The template for creating a threat model manually in six steps using a spreadsheet is made available at the link below. The template could be customized further to make it work with any security standard or framework instead of NIST CSF or with an organization's internal security standard.

🔗 Template: Creating a Manual Threat Model in Six Steps (by Shankar Chebrolu) v2.0

References

1. Microsoft Security Development Lifecycle  
2. Introduction to Microsoft SDL Threat Modeling
3. Threat Modeling - Designing for Security
4. Securing Systems - Applied Security Architecture and Threat Models

Appendix 1: Primer to STRIDE framework

Threat Classifications

There are six classifications of Threats dubbed as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) as described below. The STRIDE approach to threat modeling was invented in 1999. 

Threat Modeling Elements

There are four elements used in Threat Modeling:

1. Actor - Users (typically human users, but don't need to be. It could be clients like browsers or devices with IP address or physical address)
2. Data Store - Databases, File systems, LDAP, Cookies, Memory-Cache
3. Data Flow - HTTPS, IPSEC, RPC
4. Process (runs code) - Web application/service, OS process, VM/Host/Server

STRIDE Applicability to TM Elements

Not all the threats apply to every element in the architecture diagram. Matrix of the applicability of threats to actors is shown in the table below:

Appendix 2: Sample Threat Models

SaaS Application (Public Cloud Hosted)

Refer “Threat Model for SaaS application” worksheet

🔗 Template: Creating a Manual Threat Model in Six Steps (by Shankar Chebrolu) v2.0 

​