Application Threat Modeling using DREAD and STRIDE

Introduction

Application Threat Modeling using DREAD and STRIDE is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, classify, rate, compare and prioritize the security risks associated with an application.

Application Threat modeling should be considered separate from Risk Assessment, although similar but Application Threat Modeling is more of a calculated approach. Inducing Application Threat Modeling into SDLC process has its advantages for the security of the entire project. Most importantly when performing security assessments following the threat modeling approach gives the reviewer a comprehensive overview of the Application.

This post is specially focused on the DREAD and STRIDE methodology.

Why Penetration Testers Should care?

Good question, let me answer this by a real life example, last year I found some serious access control issues in a Web Application. The issues were such that one user could perform actions on behalf of other users. Now I am in a meeting infront of the client explaining the issues (client not being technical) couldn’t comprehend the severity of bugs. I had no solid ground apart from saying that these bugs are in OWASP Top 10. We argued either the issues are S1, S2 , S3 (S1 being most severe) I argued it to be S1, they disagreed. The issue could have solved had I done Application Threat Modeling using DREAD and STRIDE. I could have said I calculated the risk/severity using DREAD (Explained below), a framework designed by Microsoft, that’s a solid foundation on which hardly anyone argues, specially management people, they love Standards , Frameworks and rightly so!

If severity of vulnerabilities is measured just by the “Name” of the vulnerability it has the potential to exaggerate or underrate the risk it pose. For example, if a vulnerability allows an attacker to identify usernames in an Application, in it self its not a major risk, but lets say it is a banking application and they lockout users after 5 wrong password tries, attacker could just write a script to spray legitimate username wrong password combination on the application and it would block all the users to access banking services or any other high traffic service. Now that is a Major risk and its accurate severity can only be calculated if we apply a methodological approach like DREAD (explained below)

Procedure

To perform Application Threat Risk Modeling use  OWASP testing framework to identify, STRIDE methodology to Classify and DREAD methodology to rate, compare and prioritize risks, based on severity. Following are the steps involved in application Application Risk Threat Modeling:

Decompose the application

The first step of threat modeling is to understand how it interacts with internal and external entities, Identify entry points, privilege boundaries, access control matrix, and technology stacks being used. This step in OWASP testing methodology is called information gathering phase where you gather maximum information about the target. Maybe I will write another post to explain the process and tools for application decomposition but it is out of the scope of this post.

Identify

Implementation of OWASP testing framework results in identifying vulnerabilities in application, this is commonly known as Application Penetration testing.In  Penetration testing attackers use tools and techniques to find maximum vulnerabilities in application.

Classify Threats

After the vulnerabilities are identified, STRIDE methodology introduced by Microsoft is used to classify these vulnerabilities. During security engagements it is vital to backup your claims (about vulnerabilities) with a solid foundation like a framework or standard. For example if you find a vulnerability and classify it according to STRIDE, ill get less argued about the classification.




STRIDE stands for

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege.

Following Table explains STRIDE

Rate, Compare and Prioritize Threats

DREAD methodology is used to rate, compare and prioritize the severity of risk presented by each threat that is classified using STRIDE.

DREAD Risk = (Damage + Reproduciblity + Exploitability + Affected Users + Discoverability) / 5. Calculation always produces a number between 10. Higher the number means more serious the risk is.

Following is a customized mathematical approach to implement DREAD methodology:-

Damage Potential

If a threat exploit occurs, how much damage will be caused?

• 0 = Nothing
• 5 = Information disclosure that could be used in combination with other vulnerabilities
• 8 = Individual/employer non sensitive user data is compromised.
• 9 = Administrative non sensitive data is compromised.
• 10 = Complete system or data destruction.
• 10 = Application unavailability.

Reproducible

How easy is it to reproduce the threat exploit?

• 0 = Very hard or impossible, even for administrators of the application.
• 5 = Complex steps are required for authorized user.
• 7.5 = Easy steps for Authenticated user
• 10 = Just a web browser and the address bar is sufficient, without authentication.

Exploit-ability

What is needed to exploit this threat?

• 2.5 = Advanced programming and networking knowledge, with custom or advanced attack tools.
• 5 = Exploit exits in public, using available attack tools.
• 9 = A Web Application Proxy tool
• 10 = Just a web browser

Affected Users

How many users will be affected?

• 0 = None
• 2.5 individual/employer that is already compromised.
• 6 = some users of individual or employer privileges, but not all.
• 8 = Administrative users
• 10 = All users

Discover-ability

· How easy is it to discover this threat?

• 0 = Very hard requires source code or administrative access.
• 5 = Can figure it out by monitoring and manipulating HTTP requests
• 8 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
• 10 = the information is visible in the web browser address bar or in a form.

DREAD methodology can be customized to cater the needs of your application, during consultancy engagements it should be approved from the client before starting the security assessment so that after you perform the analysis the results produced by DREAD couldn’t be challenged.

If you have any suggestions about Application Threat Modeling using DREAD and STRIDE let me know I will cover that in the article with acknowledgment.