Misuse and Abuse Cases

Why Misuse and Abuse Cases Matter
Traditional requirements engineering focuses on what the system should do for legitimate users. Use cases capture functional behavior from the perspective of an authorized actor. But attackers do not follow the happy path. Misuse and abuse cases fill this gap by asking: How could this functionality be deliberately exploited, subverted, or turned against the system and its users?

In the CSSLP Domain 2 (Secure Software Requirements), misuse and abuse cases are a core technique for eliciting security requirements early in the Software Development Life Cycle (SDLC). Finding and fixing a design flaw during requirements is dramatically cheaper than patching it in production. By modeling hostile intent up front, teams derive concrete security controls (authentication, input validation, logging, rate limiting, etc.) that become testable requirements rather than afterthoughts.

What Misuse and Abuse Cases Are
Use case: A description of how a legitimate actor interacts with the system to achieve a goal (e.g., "Customer logs in to view account balance").

Misuse case: A use case written from the perspective of a hostile actor (the misuser or mis-actor) describing a sequence of actions that would cause harm to the system or its stakeholders (e.g., "Attacker performs credential stuffing to gain access to a customer account"). The term was popularized by Guttorm Sindre and Andreas Opdahl, who extended UML use case diagrams with inverted (black) ovals for misuse cases and black stick figures for misusers.

Abuse case: Introduced by John McDermott and Chris Fox, an abuse case describes a complete interaction between one or more actors and the system where the results are harmful. In practice, the CSSLP exam and most literature treat misuse case and abuse case as essentially interchangeable; both describe unintended, malicious use of software. Some practitioners distinguish them subtly: misuse cases are often more diagrammatic and tied to UML relationships, while abuse cases tend to be more narrative/scenario-based, often including the attacker's resources, skills, and objectives. For exam purposes, know both terms refer to modeling how the system can be used in ways it was not intended to be used, with harmful intent.

Related but distinct concepts:
• Threat modeling (STRIDE, attack trees) – a broader, more systematic analysis usually done in design; misuse cases often feed into or come from threat modeling.
• Attack trees – hierarchical decomposition of a single attacker goal into sub-goals; misuse cases are scenario-driven.
• Security user stories / evil user stories – the Agile equivalent ("As a malicious user, I want to… so that…").
• Negative requirements – statements of what the system must not allow; misuse cases help convert vague negative requirements into specific positive controls.

How Misuse and Abuse Cases Work
1. Start with the normal use cases. Identify legitimate actors and the functions they perform.

2. Identify misusers. Who might want to harm the system? External attackers, malicious insiders, competitors, automated bots, disgruntled employees, even careless users. Characterize their motivation, skill level, and resources.

3. Brainstorm misuse cases. For each use case, ask what could go wrong if someone intentionally subverts it. Use threat catalogs (STRIDE categories, OWASP Top 10, CAPEC attack patterns) to stimulate ideas. Example for "Reset password": attacker enumerates valid usernames, hijacks the reset token, floods the mail server, or answers security questions from social media research.

4. Model relationships. In Sindre & Opdahl notation, misuse cases connect to use cases with special relationships:
• threatens – a misuse case threatens a legitimate use case.
• mitigates – a security use case (countermeasure) mitigates the misuse case.
• Standard includes and extends can also be used between misuse cases.

5. Define security use cases / mitigations. For each misuse case, define the countermeasure as a new (security) use case: "System locks account after N failed attempts," "System validates and encodes all input," "System logs and alerts on anomalous access."

6. Derive security requirements. Translate mitigations into specific, measurable, testable requirements. These should be positive statements ("The system shall enforce a 15-minute lockout after 5 failed logins") rather than unverifiable negatives ("The system shall not be hackable").

7. Document the abuse case template. A typical textual template includes: name/ID, summary, misuser description and goal, preconditions, basic (attack) flow, alternative flows, postconditions (harm caused), trigger, assumptions, mitigation points, related use cases, business impact, and likelihood/risk rating.

8. Prioritize by risk. Not every misuse case warrants a control. Assess likelihood and impact (often with the business owner) so the most dangerous scenarios drive the requirements.

9. Use them downstream. Misuse cases become inputs to threat modeling, secure design reviews, security test cases (abuse case testing / negative testing), and acceptance criteria. They also help justify security budget to stakeholders in business language.

Benefits
• Shifts security left into requirements.
• Makes attacker thinking accessible to non-security stakeholders.
• Produces traceable, testable security requirements.
• Highlights gaps that functional requirements and compliance checklists miss.
• Improves communication between business analysts, developers, and security teams.

Limitations
• Only as good as the imagination and expertise of the team; unknown attacks may be missed.
• Can become unwieldy for large systems if every use case spawns many misuse cases.
• Not a replacement for full threat modeling, code review, or penetration testing.
• Must be revisited as the system and threat landscape change.

Exam Tips: Answering Questions on Misuse and Abuse Cases
Tip 1 – Know the definition cold. If a question describes modeling how the system could be intentionally used in a way it was not designed for, resulting in harm, the answer is misuse/abuse case. Keywords: hostile intent, malicious actor, unintended use, inverted use case, what the system should not allow.

Tip 2 – Place it in the right SDLC phase. The CSSLP ties misuse cases to the requirements phase (Domain 2). If asked when they are most effectively developed, pick requirements gathering/analysis, not testing or deployment. If asked how they are used later, they feed threat modeling (design) and security test cases (testing).

Tip 3 – Distinguish from related techniques.
• Use case = legitimate user, intended behavior.
• Misuse/abuse case = malicious user, unintended harmful behavior.
• Attack tree = hierarchical goal decomposition.
• Threat model (STRIDE) = systematic categorization of threats against components/data flows.
• Data classification, privacy requirements, and regulatory analysis = other requirement sources, not misuse cases.

Tip 4 – Remember the people. Sindre & Opdahl (misuse cases, UML notation) and McDermott & Fox (abuse cases). If an answer choice credits them to a totally unrelated figure, eliminate it.

Tip 5 – Recognize the relationships. "Threatens" links a misuse case to a use case; "mitigates" links a security use case to a misuse case. A question asking what relationship a countermeasure has to a misuse case wants mitigates.

Tip 6 – Output should be requirements, not fixes. If a question asks what the deliverable of misuse case analysis is, choose security requirements / security use cases / mitigating controls, not source code changes or patches. The CSSLP consistently stresses that requirements must be specific, measurable, and testable.

Tip 7 – Positive over negative. The exam favors converting negative requirements ("shall not") into positive, verifiable controls. If offered a choice between "the system shall not allow SQL injection" and "the system shall use parameterized queries for all database access," the latter is the better requirement derived from the misuse case.

Tip 8 – Treat the terms as synonyms unless the question forces a distinction. ISC2 generally uses "misuse and abuse cases" together. Do not over-think a subtle difference unless the answer options clearly hinge on it.

Tip 9 – Watch for the "best" or "most" qualifier. Many questions have several plausible answers. When asked the best way to identify security requirements from an attacker's viewpoint during requirements elicitation, misuse/abuse cases beat penetration testing (too late), code review (wrong phase), or compliance checklists (not attacker-centric).

Tip 10 – Stakeholders and value. Expect questions on why misuse cases are useful: they help non-technical stakeholders understand risk, justify security controls in business terms, and ensure security is designed in rather than bolted on. The underlying principle is economy of defense: earlier is cheaper.

Tip 11 – Scenario questions. If a scenario says a team wrote "As a legitimate customer I can transfer funds" and asks for the corresponding misuse case, look for something like "An attacker initiates a transfer from an account they do not own by tampering with the account ID parameter." Then the mitigation is server-side authorization checks. Think attacker → harm → control.

Tip 12 – Limitations are fair game. Know that misuse cases depend on team expertise, can miss novel attacks, and must be complemented by threat modeling and testing. An answer claiming misuse cases guarantee complete coverage is wrong.

Quick Recap
Misuse and abuse cases model intentional, harmful interactions with software from the attacker's perspective. They are created during requirements, extend normal use cases with threatens and mitigates relationships, and produce specific, testable security requirements and security use cases. On the exam: identify the attacker-centric, requirements-phase, unintended-use language; pick requirements as the output; favor positive, measurable controls; and separate the concept from use cases, attack trees, and full threat modeling.