Threat modeling is a technique and tabletop exercise that can be used to identify potential threats and risks that affect a network, application, asset, etc. The goal of a threat model is to find these risks, threats and ultimately, vulnerabilities early on in the Software Development Lifecycle (SDLC) to prevent devastating security incidents and reduce the costs of fixing an issue in production.

Preface

Finding vulnerabilities, bugs, issues, etc. in an asset in a production environment can be costly. From re-designing, re-testing (configuring the test environment) and change control activities (approvals), it can also be challenging to implement a new change or update quick. However, threat modeling should be treated differently than penetration tests, SAST or DAST activities because while those tools are effective, threat modeling should occur before significant development has been done to avoid costly changes. The goal is to not inundate the teams with additional work and auditing, but to drive the groups to work together and ‘think like a hacker,’ making this activity a great teamworking exercise.

Where Does a Threat Model Fit in the SDLC?

The Software Development Lifecycle (SDLC) typically contains 6 phases and can also be tailored by an organization to better fit their needs. The standard baseline is as follows:

1. Planning – Review of Project Plan such as, Initiatives, Resources & Timeline.
2. Requirements – Technical Requirements are drafted and initial round reviewed. However, requirements can change along the way.
3. Design – Design of the Application, System, Architecture is drafted. However, design can change along the way.
4. Development – Coding, Implementation and Code Tests, such as SAST, SCA.
5. Test – Testing such as a Web penetration test.
6. Release – Approval to move into Production and continuous monitoring such as DAST.

Threat modeling occurs at the bottom of the design phase where there are requirements formed and architecture drawings have been drafted, however, may not be complete if using agile.

Steps for a Successful Threat Model

Step One

Get an overall understanding of the application or system being threat modeled. The following items can be input into the process: Data Flows, Schemas, Diagrams, Requirements, Design Documentation, Baseline Standards. If these items do not exist, the discussion will not be about threats but a lack of understanding in how the system works. However, this would not be a good use of everyone’s time, only indicate a lack of awareness on the design.

Step Two

Step One has allowed the team to understand the application or system and now the team will begin a whiteboard or tabletop exercise to identify threats. Firstly, to be able to organize and frame the discussion a methodology is recommended. There are many to choose from but the most prevalent one is the STRIDE method. It has been around since 1999 and stands the test of time. It was also developed by two Microsoft security researchers, Praerit Garg and Loren Kohnfelder. STRIDE also provides the mnemonic for six security risk categories:

Threat	Definition	Example
Spoofing	Impersonation	Email from a source that appears to be legitimate but is not.
Tampering	Modification of data, injection	Injecting code into a form, altering data, installing a virus
Repudiation	Denial of the truth or validity of something	insufficient logging so logins cannot be verified
Information Disclosure	Exposing information to someone not authorized to view it	Exposing credit card information, user information due to a misconfiguration
Denial of Service	Denying or degrading services to a user(s)	Crashing websites such as a botnet attack
Elevation of Privilege	Gaining capabilities without authorization	Elevating a standard user to admin without approval

STRIDE is very versatile and can also work for cloud environments, system architectures, IoT, etc. The purpose of using a methodology is to organize ideas and discuss + prioritize threats but it can change based on your particular asset being reviewed.

Step Three

Finally, the step is to define the impact and probability of each threat. Now that we have a list of threats, what do with do with that data? There are many methods in calculating risk but IANS recommends the DREAD mnemonic. DREAD also evaluates each vulnerability using a mathematical formula to obtain the associated risk. Each vulnerability gets a score from 1-10 for the items below.

Damage	How bad would this attack be?
Reproducibility	How easy is it to reproduce this? Think, Repeatability.
Exploitability	How easy is it to launch the attack?
Affected Users	Who will it affect? How many users?
Discoverability	How easy is it for someone to discover this vulnerability? Can it be scanned easily?

Finally, that’s all! When put into practice a few times, threat modeling is not too complex and the process can be tailored to fit any industry.

Resources

Application Security

Sample PenTest Rules of Engagement

Common Threats

OWASP Top 10

About

About