How do you create Misuse Cases for a system like Mobile Payment?
Walk through each use case and component, add an attacker actor, and for every element ask "how could this be abused?" — using STRIDE to make sure you cover every threat category.
A misuse case is just a use case told from the attacker's side: instead of what a legitimate user wants the system to do, it captures what a malicious actor wants to make it do. You build them systematically:
- List the components and use cases the system already has.
- Add an attacker actor alongside the legitimate ones.
- For each element, brainstorm abuse — STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is the checklist that stops you from missing a category.
- Link each misuse case to the use case it threatens or exploits, and note the attacker's goal.
Worked example — the mobile payment app. Picture the system split into a back-end, a point-of-sale till, and the payment core, each used by different actors. An attacker (drawn in red) targets them:
- Back-end: exploit a vulnerable third-party library to reach seller management, customer management, or the core banking system.
- Point-of-sale till: an injection attack against the payment-system administration or the till's operation.
- Payment core (mapped to STRIDE): voucher forgery and balance manipulation (Tampering), identity theft (Spoofing), a man-in-the-middle eavesdrop (Information disclosure), and flooding the service (Denial of service).
The point is the procedure, not this app: systematically pairing each component with STRIDE categories is what turns "think like an attacker" into a repeatable analysis you can hand to security requirements (mitigation use cases).