Security Use Cases

Definitions

A security use case is a specialized use case the scope of which is restricted to security issues.

Goals

The typical goals of a security use case is to:

• Specify security requirements related to the security threat (i.e., essential use case).
• Document the use of a security architectural mechanism (i.e., architectural use case).
• Thereby:
  • Prevent a security threat from occurring.
  • Mitigate the impact of the security threat if it occurs.

Note that whereas typical use cases are used to specify system support for users, security use cases are used to specify system defenses against misuser threats.

Objectives

To achieve these goals, the typical objectives of a security use case are to:

• Clarify and analyze security threats, which may also be done via misuse cases.
• Analyze and specify related that prevent these threats from occuring or mitigate their impact if they do occur.
• Capture top-level security patterns.
• Clarify the relationships between the threats (misuse cases) and the security requirements (use cases).
• Clarify the behavior of security mechanisms.
• Help make security design trade-offs.
• Provide input to developing the security tests.

Examples

The following are examples of highly general and reusable security use 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 Data Protected
  • Use Case Path – System Data Corrupted
  • Use Case Path – System Message Integrity
  • Use Case Path – User Message Integrity
  • Use Case Path – Denial Of Service (DOS) Attack
• 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 — Security Auditing

Use Case — Access Control

The following example access control use case specifies highly general and reusable access control requirements.

This use case is defined in terms of the following use case path specifications:

• 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 example immunity use case specifies highly general and reusable immunity requirements.

This use case is defined in terms of the following use case path specifications:

• Use Case Path – Virus Protection

Use Case Path – Virus Protection

Use Case — Integrity

The following example integrity use case specifies highly general and reusable integrity requirements.

This use case is defined in terms of the following use case path specifications:

• Use Case Path – System Data Protected
• Use Case Path – System Data Corrupted
• Use Case Path – System Message Integrity
• Use Case Path – User Message Integrity
• Use Case Path – Denial Of Service (DOS) Attack

Use Case Path – System Data Protected

Use Case Path – System Data Corrupted

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 use case:

Use Case — Privacy

The following are typical examples of paths through the privacy use 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

Use Case — Physical Protection

The following are typical examples of paths through a physical protection use case:

Use Case — Security Auditing

The following are typical examples of paths through a security auditing use case:

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 use 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 use 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 use case after the specific security threat that the path thwarts.
• Use 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.
• 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.

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.