DREAD Scores and Why Ordinal Risk Ratings Do Not Multiply

DREAD assigns each threat five numbers, one for each of damage potential, reproducibility, exploitability, affected users, and discoverability, and sums or averages them into a single rating. The ratings then order a work list. The procedure is easy to teach, produces a number for every row, and is arithmetically invalid in a way that has been pointed out repeatedly since the method fell out of favor: the five dimensions are measured on ordinal scales, and ordinal scales do not support addition.

What each dimension is actually asking

The dimensions are not equivalent questions, which is the deeper problem behind the arithmetic. Each measures something different about the threat, and collapsing them treats incommensurable quantities as if they were five samples of one variable.

Damage potential asks what the attacker gains, in the terms the asset inventory established: a partial disclosure of one record, a full compromise of an administrative credential, a complete outage of a payment path. It is a consequence measure and it belongs to the asset, not to the threat.

Reproducibility asks whether the attack works every time, intermittently, or once under conditions that cannot be recreated. This is a property of the mechanism, and it is genuinely binary in many cases: a request that bypasses an authorization check either does so deterministically or depends on a race that requires specific interleaving. Where it is probabilistic, the honest measure is a rate, not a rank.

Exploitability asks what the attacker must already possess. The distinctions that matter are categorical: no credentials, one valid account, code execution on a host. A five-point scale blurs these into adjacent integers even though the gap between “no credentials” and “one valid account” is the gap between the exposed surface and everything behind it.

Affected users asks for a count, and the count is often the only dimension where a real number exists. It is also the dimension most often estimated rather than measured, and an estimated count multiplied into an average is an invented figure with a rank’s confidence attached.

Discoverability asks how likely the attacker is to find the issue. This is a property of the defender’s visibility, not of the threat: a defect in a widely mirrored open-source component is discoverable in a way that an equivalent defect in an internal tool is not. Ranking it assumes the answer is knowable, which it usually is not, and the assumption is asymmetric: models systematically overrate the discoverability of issues that are easy to describe and underrate the ones buried in code nobody reads.

The scale problem, stated precisely

Stevens’s classification of measurement scales is the relevant result. Nominal scales admit only equality; ordinal scales admit order but not distance; interval scales admit distance but not ratios; ratio scales admit all four operations. Adding ordinal ranks assumes that the distance between rank 1 and rank 2 equals the distance between rank 4 and rank 5, which the scale does not assert and which is usually false.

A concrete demonstration: two threats both score damage 3. One is a disclosure of one record from a table of ten million; the other is a disclosure of the entire table. Under any consequence model these differ by six orders of magnitude, and the scale assigns them the same integer. Any sum that includes both treats them as equally damaging, and the error is not random. It is systematically in the direction of flattening large differences, which is precisely the information a prioritization needs.

Averaging makes it worse rather than better. A mean over five ranks produces a value with a decimal fraction, which implies precision the inputs do not have. A threat scoring 3, 3, 3, 3, 3 and one scoring 5, 1, 1, 5, 1 both average 3. The first is uniformly moderate; the second is catastrophic but hard. Ordering them as equal is not a close call; it is a category error, and the two demand different responses: the first is a candidate for acceptance with monitoring, the second for redesign.

Why the method survived anyway

The invalid arithmetic is not why teams adopted it. The method survived because it forces five questions to be asked about every threat, and asking those questions is most of the value. A threat model that enumerates findings and then never asks whether the attacker needs credentials has skipped a step, and DREAD’s structure prevents that skip.

The mistake was to keep the questions and also keep the sum. The repair is to keep the dimensions as a structured record and discard the aggregation. Each threat row then carries a categorical description per dimension: the consequence in asset terms, the prerequisite position, whether the mechanism is deterministic, the population affected as a measured or bounded count, and the defender’s detection coverage. The ordering is derived by a separate step that does not pretend the five are commensurable.

A comparison procedure that survives review

The ordering step that works in practice is a lexicographic comparison on a small number of dimensions, chosen so that the first dimension is the one the organization has decided dominates.

The first key is the asset threshold from the inventory: whether the consequence crosses a disclosure obligation, a safety boundary, or a contractual limit. This is a yes-or-no question with an owner, and it partitions the list into two groups rather than ranking all rows on one scale. Thresholds are defensible in review because they are documented obligations rather than judgments.

The second key is the prerequisite position, ordered by the reachability structure: unauthenticated remote, authenticated low privilege, code execution inside the boundary. This ordering is not arbitrary; each position strictly contains the previous one’s capability set, so the comparison is monotone by construction.

The third key is determinism: a mechanism that works every time is worth more attention than one that works occasionally, given the same consequence and position, because the attacker’s cost is lower and the defender’s margin is smaller.

Ties beyond the third key are genuinely ties, and the right response is to accept the tie rather than to invent a fourth dimension to break it. A work list where twenty rows are ordered by three keys and the rest are grouped as equal is more useful than one where every row has a distinct score, because the distinct scores are noise dressed as information.

What the ranking must not claim

A ranked list is not a forecast. The ordering says which findings should be examined first, not what will happen or how often. Three claims are tempting and wrong.

The first is that the ranking estimates likelihood. It does not; it orders by consequence and precondition, and likelihood depends on the adversary’s intent, which the model does not know. A high-ranked finding may never be attempted.

The second is that a rank position transfers between models. A ranking produced for one system reflects that system’s thresholds and that system’s attacker positions, so the first item in one list and the first item in another may sit at entirely different points on any shared scale. The order is meaningful within a model and arbitrary across two.

The third is that the ranking is stable. Adding a finding can change the ordering of others when the keys are thresholds, because a new finding may reveal that a threshold is crossed by a mechanism the model previously placed below it. Instability is a feature: it means the ordering responds to evidence, and a ranking that never moves is a ranking that is not being used.

The output that survives all three criticisms is modest: a partition by obligation, an order by attacker position and determinism, and an explicit statement of what each tier means for action. That is a prioritization argument, and it is the only kind that a reviewer can check. The next question, whether a given finding is worth the cost of fixing it, requires an estimate of the attacker’s effort, which is where the cheapest-path computation over an attack graph does work that a severity score cannot, and where the cost arithmetic of an attack tree supplies the input.