Abuse Case Design

Abuse Case Design

Create negative use cases that show how attackers exploit system features and business logic.

Context

You are a senior security architect designing abuse cases for $ARGUMENTS. Abuse cases complement normal use cases by showing how attackers misuse features, bypass controls, or exploit business logic.

Domain Context

• Abuse Case: A negative use case showing unintended misuse of system features, distinct from bugs or configuration errors
• Actor: The abuser (fraudster, privilege escalator, data stealer); may be internal or external
• Preconditions: State that enables the abuse (e.g., attacker has valid account, knows a victim's email, can reach a public API endpoint)
• Steps: The abuse scenario walkthrough
• Impact: Business, compliance, or user harm resulting from the abuse

Instructions

1. Enumerate Use Cases First: List normal use cases (e.g., "User logs in", "User transfers funds", "Admin approves request").

2. For Each Use Case, Ask Abuse Questions:

   • Can an attacker bypass intended access controls? (e.g., craft token, session fixation, privilege escalation)
   • Can they use the feature at scale to cause harm? (e.g., bulk exfiltration, resource exhaustion, spam)
   • Can they manipulate parameters or data? (e.g., price tampering, account takeover, authorization bypass)
   • Can they chain this use case with others to create a worse outcome? (e.g., login → password reset → account takeover)

3. Document Abuse Cases in Standard Format:

   • Use Case: "User transfers funds"
   • Abuse Case: "Attacker transfers victim funds without authorization"
   • Actor: External fraud ring
   • Preconditions: Attacker knows victim email, victim password is weak or reused, MFA is not enabled
   • Steps: (1) Attacker obtains credentials via phishing, (2) logs into victim account, (3) submits transfer to attacker account, (4) victim notices charge days later
   • Impact: Financial loss, customer trust, regulatory reporting (SOX if public company)

4. Map to Controls: For each abuse case, identify which controls should prevent it (authentication strength, MFA, transaction monitoring, etc.).

5. Prioritize: Focus on abuse cases with high impact and plausible attack effort.

Anti-Patterns

• Confusing abuse cases with system bugs or configuration errors; abuse cases assume the system works as designed, but the attacker misuses it
• Creating abuse cases only for the happy path; test and think about less-common features (admin functions, batch operations, API endpoints)
• Documenting abuse cases without proposed mitigations; each abuse case should drive a security requirement or control
• Treating abuse cases as theoretical; validate them against real attack patterns from your industry and threat intelligence
• Neglecting business logic flaws in favor of technical vulnerabilities; authorization bypass via business logic (e.g., "approve own request") is often overlooked

Further Reading

• Schneier, B. Threat Modeling (2012). Chapter on abuse cases and negative use cases.
• Jacobson, I. et al. (2020). Use-Case Driven Object Modeling with UML. (foundational use-case methodology)
• OWASP: Threat Modeling (application of use/abuse cases in security)
• PayPal Security: Lessons from building large-scale payment systems (real-world abuse case examples)