Threat Modeling

Threat Modeling

Threat modeling is an exercise that helps with quantifying threats to understand how attackers (threat actors) may be able to compromise a system and then make the appropriate mitigations to thwart the potential risks posed. Typically, threat modeling is an exercise that takes place before deployment to production systems as part of the design phase but can also be used in the beginning stages of any security testing. Threat modeling will usually include the following activities:

  1. Identifying all assets in a system, creating an architecture overview

  2. Decomposing the system (or device)

  3. Identification of threats

  4. Document all the threats with their respective scenarios, and

  5. Rate each threat by its likelihood as well as impact using a rating system

A framework used to help enumerate and identify threats is STRIDE, which is a mnemonic described in the following table:


Property Violated

Threat Definition





Pretending to be someone or something you are not

Impersonating another user




Modifying data or code

Deleting log files to conceal activity




Claiming to have not performed an action.

I never executed that DROP TABLE in production


Information disclosure


Exposing information to someone not authorized to see it

Hardcoded usernames and passwords in source code


Denial of Service


Deny, limit, or degrade service to users

Exhaust server side infrastructure with requests


Elevation of Privilege


Gain capabilities without proper authorization

Gaining admin privileges

Common risk rating systems used in threat modeling are DREAD, and CVSS but several others are also available. DREAD, another mnemonic, is scored on a scale of 1 to 3 according to each category described below and a final score is the average. 1 is low risk, 2 is medium risk, and 3 is high risk. Often, the scoring scale is modified to fit the need of an organization, such as 0 to 10.








How bad would an attack be?

Can subvert all security controls and get full trust to take over the whole ecosystem.

Could leak sensitive information.

Could leak trivial information.



How easy is it to reproduce the attack?

The attack is always reproducible.

The attack can be reproduced only within a timed window or specific condition.

It's very difficult to reproduce the attack, even with specific information about the vulnerability.



How much work is it to launch the attack?

A novice attacker could execute the exploit.

A skilled attacker could make the attack repeatedly.

Allows a skilled attacker with in- depth knowledge to perform the attack.


Affected users

How many people or users will be impacted by a successful attack?

All users, default configurations, all devices.

Affects some users, some devices, and custom configurations.

Affects a small percentage of users and/or devices through an obscure feature.



How easy is it to discover the threat?

Attack explanation can be easily found in a publication.

Affects a seldom-used feature where an attacker would need to be very creative to discover a malicious use for it.

Is obscure and unlikely an attacker would discover a way to exploit the bug.

Threat models should answer the following four questions:

  • What are we building?

    • Use data flow diagrams (DFD) to assist with modeling components and how they interact locally as well as with external services

    • DFDs should show each process, user, entity, data store, and protocols that connect assets

    • Make use of tools such as Microsoft Threat Modeling Tool 2016, OWASP Threat Dragon, or online diagram software such as or

  • What can go wrong?

    • Leverage STRIDE to help identify and enumerate threats

  • What are we going to do about the issues that can go wrong?

    • DREAD aids with risk scoring and prioritization. The higher the risk, the higher priority the threat should be addressed or mitigated.

  • How well was our analysis?

    • Conduct a retrospective activity to check the overall quality, progress, and future planning.

Threat modeling should be done early, and as often as possible. Threat model owners are best in the hands of the software teams and should considered a living document that is updated as new features are planned.

A great book and also an authoritative reference is "Threat Modeling: Designing for Security".

Additional References

Last updated