What elements should be included in a Misuse Case Description?
The core skeleton is Name, Misuser profile, Description, Basic path, Alternative paths, Triggers, Assumptions, and Mitigation — a mirror of a normal use-case description, but written from the attacker's side.
A bare diagram oval ("Injection attack") isn't enough to act on — you can't test it, prioritise it, or assign a fix. The description template forces you to pin down the who, how, and so-what of each attack so it becomes a concrete, reviewable security requirement. Use it whenever an MUC is significant enough to need a mitigation you'll actually verify.
The richer form adds Priority (so you can triage), Mis-actors and Access Right Levels (who can pull it off, and from what privilege), Point of Entry, Security Attributes Affected (which of Confidentiality/Integrity/Availability is hit), Sophistication (attacker skill needed), and Pre-conditions:
Full template:
| Field | Description | Example Values |
|---|---|---|
| Name | Unique identifier | SQL Injection Attack |
| Priority | Low/Medium/High | High |
| Scope | System area affected | Login module |
| Mis-actors | Who performs attack | External attacker, malicious insider |
| Access Right Levels | Required privilege | Low-Level User, Sys Admin |
| Point of Entry | Where attack starts | Web form input |
| Security Attributes Affected | CIA triad | Confidentiality, Integrity |
| Description | Detailed narrative | - |
| Sophistication | Attacker skill needed | Low/Medium/High |
| Pre-conditions | What must be true | User can access login page |
| Basic path | Main attack steps | - |
| Alternative paths | Variations | - |
| Triggers | What initiates attack | - |
| Assumptions | What we assume | - |
| Mitigation | How to prevent | Input validation |