News About John X. Wang

What Every Engineer Should Know About DREAD and Penetration Testing

  • Nov 30, 2019 |

    DREAD as a risk assessment model

    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, however, 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 CRC Press News is specially focused on the DREAD methodology.

    Quantitative vs. Qualitative Risk Analysis

    Quantitative risk analysis

    Quantitative risk analysis is about assigning monetary values to risk components. It’s composed of:

    1. Assessing value of the asset (AV)
    2. II. Calculating single loss expectancy (SLE),

    SLE = AV x EF. EF is exposure factor (expressed as percentage value)

    1. Calculating annualized loss expectancy (ALE),

    where ALE = SLE x ARO. ARO is annual rate of occurrence.

    The countermeasure should not cost annually more than ALE. This is basically how cost/benefit analysis works.

    Quantitative risk analysis

    Qualitative risk analysis is opinion based. It uses rating values to evaluate the risk level. The DREAD model can be used to perform qualitative risk analysis.

    Qualitative Risk Analysis with the DREAD Model

    DREAD is part of a system for risk-assessing computer security threats. It provides a mnemonic for risk rating security threats using five categories.

    The categories are:

    • Damage – how bad would an attack be?
    • Reproducibility – how easy is it to reproduce the attack?
    • Exploitability – how much work is it to launch the attack?
    • Affected users – how many people will be impacted?
    • Discoverability – how easy is it to discover the threat?

    The DREAD name comes from the initials of the five categories listed when it was initially proposed for threat modeling.

    When a given threat is assessed using DREAD, each category is given a rating from 1 to 10. The sum of all ratings for a given issue can be used to prioritize among different issues.

    The threat is rated by answering the aforementioned questions and assigning rating values for every item (high, medium, low). The rating values represent the severity and are expressed as numbers (3-high, 2-medium, 1-low).

    The risk rating is obtained by adding rating values for all items and comparing the results with the following table:

    Risk rating



    12 – 15


    8 -11


    5 – 7

    Case Analysis with the DREAD Model

    An exemplary vulnerability in web applications is provided to better understand how DREAD works in practice. Please keep in mind, that DREAD is not limited to web application vulnerabilities.

    Cross-site request forgery in the admin panel allows us to add a new user and delete an existing user or all users. Let’s analyze the ratings for the items in the DREAD model.



    Damage potential






    Affected users




    Let’s add all ratings to get the risk rating. The sum is 13 (risk rating: high).


    • The admin has to visit the attacker’s website so that the vulnerability is exploited. That’s why the reproducibility is medium.
    • The attacker can delete all users, making the system unavailable for them. Thus the rating for affected users is high.
    • Deleting all users doesn’t delete all data in the system. That’s why the impact on integrity is partial. Finally, there is no impact on the confidentiality of the system, provided that added user doesn’t have read permissions on default. Thus the rating for damage potential is medium.
    • The vulnerability can be easily discovered (no CSRF token, no authorization password) and exploited. That’s why the ratings for discoverability and exploitability are high.

    Why Penetration Testers Should care?

    Assume that an engineer 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 the engineer is in a meeting in front of the client explaining the issues (client not being technical) couldn’t comprehend the severity of bugs.
    • The engineer had no solid ground apart from saying that these bugs are in OWASP Top 10.
    • The peer engineers argued either the issues are S1, S2 , S3 (S1 being most severe)
      • the engineerargued it to be S1,
      • others disagreed.
    • The issue could have solved had the engineer done Application Threat Modeling using DREAD and STRIDE.
      • the engineer could have said: “I calculated the risk/severity using DREAD”; 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;
      • however, 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.


    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.


    • 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 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 the engineer find a vulnerability and classify it according to STRIDE, the peer engineer will get less argued about the classification.

    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.


    • 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.


    • 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


    • 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.


    • While we can mitigate the risk of an attack, we can never wholly eliminate risk from any complex application.
    • The truth in the world of security is that we recognize the nearness of threats and we deal with our risks.
    • Threat analysis enables us to examine and impart security throughout our work.
    • In our threat analysis, we have:
      • identified sensitive system assets,
      • identified ways that an attacker could compromise the system and gain access to the sensitive assets, and,
      • prioritized these threats by categorizing them as “High”, “Medium”, or “Low” risk.
    • Mitigating Threats: your web design should mitigate against all the threats that your model exposes.
      • However, in some cases, mitigation might not be practical.
        • For example, consider an attack that potentially affects very few users and is unlikely to result in loss of data or system usability.
        • If mitigating such a threat requires several months of additional effort, you might reasonably choose to spend additional time testing the driver instead.
        • Nevertheless, remember that eventually a malicious user is likely to find the vulnerability and mount an attack, and then the driver will require a patch for the problem.
    See More
    Business & Management, Computer Game Development, Computer Science & Engineering, Engineering - Electrical, Engineering - General, Engineering - Industrial & Manufacturing, Homeland Security, Information Technology, Web, Web2