Misuse Cases

Definitions

A misuse case (a.k.a., abuse case) is a special kind of use case in which:

• The goal of the use case is to prevent a threat from occurring or to mitigate the impact of a threat if it does occur.
• Specify what threat the business, application, component, or center is to neutralize as opposed to specify what it is to do.
• The user client external (human actor or application) of the use case is replaced by or augmented with a hostile misuser (e.g., cracker or disgruntled employee, computer virus, storm, earthquake) who threatens or attempts to misuse the business, application, component, or center.
• The normal user-initiated interactions are replaced or augmented by the misuser-initiated attack interactions.
• The required business, application, component, or center interactions and postconditions are replaced or augmented by security-oriented responses to the threat.

Whereas use cases are used to specify system support for users, misuse cases are used to specify system prohibitions against misuser threats.

Objectives

The typical objectives of a misuse case are to:

• Clarify and analyze security threats.
• Capture top-level security patterns.
• Analyze and specify related security and safety requirements that prevent these threats from occuring or mitigate their impact if they do occur.
• Clarify the relationships between the threats (misuse cases) and the functional requirements (use cases).
• Clarify the behavior of security mechanisms.
• Help make security design trade-offs.
• Drive security tests.

Examples

The following are typical examples of security misuse cases:

• Use Case — Access Control:
  • Use Case Path – Attempted Spoofing using Valid User Identity
  • Use Case Path – Attempted Identity and Authentication Theft
  • Use Case Path – Attempted Spoofing using Social Engineering
• Use Case — Immunity:
  • Use Case Path – Virus Protection
• Use Case — Integrity:
  • Use Case Path – Data Integrity
  • Use Case Path – System Message Integrity
  • Use Case Path – User Message Integrity
• Use Case — Intrusion Detection
• Use Case — Nonrepudiation
• Use Case — Privacy:
  • Use Case Path – Data Privacy
  • Use Case Path – System Message Privacy
  • Use Case Path – User Message Privacy
• Use Case — Physical Protection

Use Case: Access Control

The following are typical examples of paths through the access control misuse case:

• Use Case Path – Attempted Spoofing using Valid User Identity
• Use Case Path – Attempted Identity and Authentication Theft
• Use Case Path – Attempted Spoofing using Social Engineering

Use Case Path: Attempted Spoofing using Valid User Identity

Use Case Path – Attempted Identity and Authentication Theft

Use Case Path – Attempted Spoofing using Social Engineering

Use Case — Immunity

The following are typical examples of paths through the immunity misuse case:

Use Case Path – Virus Protection

Use Case — Integrity

The following are typical examples of paths through the integrity misuse case:

• Use Case Path – Data Integrity
• Use Case Path – System Message Integrity
• Use Case Path – User Message Integrity

Use Case Path – Data Integrity

Use Case Path – System Message Integrity

Use Case Path – User Message Integrity

Use Case — Intrusion Detection

The following are typical examples of paths through the intrusion detection misuse case:

Use Case — Nonrepudiation

The following are typical examples of paths through the nonrepudiation misuse case:

Use Case — Privacy

The following are typical examples of paths through the privacy misuse case:

• Use Case Path – Data Privacy
• Use Case Path – System Message Privacy
• Use Case Path – User Message Privacy

Use Case Path – Data Privacy

Use Case Path – System Message Privacy

Use Case Path – User Message Privacy

Guidelines

The following guidelines have been found to be useful when producing access control requirements:

• Misuse cases can support different activities (e.g., requirements engineering, architecting, design, testing) depending on their level of abstraction and the amount of implementation details they contain.
• To analyze and specify security requirements, use essential misuse cases that do not unnecessarily contain architectural or design constraints (e.g., specific security mechanisms).
• Because essential misuse cases do not contain architectural or design constraints, they are very general and highly reusable.
• Specify requirements only on the system, not on the user or misuser.
• Develop misuse case paths to counter specific security threats.
• For each misuser, identify the following information:
  • Types of misusers (e.g., hacker, cracker, or disgruntled employee)
  • Objectives (i.e., motives) for their attack
  • Means of attack (e.g., skills, resources)
  • Assumed level of authorization (i.e., privilege)
• Name the path through the misuse case after the specific security threat that the path thwarts.
• Misuse cases are not equally applicable to all kinds of security requirements.
• Misuse cases can be related to use cases by the “threatens” and “mitigates” relationships.
• Misuse cases should be clearly differentiated from normal use cases on use case diagrams, possibly by use of a graphical or textual stereotype.

References

For more information about misuse cases, read:

• Ian Alexander:
  • “Misuse Cases, Use Cases with Hostile Intent,” OU Research Group, May 2002. IEEE Software, Volume 20, Number 1, January/February 2003, pp. 58–66.
  • “Initial Industrial Experience of Misuse Cases in Trade-Off Analysis,” Proceedings of IEEE Joint International Requirements Engineering Conference, Essen, Germany, 9-13 September 2002, pp 61–68.
  • “Misuse Cases Help to Elicit Nonfunctional Requirements,” REFSQ Workshop, Essen, September 2002.
  • “Modelling the Interplay of Conflicting Goals with Use and Misuse Cases,” Proceedings of the Eighth International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ’02), Essen, Germany, 9th-10th September 2002, pp 145–152.
  • “Requirements Engineering with Use Cases and Misuse Cases”
  • “Misuse Cases”
• Karen Allenby and Tim P. Kelly:
  • “Deriving Safety Requirements using Scenarios,” Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE’01), Los Alamitos, California: IEEE Computer Society Press, 2001, pp. 228–235. Proceedings of the International Conference on Engineering Design (ICED’01), August 2001.
• John McDermott and Chris Fox (Abuse Cases):
  • “Using Abuse Case Models for Security Requirements Analysis,” Proceedings of the 15th Annual Computer Security Applications Conference, Phoenix, Arizona, 6–10 December 1999.
  • “Abuse-Case-Based Assurance Arguments,” Proceedings of the 17th Annual Computer Security Applications Conference, New Orleans, Louisiana, 10–14 December 2001.
  • “Abuse-Case Model Template”
• Guttorm Sindre and Andreas L. Opdahl:
  • “Eliciting Security Requirements by Misuse Cases,” Proceedings of the 37th Technology of Object-Oriented Languages and Systems (TOOLS–37 Pacific 2000), Sydney, Australia, 20–23 November 2000, pp 120–131.
  • “Templates for Misuse Case Description,” Proceedings of the Seventh International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ’2001), Interlaken, Switzerland, 4–5 June 2001.
  • with Gøran F. Brevik: “Generalization/Specialization as a Structuring Mechanism for Misuse Cases,” in the Proceedings of the 2nd Symposium on Requirements Engineering for Information Security (SREIS’02), Raleigh, North Carolina, USA, 15–16 October 2002.
  • “Elicitation and Specification of Security Requirements During Early RE through Misuse Cases,” a seminar given at the University of Technology at Sydney (UTS) on 23 October 2002.