DREAD Threat Modeling Methodology

by | Mar 9, 2023

Share article:
dread threat modeling

In our hyper-connected world, security breaches, and incidents are a certainty. According to a report from Statista, the cost of cybercrime committed globally is expected to rise from $8.44 trillion in 2022 to $23.84 trillion by 2027. 

Statista’s report expects the cost of cybercrime committed globally to rise from $8.4 trillion in 2022 to $23.84 trillion by 2027. In fact, Cyber attackers do 86% of cyberattacks for financial gain, and “state espionage” is a close second.

Although there are several strategies to address and prevent cyber attacks, one approach that can be used to gauge and reduce cyber attacks is threat modeling, among several other strategies. The foundation when “shifting left” in a DevSecOps environment is the threat modeling approach, as it helps to find vulnerabilities and threats much earlier in the software development lifecycle. This, in turn, saves the organization’s reputation and reduces monetary and timely losses. While there are several threat modeling approaches, such as STRIDE, PASTA, VAST, STRIKE, and more, we will be discussing the DREAD threat modeling approach in this post.

What is the DREAD Threat Modeling approach?

Microsoft developed the DREAD threat modeling approach to detect and prioritize threats so that serious threats can be mitigated first. It was first published in ‘Writing Secure Code’ 2nd edition by David LeBlanc and Michael Howard in 2002. Though Microsoft stopped using the DREAD threat modeling approach, smaller organizations, Fortune 500 companies, and the military continue to use it.

DREAD stands for 

D – Damage potential

R – Reproducibility

E – Exploitability

A – Affected users

D – Discoverability

We rank these factors on a scale from 0-10 and calculate the sum of these values. If the resulting value is higher, the risk of a potential attack on the organization is greater and we need to employ mitigation strategies immediately.

Let us explore these factors in greater detail:

Expanding the acronyms in DREAD Threat Model

Damage potential:

The organization measures the amount of damage that a threat actor can cause as the damage potential on the following scale:

0 – Indicates no damage caused to the organization

5 – Information disclosure said to have occurred

8 – Non-sensitive user data has been compromised

9 – Non-sensitive administrative data has been compromised

10 – The entire information system has been destructed. All data and applications are inaccessible

Reproducibility:

Reproducibility indicates if it’s simple to replicate an attack. These are again plotted on a scale of 0 – 10.

0 – Difficult to replicate the attack

5 – Complex to replicate the attack

7.5 – Easy to replicate the attack

10 – Very easy to replicate the attack

Exploitability:

Different vulnerabilities in an organization can be exploited by using different tools and skills, as indicated by their ratings. They are rated as follows:

2.5 – Indicates that advanced programming and networking skills needed to exploit the vulnerability

5 – Available attack tools  needed to exploit the vulnerability

9 – Web application proxies are needed to exploit the vulnerability

10 – Indicates the requirement of a web browser  needed to exploit the vulnerability

Affected Users:

Calculate the number of users who will be affected by an attack to determine the potential impact of the attack. This is again rated on a scale of 1 – 10.

0 –  no users  affected

2.5 – Indicates chances of fewer individual users  affected

6 –  Few users affected

8 – Administrative users affected

10 – All users affected

Discoverability:

On a scale of 1 – 10, this factor rates the discoverability of a vulnerability.

0 – Indicates it’s hard to discover the vulnerability

5 – HTTP requests can uncover the vulnerability

8 – Vulnerability  found in the public domain

10 – Vulnerability found in  web address bar or form

Read more about other Threat Modeling Methodologies

Also Read, Threat Modeling VS Pen testing

 

Let’s assume an organization wants to identify and prioritize potential threats to their online banking platform using the DREAD model. Here’s an example of how the factors in the DREAD model could be applied:

  1. Damage potential: The organization assesses the potential damage caused by a threat based on the following scale:

   – 0: No damage caused

   – 5: Information disclosure

   – 8: Non-sensitive user data compromise

   – 9: Non-sensitive administrative data compromise

   – 10: Complete system destruction, rendering data and applications inaccessible

 

  1. Reproducibility: Evaluating how easily an attack can be replicated. Ratings might look like this:

   – 0: Difficult to replicate

   – 5: Complex to replicate

   – 7.5: Easy to replicate

   – 10: Very easy to replicate

 

  1. Exploitability: Considering the tools and skills required for exploitation:

   – 2.5: Advanced programming and networking skills needed

   – 5: Available attack tools needed

   – 9: Web application proxies required

   – 10: Only a web browser needed

 

  1. Affected users: Calculating the potential impact of an attack by determining the number of users affected:

   – 0: No users affected

   – 2.5: Fewer individual users affected

   – 6: Few users affected

   – 8: Administrative users affected

   – 10: All users affected

 

  1. Discoverability: Assessing how easily a vulnerability can be discovered:

   – 0: Hard to discover

   – 5: Discoverable through HTTP requests

   – 8: Vulnerability found in the public domain

   – 10: Vulnerability found in the web address bar or form

 

By assigning a numerical value to each factor and calculating the average, the organization can prioritize the identified threats based on the resulting risk value which allows them to focus their mitigation efforts on addressing the most critical threats that pose a highest risk to their online banking system.

 

Keep in mind that this is just an example of applying the DREAD threat modeling approach to a specific scenario. The actual assessment process may involve more extensive analysis, consideration of additional factors, and customization based on the organization’s unique requirements and risk profile.

Summary

After scaling each factor to a numerical value, the sum of the values calculated shows the risk value to the organization if an attack occurs. The organization can then take steps to mitigate the risks and reduce the possibility of cyber attacks. We have seen the DREAD threat modeling approach in this post. Stay tuned for further posts that seek to bolster your knowledge of threat modeling and DevSecOps!

Interested in upskilling in Threat Modeling?

Get trained through the Certified Threat Modeling Professional (CTMP) course offered by Practical DevSecOps.

This vendor-neutral course provides you with hands-on training in important threat modeling concepts such as Security requirements in Agile environments, Agile Threat modeling, Threat Modeling as Code, Secure Design Principles to help you ensure security in the design phase, and other core threat modeling concepts and tools.

References:
Satoricacyber: Threat Modeling with Microsoft DREAD

Haider: Stride Threat Modeling VS DREAD Threat Modeling

 

Share article:

Interested in Upskilling in DevSecOps?

Practical DevSecOps offers excellent security courses with hands-on training through browser-based labs, 24/7 instructor support, and the best learning resources.

Begin Today to Transform Your Career!

Meet The Author

Yuga

Yuga

Muhammed Yuga Nugraha is the creator of awesome lists which is focused on security for modern technologies, such as Docker and CI/CD. He is a thriving DevSecOps engineer who is focused on the research division exploring multiple topics including DevSecOps, Cloud Security, Cloud Native Security ,Container Orchestration, IaC, CI/CD and Supply Chain Security.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

You May Also Like:

Tackling DevSecOps Adoption Challenges
Tackling DevSecOps Adoption Challenges

Adoption challenges are critical to addressing DevSecOps because they define DevSecOps in terms of how security practices are put in DevOps from the initiation to deployment. The aim, in this case, is to fill the obstacle that exists between rapid cycles of released...