Mitigating Controls From Abuse Cases

Why This Topic Matters
Most security defects are not coding mistakes; they are requirements that were never written. If no one ever specifies that the application must reject a negative quantity in a shopping cart, a developer will not build that check and a tester will not test for it. Abuse cases (also called misuse cases) are the structured technique the CSSLP uses to surface these missing requirements by asking, "How would a hostile user try to make this feature do something it should not?" The mitigating controls that come out of that exercise become explicit, testable security requirements. On the exam, this topic sits squarely in Domain 2 (Secure Software Requirements) and connects directly to Domain 3 (Secure Software Architecture and Design) and Domain 5 (Secure Software Testing). Expect scenario questions that ask you to identify the right control, the right phase, or the right artifact.

What an Abuse Case Is
A use case describes how a legitimate actor interacts with the system to achieve a goal ("Customer logs in with username and password"). An abuse case or misuse case describes how a malicious actor (the "misuser") interacts with the same system to achieve a harmful goal ("Attacker brute-forces the login form to guess a valid password"). The concept was formalized by Sindre and Opdahl and by McDermott and Fox in the late 1990s and early 2000s, and it is deliberately modeled alongside normal use cases, often in the same UML diagram with the misuser drawn as an inverted (black) actor.

Each abuse case typically records:
• Misuser / threat agent – who is attacking (external hacker, malicious insider, automated bot, careless user).
• Goal – what the attacker wants (steal credentials, escalate privilege, deny service, tamper with data).
• Preconditions – what must be true for the attack to be attempted.
• Attack flow / steps – the sequence of actions.
• Related use case – the legitimate function being abused.
• Impact – consequence to confidentiality, integrity, or availability.
• Mitigation – the security requirement or control that prevents, detects, or limits the abuse.

What a Mitigating Control Is
A mitigating control is the countermeasure derived from the abuse case and written as a security requirement. In misuse-case diagrams it is shown as a security use case that mitigates (or prevents / detects) the misuse case, while the misuse case threatens the legitimate use case. The key point for the exam: the control is not left as a vague design idea; it is converted into a specific, verifiable requirement that goes into the requirements traceability matrix (RTM) and later into test cases.

Controls are classified in several ways you should recognize:
• By function: preventive (input validation, authentication), detective (logging, monitoring, integrity checks), corrective (automatic lockout release, rollback), deterrent (warning banners), compensating (a secondary control when the primary is infeasible).
• By type: technical (code, configuration), administrative (policy, procedure, training), physical.
• By security property protected: confidentiality, integrity, availability, authentication, authorization, accountability/non-repudiation.

How the Process Works
1. Start from the functional use cases. Every legitimate function is a potential attack surface.
2. Identify misusers. Brainstorm who would want to subvert the function and why. Use threat libraries (STRIDE, CAPEC, OWASP Top 10) to be systematic rather than relying on imagination alone.
3. Write the abuse case. Describe the attack steps against the use case, e.g., "Attacker submits SQL metacharacters in the search field to extract other users' records."
4. Assess risk. Estimate likelihood and impact (DREAD, CVSS-style scoring, or simple high/medium/low) so controls are prioritized against business risk, not applied uniformly.
5. Derive mitigating controls. For each abuse case, define one or more controls. Prefer controls that address root cause and follow secure design principles: least privilege, defense in depth, fail secure, complete mediation, economy of mechanism, psychological acceptability.
6. Write them as security requirements. Use measurable language: "The application SHALL lock an account after five consecutive failed authentication attempts within 15 minutes and SHALL log each attempt with timestamp and source IP." Avoid "The system shall be secure."
7. Trace and test. Record the requirement in the RTM linking abuse case → requirement → design element → test case. The abuse case itself becomes the basis for a negative test (misuse test) during security testing.
8. Revisit. Abuse cases are living artifacts; update them as features change and as new threats emerge.

Worked Examples of Abuse Case → Control
• Abuse: Attacker brute-forces login. Controls: account lockout or progressive delay, CAPTCHA after N failures, multi-factor authentication, logging and alerting of failed attempts.
• Abuse: User modifies hidden price field in a web form. Controls: server-side validation and recalculation, never trusting client-supplied business values, integrity protection of session data.
• Abuse: Insider exports entire customer database. Controls: role-based access control with least privilege, export rate limits, audit logging with separation of duties for log review, data loss prevention.
• Abuse: Attacker floods the password-reset endpoint. Controls: rate limiting/throttling, resource quotas, monitoring for availability.
• Abuse: Attacker uploads a malicious file. Controls: whitelist of permitted types, content inspection, storage outside the web root, antivirus scanning, size limits.
• Abuse: Attacker replays a captured transaction. Controls: nonces/timestamps, session binding, message authentication codes.

Relationship to Other CSSLP Concepts
• Threat modeling (Domain 3) is a broader architectural activity; abuse cases are a requirements-level technique that often feeds threat modeling and vice versa.
• Attack trees decompose a single attacker goal into sub-goals; an abuse case can be the root of an attack tree.
• Security stories / evil user stories are the Agile equivalent: "As an attacker, I want to … so that …." The derived acceptance criteria are the mitigating controls.
• Requirements traceability matrix ensures every control is implemented and tested.
• Negative / misuse testing (Domain 5) validates that the controls actually defeat the abuse case.
• Abuse cases also help document compliance mapping (PCI DSS, HIPAA, GDPR) because they show why a given control exists.

Exam Tips: Answering Questions on Mitigating Controls From Abuse Cases
1. Phase matters. If the question asks when abuse cases should be created or when mitigating controls should first be defined, the answer is the requirements phase, not design, coding, or testing. ISC2 heavily rewards "earlier is cheaper."
2. Pick the control that addresses the attacker's goal, not the symptom. If the abuse case is parameter tampering, server-side validation beats "hide the field with JavaScript." Client-side controls are almost never the best answer when a server-side option exists.
3. Favor measurable requirements. When answer choices include a vague statement ("ensure strong security") and a specific, testable one ("enforce 12-character minimum with complexity and lockout after 5 attempts"), choose the specific one.
4. Know the diagram vocabulary. The misuse case threatens the use case; the security use case mitigates (or prevents/detects) the misuse case. The misuser is the black/inverted actor.
5. Risk-based, not exhaustive. If a question asks how to decide which controls to implement, the answer involves prioritizing by risk (likelihood × impact) and business context, not implementing every conceivable control.
6. Remember traceability. Questions about "ensuring the control is actually built and verified" point to the RTM and to deriving test cases from the abuse case.
7. Distinguish abuse case from related terms. Threat modeling = architecture-level analysis of the whole system; attack tree = hierarchical decomposition of one goal; abuse/misuse case = narrative of hostile interaction tied to a specific use case; evil user story = Agile form of the same idea.
8. Watch for defense-in-depth distractors. A single control is rarely the "best" answer if a layered answer is offered, but do not choose an answer that adds controls unrelated to the stated abuse case.
9. Think about the control type asked for. If the stem says "detect," look for logging/monitoring/alerting; if it says "prevent," look for validation, authentication, or authorization; if it says "compensating," look for an alternative that provides equivalent protection when the primary control cannot be applied.
10. Who should participate? The best abuse cases come from cross-functional input: security, developers, testers, business analysts, and sometimes operations. An answer that limits the activity to one role is usually wrong.
11. Read for the actor. Exam scenarios often hide the real threat agent (an insider, an automated bot, a partner system). The correct control must be effective against that actor; an external firewall does nothing against a malicious insider.
12. Eliminate "accept the risk without analysis" answers. The CSSLP expects documented, risk-informed decisions, so an option that skips analysis or defers security to a later phase is almost always a distractor.

Quick Review Summary
Abuse cases flip use cases to show how a misuser attacks a function. Each abuse case yields one or more mitigating controls, written as specific, testable security requirements during the requirements phase, prioritized by risk, traced through the RTM, and validated with negative tests. On the exam: earliest phase, server-side over client-side, specific over vague, root cause over symptom, and controls matched to the actual threat agent and the function (prevent/detect/correct) the question asks about.