How do you systematically derive Misuse Cases from a Use Case Diagram?
Walk every use case and ask "how could an attacker abuse, bypass, or exploit this?" — turning each functional UC into one or more Misuse Cases, then linking and mitigating them.
* The six-step flow for deriving misuse cases (and mitigations) from a use-case diagram. *
The method is systematic on purpose: rather than brainstorming threats at random, you anchor each one to a concrete piece of functionality, which guarantees coverage and keeps every threat tied to something testable. Applying a checklist like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to each UC stops you from forgetting whole categories of attack:
Step-by-step process:
| Step | Action | Example (Login system) |
|---|---|---|
| 1 | List all Use Cases | Enter username, Enter password, Use system |
| 2 | For each UC, identify input points | Username field, password field |
| 3 | Apply STRIDE to each input | Spoofing (fake identity), Tampering (SQL injection) |
| 4 | Create Misuse Cases for each threat | "Injection attack", "Brute force", "Session hijacking" |
| 5 | Link MUCs to UCs with "threatens/exploits" | Injection → threatens → Enter username |
| 6 | Design Mitigation Cases | Input validation mitigates injection |
Checklist for each Use Case:
- Can the input be manipulated? (Injection, Overflow)
- Can the identity be faked? (Spoofing)
- Can the action be replayed? (CSRF, Replay attack)
- Can the data be intercepted? (MITM)
- Can the function be abused beyond intent? (Privilege escalation)
Tip: Focus on Use Cases that cross trust boundaries first — these are the highest-risk interfaces.
Go deeper:
Misuse case (Wikipedia) — deriving negative scenarios from use cases to elicit security requirements.