Rating threats with DREAD

The bottom line: DREAD ranks a set of threats by scoring five factors and adding them up. It’s a fine way to force a structured argument about which threat is worse, and a poor calculator. The numbers look precise and aren’t, and Microsoft, which wrote DREAD down in the first place, quietly stopped using it. Reach for it to rank threats against each other inside one system and to make people defend their reasoning out loud, not as an absolute severity you compare across projects or pipe into a dashboard.

Fourth post in the threat modeling series. STRIDE and LINDDUN find threats by walking a data flow diagram and enumerating what can go wrong. Neither tells you what to fix first, which is the gap DREAD fills: you’ve found thirty threats, have budget for six this quarter, and DREAD is one way to pick the six.

Where DREAD fits

Same system as the STRIDE walkthrough: a telematics backend with TCUs talking to an ingestion API over mutual TLS, a database of telemetry and vehicle records, and an operator dashboard, with the trust boundary at the internet edge. STRIDE gave us the threats against that diagram. DREAD is the step after, asking for each one how bad and how likely, and producing a number you can sort on.

One disambiguation, because “risk score” gets overloaded. DREAD is not CVSS, and it’s not the risk method in ISO/SAE 21434. CVSS rates the severity of a specific vulnerability and is maintained by an external body. The 21434 method is automotive-specific and splits impact into safety, financial, operational, and privacy. DREAD predates both and is generic. Don’t directly compare their scores against each other; they aren’t the same, and the differences are most of the point here.

The five factors

DREAD comes from Writing Secure Code by Michael Howard and David LeBlanc. LeBlanc later wrote that it grew out of Microsoft’s Visual Studio security push, the company’s first. The five factors, each scored on some numeric scale:

• Damage. How bad the outcome is. An operator reading another fleet’s location history is bad; a flaw that sends an unlock or immobilize command to a vehicle is worse, because the harm is physical.
• Reproducibility. How reliably the attack fires once triggered. A race condition that hits one time in fifty scores low; a deterministic missing-authorization check scores high. (LeBlanc glosses the R as “reliability,” which hints at how loosely the scale was defined.)
• Exploitability. How much work it takes to launch. Anonymous and scriptable is the worst case; needing a valid login, a specific config, or an extracted device key is better.
• Affected users. How many get hit, from one fleet to every fleet on the platform.
• Discoverability. How likely an attacker is to find it. The controversial one: LeBlanc’s advice is to take no comfort when it’s low, but get alarmed when it’s high.

Damage, reproducibility, and affected users describe how bad the outcome is and stay roughly fixed for a given bug. Exploitability and discoverability describe the attacker’s situation and shift between deployments. LeBlanc made exactly this split when he revisited DREAD, treating the first group as severity and the second two as a priority boost.

DREAD adds all five anyway, and the next section is mostly about what that breaks.

From five scores to one number

Two scales are in common use and they disagree. Writing Secure Code rates each factor 1 to 10, sums, and divides by five for a single 1-to-10 number; Microsoft’s driver-security docs still describe it this way. Microsoft’s 2003 guide Improving Web Application Security: Threats and Countermeasures (Chapter 3) rates each High, Medium, or Low as 3, 2, 1 and sums to between 5 and 15, bucketed 12 to 15 High, 8 to 11 Medium, 5 to 7 Low. Past those two, every team writes its own anchors for what a 3 or a 7 means, and the published rubrics don’t agree. A scale that isn’t pinned down produces numbers that look comparable but came off different rulers.

An example on the back office

Here’s an anchored rubric for the back office, adapted from the OpenStack Security Group’s advisory-scoring rubric. Writing the anchors down is what makes two people score the same threat the same way. Copy it, reword it for your system, and you’ve at least defined your ruler.

Now three threats from the STRIDE pass, scored against it. The numbers are illustrative, meant to show the mechanics rather than stand in for measured findings. I’m pinning Discoverability to 10 for reasons explained below, and I’ll show what happens if you don’t.

None of these is hypothetical. T1 is what Sam Curry’s group found in SiriusXM’s Connected Vehicle Services in late 2022: the platform authorized commands and returned owner data keyed on a vehicle’s VIN, which is visible through the windshield, so the VIN alone was enough to locate a car and pull the owner’s profile. The same research found a fleet-management back office, Spireon, with administrative access to send unlock, start, and disable-starter commands to an estimated 15.5 million vehicles. That’s T2: this diagram with the safety latches off. T3 echoes an OpenStack advisory (OSSA 2014-038), where listing instances by IP on a busy deployment hung the network service. There it took an authenticated user; an unauthenticated variant is the obvious worry for a public ingestion endpoint.

Ranked by DREAD score the order is T2, T1, T3, which roughly matches intuition: remote physical control worst, mass data exposure next, recoverable outage last. So far it looks like it works.

Where the number lies

Watch what the averaging does. LeBlanc named the core defect long ago: a nuisance with damage 1 and everything else 10 (browser pop-ups) averages to the same score as a flaw with discoverability 1 and everything else 10 (hard to find, but it ends the world). He called the result an obvious malfunction. Summing independent axes lets a high score on a trivial dimension cancel a low score on the one you care about. Damage and discoverability aren’t the same kind of thing, and adding them pretends they are.

The discoverability axis makes it worse. Score it at face value instead of pinning it. Nobody has published the command-authorization flaw, so T2’s naive discoverability is maybe a 3, and T2 becomes 10 + 7 + 4 + 9 + 3 = 33, or 6.6. T1 and T3 are both externally observable, so their discoverability stays high, say an 8 each: T1 lands at (6 + 9 + 6 + 8 + 8) / 5 = 7.4 and T3 at (5 + 8 + 7 + 6 + 8) / 5 = 6.8. The threat that can remotely control a moving vehicle now ranks last, below a temporary outage, purely because its flaw is still secret. The model rewards you for not having been caught, which is security through obscurity dressed up as a risk score.

A third problem the back office makes obvious: T2’s damage is a 10, and so is “full backend compromise,” and so is “all telemetry destroyed.” One 0-to-10 number can’t say that one of those puts someone in a hospital and the others don’t. A generic damage scale has no slot for physical safety, which is why ISO/SAE 21434 splits impact into safety, financial, operational, and privacy and lets a safety hit dominate the rest. (The 21434 method gets its own post.)

Adam Shostack, who worked on Microsoft’s SDL, named the deeper issue in his 2008 retrospective: DREAD got bolted on because the process obviously needed a risk step, and it attaches numbers to factors without defining their scales, which makes a judgment call look like the output of an algorithm. That’s the failure under all the others. The arithmetic launders a guess into a decimal.

Making it less wrong, and when to bother

The fixes that survive contact with reality all re-introduce judgment on purpose.

• Pin or drop discoverability. OpenStack sets it to a constant 10 for every issue, even privately reported ones, on the logic that if you know about a flaw, someone else probably does too. Other teams cut the axis entirely and score the four remaining factors.
• Calibrate against past findings. Score a handful of threats the team already agrees on and tune your anchors until the model reproduces that ordering. A commenter on LeBlanc’s post made the same point from the code-review side: DREAD scores mean the most relative to other issues you’ve looked at, and scoring one in a vacuum doesn’t work.
• Use coarse buckets. LeBlanc’s own fix was High, Medium, Low. Nobody can defend a discoverability of 6 against a 7.
• Keep scores inside one model. A 7.8 on the back office and a 7.8 on someone else’s payment service are not the same risk.

With those guardrails DREAD still earns its place. It works for:

• a small team with no tooling that needs a shared way to argue about what to fix first;
• getting non-experts to reason about risk, where five named factors give them a checklist for the conversation (Shostack’s point: a method engineers will use beats a rigorous one they won’t);
• ranking threats inside one calibrated model;
• teaching, as a clean example of how scoring is meant to work before you show where it fails.

What to use instead

To rate a specific, known vulnerability, use CVSS. The current version is 4.0, published by FIRST on 1 November 2023; it defines its scales in detail and added safety-impact metrics for OT, ICS, and IoT, which matters if your telematics work touches the vehicle side. It isn’t a cure: FIRST says a Base score is technical severity, not remediation priority, and people misuse it as one anyway, which is why pairing it with exploit-likelihood data like EPSS is the common correction. Its edge over DREAD is shared, written-down rulers, not an escape from subjectivity. For automotive, the TARA process in ISO/SAE 21434:2021 is built for the domain and is what an R155-regulated program expects to see, and its impact-times-feasibility structure handles the safety dimension DREAD can’t. For a generic likelihood-times-impact option, OWASP’s Risk Rating Methodology has the same judgment-call weakness but at least keeps likelihood and impact apart.

The general lesson

The DREAD failure isn’t really about DREAD. Any scheme that maps several independent qualitative axes to numbers and adds or averages them inherits the same two problems: a high score on something you don’t care about cancels a low score on something you do, and a string of judgment calls ends up looking like a measurement. That covers CVSS Base scores, the 5-by-5 grid in your GRC tool, and most “risk = probability times impact” spreadsheets. What the number actually does is make two people who disagree about a threat say why, on which axis, and against which past case they’re calibrating.

I don’t have a clean answer for comparing risk across unrelated systems. Relative ranking inside one calibrated model is the ceiling for this whole family of methods, and DREAD is just the oldest and most obvious place to see it.

Further reading

• David LeBlanc, “DREADful” (2007), the co-author’s own takedown of the scoring math: learn.microsoft.com/en-us/archive/blogs/david_leblanc/dreadful.
• Adam Shostack, “Experiences Threat Modeling at Microsoft” (2008), on why DREAD got bolted on and what the SDL did instead: shostack.org.
• Microsoft, Improving Web Application Security: Threats and Countermeasures (2003), Chapter 3, source of the High/Medium/Low scale and the 5-to-15 buckets.
• OpenStack Security Group, OSSA-Metrics, a real-world DREAD adaptation with calibrated anchors and worked advisories.
• Sam Curry et al., “Web Hackers vs. The Auto Industry” (2023), the telematics and back-office API findings used in the walkthrough.
• FIRST, CVSS v4.0 specification.
• ISO/SAE 21434:2021, Road vehicles: Cybersecurity engineering (paywalled; the threat analysis and risk assessment methods are in clause 15).

Related posts: the STRIDE and LINDDUN walkthroughs for finding the threats DREAD ranks, and the ISO/SAE 21434 TARA post for the automotive method that handles the safety dimension DREAD can’t.