Abuse Case
also called Misuse Case
A use case written from the attacker's side - a hostile actor plus the interaction that achieves their goal - which engineers can refute or fix, unlike a likelihood-impact score which they can only dispute.
A security review hands engineering 47 findings on a five-by-five matrix: 9 high, 12 medium, 26 low, each with a numeric score. A quarter later three are closed and the team's recorded position on several others is that the likelihood rating is too high. Nothing about the exchange was unreasonable, and it produced almost no code changes.
Rewrite one finding as a path — an unauthenticated caller enumerates booking references and reads another guest's itinerary — and the conversation changes shape. The engineer now has two useful moves: break a link in the chain, or show it is unreachable. Disputing it is no longer the cheapest response, because the claim is about the system rather than about a number.
Why it matters
Abuse cases are falsifiable and scores are not. A score is an opinion about a probability, so the honest engineering response to a score is another opinion, and the exchange ends in a risk-accepted column. A path is a claim about reachability, so the response is a test.
They also work earlier. Written at design time an abuse case is a requirement — "the booking reference must not be enumerable" — and requirements get built. The same content after launch is a finding, and findings get queued.
Implementation patterns
- Four parts per case: the actor and what they hold (no credentials, any employee credential, administrator), the goal, the reachable path hop by hop, and the one change that removes it with its cost.
- Derive them from the trust-boundary diagram, one boundary crossing at a time, which makes coverage arguable rather than anecdotal.
- Keep a derived severity label rather than a voted one: reachable unauthenticated, reachable with any employee credential, reachable only with administrative access, crossed with the data class at the end of the path. It sorts, and it cannot be negotiated separately from the mechanism.
- Turn closed ones into automated negative tests, the only form that stays closed through a refactor.
- Write them with the owning engineer, not at them. A case written in the room is estimated in the room.
Industry example
The idea has a documented lineage: abuse cases were introduced in 1999 by McDermott and Fox and misuse cases in 2000 by Sindre and Opdahl, both as extensions of UML use cases for eliciting security requirements, and the approach was argued for practitioners in IEEE Security & Privacy in 2004. The shape recurs wherever identifiers are guessable: a hotel-booking marketplace at Booking.com scale emails reservation references to guests, partners and hotels, so enumerate the reference space and read other people's itineraries is the first abuse case anyone writes — answered by unguessable references bound to a second factor, not by rating the risk.
Failure scenarios
- The unreachable hypothetical. A path with no reachability argument is a story, correctly ignored.
- No severity label at all, leaving the risk register unsortable and the audit without its artefact.
- Coverage collapse. A traced path costs 45 to 90 minutes against about 10 minutes for a matrix row, so a team that switches wholesale reviews far fewer services.
- Security-authored only, which reproduces the dispute dynamic the format was meant to remove.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Abuse cases | changes shipped · falsifiable · reusable as tests | 4 to 9× authoring time · no portfolio aggregation |
| Scored matrix | fast · comparable across teams · satisfies the register | arguable numbers · remediation stalls in acceptance |
| Both | sortable register with actionable bodies | discipline never to let the label decide the work |
When not to use it
For a first pass over an estate nobody has mapped — 300 services with no inventory are better served by cheap scored triage, because the goal is finding unknowns, and depth comes second. Below roughly 20 findings a quarter, skip the format and put each one in front of the owning engineer. And when the exercise exists purely to produce a compliance artefact, an abuse-case folder will not satisfy the control: produce the register and keep paths for the few findings you intend to fix.
Interview question
Q: Your threat models are thorough and remediation is slow. You suspect the communication format. What do you change, and what do you lose by changing it?
What a strong answer covers: replace scores-as-the-finding with attack paths naming the one change and its cost, derived from the trust-boundary diagram; keep a severity label derived from reachability and data class so the register still sorts; pair each case with the owning engineer. State the losses: authoring time rises several-fold so coverage drops, narratives do not aggregate for a board, and the audit artefact needs separate maintenance. Sequence it — paths for services touching regulated or monetary assets, scored triage elsewhere — rather than switching the whole programme.
Quick check
Quiz: Why does an abuse case produce code changes where a score produces debate? — The path is a claim about reachability an engineer can break or refute; a score is an opinion met only with another opinion.
Flashcard: What are the four parts of a usable abuse case? — The actor and their starting credentials, the hostile goal, the reachable path hop by hop, and the one change that removes it with its cost.