Abuse and Misuse Case Method
Scope and purpose
The manual refers to abuse cases at several points, but without a method for producing them. This addon provides one.
An abuse case describes how an adversary uses the system in an intentionally hostile way — the reverse of a use case. Where the functional user story captures what a legitimate user wants to do, the abuse case captures what an attacker wants to achieve against the system. The misuse case is its formalisation (in the tradition of Sindre and Opdahl): a use case driven by a hostile actor, modelled in parallel with the legitimate use cases.
The function of the method is to make adversarial an activity that, by default, is centred on the legitimate user. Abuse cases are an elicitation technique that feeds the threat model and the security requirements.
Applicability: L2 and L3, in the requirements and threat modelling phases.
Abuse cases are a creative and non-exhaustive technique. They complement structured threat modelling (STRIDE, LINDDUN) — they do not replace it. The absence of an abuse case is not proof of the absence of an abuse path.
The method
- Cross-functional workshop. Bring together product, development, security and QA. The diversity of perspectives is what distinguishes useful abuse cases from a predictable list — whoever knows the business rule identifies abuses that the generic attacker does not reveal.
- Derive the adversarial reverse. For each relevant user story or functional flow, formulate its hostile counterpart: "As an attacker, I want <objective>, exploiting <weakness>". An upload flow generates the abuse "upload a file that executes code on the server"; an authentication flow generates "enumerate valid accounts from the error messages".
- Prioritise by risk. Order the abuse cases by the system's risk classification (Ch. 01) and by plausibility against the threat model (Ch. 03). Not every abuse justifies a control; proportionality applies here as it does throughout the manual.
- Translate into adversarial requirements and acceptance criteria. Each prioritised abuse case becomes a security requirement with a verifiable acceptance criterion, and enters the backlog with the same rigour as a functional user story (Ch. 02).
- Feed tests and the threat model. The prioritised abuse cases become test cases (Ch. 10) and inputs to the threat model, closing the cycle between what is feared and what is validated.
Integration into the backlog
An adversarial user story is not an informal note — it is a traceable requirement. It must have an owner, an acceptance criterion and a status, and be handled in the same backlog as the functional requirements. An abuse case that stays outside the backlog is a concern that gets lost between sprints.
Integration into the backlog is what separates this method from a one-off exercise: the abuse identified in a workshop only changes the product if it materialises as prioritised and tracked work.
Relation to structured threat modelling
Abuse cases and structured threat modelling answer different and complementary questions. The abuse case starts from the function ("how is this flow abused?"); STRIDE starts from the security property ("where do integrity, confidentiality and availability fail?"). Applied together, they cover what each one on its own lets slip. Abuse cases are typically the most accessible entry point for teams without a practice of formal threat modelling.
Cross-references
| Document | Relation |
|---|---|
| Ch. 02 — Requirements Catalogue | Where the derived adversarial requirements enter as traceable items |
| Ch. 02 — Application examples | Examples of abuses already translated into requirements and tests |
| Ch. 03 — Methodologies and tools | Structured threat modelling that the abuse cases feed |
| Ch. 01 — Application classification | Basis for prioritisation by risk |
| Ch. 10 — Testing strategy | Where the prioritised abuse cases become test cases |
On curation: Consolidated from OWASP (Abuse Case guidance) and the misuse case tradition (Sindre & Opdahl). Adversarial elicitation method — it complements, and does not replace, structured threat modelling and the programme's risk analysis.