Is DREAD worth keeping for a thirty-minute threat model of an internal service?

## The setting Thirty minutes, one internal analytics service, a handful of engineers and the person who owns the service. The attacker positions worth modeling here are an employee with legitimate but broader-than-needed access, and an operator or automated job with credentials to the data store. The asset is largely personal data about colleagues plus the audit truth of who queried what. You will produce maybe eight to twelve threats. The question is not whether the model is thorough; it is what, if anything, you use to order those threats before the clock runs out. ## What DREAD genuinely offers **The five prompts are a decent checklist.** Left to itself, a group discusses threats in an undifferentiated way - "that one feels bad" - and blurs distinct questions. Walking Damage, Reproducibility, Exploitability, Affected users and Discoverability forces five separate answers. The most valuable of those in practice is Affected users, because blast radius is the question engineers most often skip: they picture the single record and not the export that touches everyone. **It is cheap.** Five quick judgments per threat costs under a minute. In a thirty-minute box that matters, and it is the reason the scheme survives in lightweight sessions despite everything wrong with the number. **It surfaces disagreement fast.** When one engineer says Damage 3 and another says 9, the useful output is not a compromise digit - it is the discovery that they are imagining different assets or different attackers. Treat the divergence as the finding and resolve it in words. ## What to discard **The mean.** Averaging five unequal, unanchored ordinal ratings produces a decimal that looks like a measurement, dilutes the extreme that usually drives the decision, and cannot be reconstructed by anyone who was not in the room. **The digit in the ticket.** This is the practical rule I would enforce. The moment a score reaches a tracker it acquires authority: it gets filtered on, quoted in a status update, compared against a threat rated by a different team on a different day. Whatever caveats you attached in the room do not travel with it. **Cross-team comparison.** Two teams' DREAD scores are not on the same scale, because the scheme ships with no per-value criteria to put them on one. Any dashboard that pools them is manufacturing a comparison that does not exist. ## What to do instead - **Record a sentence, not a number.** "Any analyst can query the raw table and read colleagues' records; nothing logs which rows they read" is legible in six months. A 6.4 is not. - **Rank by the funding question.** Ask the service owner which threat they would spend the next sprint on and why. That forces the impact conversation onto the person who actually owns the asset, which is where the judgment belongs. - **Name a control per threat before ranking.** A threat whose fix is a half-day configuration change should just be done, regardless of its position in any ordering. Cheap fixes should never wait behind a scoring exercise. - **Close the loop on the leftovers.** The threats you do not fund need an owner and a revisit date, not a low score that makes them disappear. That is what makes a fast model repeatable as a practice rather than a one-off workshop. ## If you must have numbers Some organisations genuinely need a rating that travels - an audit artefact, a shared backlog across teams, an SLA that ties remediation time to severity. Do not stretch DREAD into that role. Either adopt an instrument that publishes per-value criteria so someone absent can reconstruct the rating, or write your own rubric: define in writing what each value means for your assets, define a combination rule that preserves extremes rather than averaging them, and be explicit that this is a bespoke internal scheme. The failure mode to avoid is the middle ground, where a team keeps DREAD's name for its credibility while quietly making up what the digits mean. ## The senior framing The honest summary is that DREAD's value was always its *questions*, not its arithmetic - and that it is a symptom of a general pattern worth naming in an interview: a scoring scheme is a compression of a conversation, and compression is only safe when the reader can decompress it. If the person receiving the number cannot reconstruct why it is that number, you have transmitted confidence without information. Keep the conversation, keep the sentence, and be extremely reluctant to emit a number you could not defend to the engineer whose work you just deprioritised.