# DREAD Risk Assessment Model
## **DREAD Model: A Risk Assessment Framework for Prioritizing Threats**
The **DREAD model** is a **qualitative risk assessment framework** designed to help cybersecurity teams **evaluate and prioritize security threats** based on five key factors: **Damage Potential, Reproducibility, Exploitability, Affected Users, and Discoverability**. It is particularly useful in **threat modeling, penetration testing, and vulnerability management**, providing a systematic way to assess risks and allocate resources accordingly.
Unlike other models that focus on threat categories (e.g., **STRIDE**), **DREAD helps security teams measure and rank threats by their potential impact and likelihood**, enabling better decision-making.
***
## **Breakdown of DREAD Risk Factors**
Each letter in **DREAD** represents a factor that contributes to a threat's risk score. The **higher the cumulative score**, the more critical the threat.
***
### **1. Damage Potential (D) – How Severe is the Impact?**
* **Description:** Measures **the extent of harm** a successful attack could cause to the system, organization, or users. A higher score indicates a **greater risk** to business operations, data integrity, financial stability, or reputation.
* **Common Considerations:**
* Could the attack result in a **full system compromise**?
* Could sensitive **data be stolen or leaked** (e.g., PII, financial records)?
* Would it cause **financial loss** or regulatory violations (e.g., GDPR, HIPAA fines)?
* Would **customers lose trust** in the platform due to the breach?
* **Scoring Examples:**
* **0-3:** Minor inconvenience, no sensitive data loss.
* **4-6:** Some data exposure, partial system downtime.
* **7-10:** Full system compromise, major financial or reputational damage.
***
### **2. Reproducibility (R) – How Easily Can the Attack Be Repeated?**
* **Description:** Assesses how **consistently** an attacker can reproduce the exploit. A **high score** means an attacker can reliably execute the attack without special conditions.
* **Common Considerations:**
* Can the exploit be **executed repeatedly** with minimal effort?
* Does it **require specific conditions** (e.g., user interaction, race conditions)?
* Can the attack be **automated** (e.g., a scriptable exploit)?
* **Scoring Examples:**
* **0-3:** Very difficult to reproduce, requires rare conditions.
* **4-6:** Requires some effort but is repeatable under certain conditions.
* **7-10:** Easily reproducible with little effort or automation.
***
### **3. Exploitability (E) – How Easy is it to Exploit?**
* **Description:** Evaluates the **technical difficulty and resources** required to exploit the vulnerability. A **higher score** indicates that **attackers need fewer skills, tools, or privileges** to exploit the weakness.
* **Common Considerations:**
* Does the attack **require specialized knowledge** or tools?
* Can an attacker **exploit it remotely**, or do they need local access?
* Is the attack **publicly known**, with **readily available exploits**?
* Can it be **exploited by script kiddies**, or does it require a skilled hacker?
* **Scoring Examples:**
* **0-3:** Requires deep technical expertise, custom-built exploits.
* **4-6:** Moderate difficulty, some specialized knowledge needed.
* **7-10:** Exploitable with publicly available tools or scripts.
***
### **4. Affected Users (A) – How Many People Will Be Impacted?**
* **Description:** Measures the **breadth of the impact**, determining how many users, systems, or organizations will be affected if the attack is successful.
* **Common Considerations:**
* Is the issue **limited to a single user** or **organization-wide**?
* Would the exploit impact **a critical system** used by thousands of people?
* Would the attack affect **public-facing services** (e.g., a cloud provider)?
* **Scoring Examples:**
* **0-3:** Affects a few individuals, low impact.
* **4-6:** Affects a subset of users or employees.
* **7-10:** Affects all users/customers, global system failure.
***
### **5. Discoverability (D) – How Easy is it to Find the Vulnerability?**
* **Description:** Estimates how likely it is that an attacker can **discover the vulnerability** through **manual testing, automated scanning, or leaked information**.
* **Common Considerations:**
* Is the vulnerability **obvious** (e.g., default credentials, directory listing enabled)?
* Can it be found using **automated scanners** (e.g., Nessus, Burp Suite)?
* Is the issue **publicly documented** or disclosed in forums?
* Would it require **deep code review or black-box testing** to identify?
* **Scoring Examples:**
* **0-3:** Requires deep manual analysis, low likelihood of discovery.
* **4-6:** Possible to find with some effort, but not obvious.
* **7-10:** Easily discoverable via automated tools or common techniques.
***
## **Using the DREAD Model for Risk Scoring**
Each factor is scored on a scale (typically **0-10**), and the final risk score is calculated as:
$$
DREAD Score=
\frac{D + R + E + A + D}{5}
$$
* **Low Risk:** **0-3**
* **Medium Risk:** **4-6**
* **High Risk:** **7-10**
The higher the score, the **more urgent** the threat is, requiring immediate attention and remediation.
***
## **DREAD in Practice: Example Scenarios**
### **Example 1: SQL Injection on a Public Web Application**
| Factor | Score | Reasoning |
| -------------------- | ------------------- | -------------------------------------------------------- |
| **Damage Potential** | **9** | Can expose user credentials and sensitive data. |
| **Reproducibility** | **9** | Easily repeatable using automated SQL injection tools. |
| **Exploitability** | **8** | Well-documented attack method with public exploits. |
| **Affected Users** | **7** | Depends on database exposure, but potentially all users. |
| **Discoverability** | **9** | Can be found with automated scanners like sqlmap. |
| **Total Score** | **8.4 (High Risk)** | Requires urgent mitigation. |
***
### **Example 2: Local Privilege Escalation in a Desktop Application**
| Factor | Score | Reasoning |
| -------------------- | ------------------- | ---------------------------------------------------------- |
| **Damage Potential** | **7** | Can allow an attacker to gain admin access on one machine. |
| **Reproducibility** | **6** | Some conditions required, but repeatable. |
| **Exploitability** | **5** | Requires some knowledge but has PoC exploits. |
| **Affected Users** | **4** | Limited to users on a specific OS/system. |
| **Discoverability** | **3** | Requires deep analysis, not easily found by scanning. |
| **Total Score** | **5 (Medium Risk)** | Should be patched but is not an immediate priority. |
***
## **DREAD vs. Other Risk Models**
* **DREAD vs. STRIDE:** STRIDE classifies threats based on type (e.g., spoofing, tampering), while DREAD **scores risks** to prioritize mitigation.
* **DREAD vs. CVSS:** CVSS (Common Vulnerability Scoring System) provides a **standardized risk score**, whereas DREAD offers a **flexible and customizable approach**.
* **DREAD vs. FAIR:** FAIR (Factor Analysis of Information Risk) focuses on **quantitative risk analysis**, while DREAD provides **qualitative scoring** for immediate prioritization.
***
## **Conclusion**
The **DREAD model** is a powerful tool for **evaluating, prioritizing, and managing security threats**. By systematically assessing **damage, reproducibility, exploitability, affected users, and discoverability**, security teams can allocate resources effectively, address critical vulnerabilities first, and enhance overall **cyber resilience**.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://viceintelpro.gitbook.io/viceintelpro/security-concepts/risk-assessment-models/dread-risk-assessment-model.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.