Forrester Report: Why to automate AppSec now.

The Ultimate Cheat Sheet On Threat Modeling

Security has become a major concern in recent years with hacks becoming bigger and risks becoming greater. Today’s software must be built with the ability to combat and cope with various malicious attacks, and yet, many software developers still might miss a crucial step while creating a secure SDLC (software development lifecycle) process. In order to ensure secure software development, alongside conducting risk management, one of the first steps in your SDLC should be Threat Modeling.

Threat modeling is the process that improves software and network security by identifying and rating the potential threats and vulnerabilities your software may face, so that you can fix security issues before it’s too late. The process is then followed by defining countermeasures which will prevent those same threats and exploits likely to put your system at risk. This allows you to address threats with the appropriate solutions in a logical order, starting with the ones which present the greatest risk. Starting this process early in your software’s development lifecycle is important as identifying and rating all potential threats and weaknesses while understanding your software’s architecture could lead to significant changes in your software.

Identifying assets

The first part of your threat modeling process is identifying the assets needing protection. After all, your assets are what hackers are after and thus the reason threats to your software exist in the first place. Examples of important assets are client databases, software pages, and software availability. By identifying assets, you are completing the first step in securing them.

Creating an architecture overview

The second step in threat modeling is laying out each function of your software, including its architecture, data flow, and technologies. The goal in this step is seeking potential vulnerabilities in your software’s design and implementation.

Decompose the software

In this step you will break down the many elements of your software to gain a detailed understanding of your software’s components. Through this step you will create a security profile for your software, starting with the traditional areas of vulnerability. The security profile will come from identifying your software’s trust boundaries, data flow, entry points, and privileged code. By decomposing your software, you have the chance to familiarize yourself with your software’s components, making this step is important as the more you know about your software, the easier uncovering threats will be.

Identifying trust boundaries threat modeling - The Ultimate Cheat Sheet

Trust boundaries show where trust levels change. Identifying the software’s trust boundaries will help you focus on analyzing the areas of greater concern. Start by identifying the trust boundaries which surround each of the detectable assets in your software – these assets are defined by your software design. For each aspect of your software, consider whether user input of upstream data flows are trusted; and if not, how to determine whether or not the calling code is trusted while considering how it can be authenticated.

Identifying data flow

Trace your software’s data input from entry to exit in order to understand your software’s interaction with external systems and how internal components interact. Identifying data flow is critical as code that is given info from a foreign trust boundary should assume that the data is malicious, and should perform a validation prior to accepting it.

Identifying entry points

Your software’s entry points may also serve as entry points for potential attacks. An entry point might include a front-end web application for HTTP requests – a point intended to be exposed by clients. Other entry points may be internal ones, exposed by subcomponents across your software. These entry points serve as internal communication with other components. It is important to locate each of these entry points and to know what type of input they receive in case an attack manages to get by the entrance of the software and directly attack an internal entry point.

Identifying privileged code

According to Esus, privileged code allows you to give temporary permission to code which would not normally have permission to run, usually to access secure resources in your software. The key with privileged code is ensuring each resource and asset it interacts with is not exposed to potential malicious code.

Documenting the security profile

The final step in decomposing your software is completing your software’s security profile. This is where you will discover and map-out all potential vulnerabilities and threats in your software’s design, implementation, authentication and/or configuration thus creating a security profile. For a great in depth look at how you can successfully create a security profile, check out Microsoft’s chapter on threat modeling here

Rating the threats

At this point in your threat modeling process, you should already have a list of potential vulnerabilities and threats. By rating threats you can prioritize and focus on the treats putting you most at risk. The threat rating process should be influenced by the chance of the threat causing great damage to your software and other potential attacks that could occur. However, you may discover that certain threats, usually ones with a very slim chance of occurring,  might not require any immediate action nor any action at all.  

OWASP recommends the Microsoft threat rating system called DREAD.

DREAD Rating system for potential threats


By using the DREAD threat rating system, you can accurately and easily rate each potential threat. You may also tailor or add additional questions to each category in order to best determine what each threat rating is.  

You can successfully secure your system once you know the threats that are posed to it. Threats to your software will still exist regardless of the countless security measures and actions you take. However completing a threat model is where you can best manage those threats teamwide. Your threat model will become an influential item used by designers to make more secure design choices, by developers who can keep security in mind, and by testers who can base their security testing on the analysis.




The next step is ensuring a secure SDLC process. Click here to learn more. 

Jump to Category