Misuse Cases Claude Turner

Outline Introduction Misuse Cases Example 1 Example 2 Tool Support for Use and Misuse Cases

Introduction

“Humans have analyzed negative scenarios ever since they first sat around Ice Age campfires debating the dangers of catching wooly rhinoceros: ‘What if it turns and charges us before it falls into the pit?’” Ian Alexander

A more recent scenario is ‘What if the hackers launch a denial of service attack?’ Modern systems engineers can employ a misuse case—the negative form of a use case—to document and analyze such scenarios. A misuse case is simply a use case from the point of view of an actor hostile to the system under design.” Ian Alexander

Misuse Cases

Misuse Case A use case that documents a negative scenario A use case from an attacker’s perspective or from an actor hostile to the system under design. Applies the concept of negative scenario in a use- case context. – A negative scenario is a situation that the system’s owner does not want to occur. – Example: business leaders, game planners, and military tacticians are familiar with the strategy of analyzing their opponents’ best moves as identifiable threats. – In contrast, a use case generally describes behavior the owner wants the system to possess. Represents what if type questions

Recursive Misuse and Use Cases Can develop misuse and use cases recursively, going from system to subsystem levels or lower as necessary Lower-level cases can highlight aspects not considered at higher levels, possibly forcing another analysis Approach offers rich possibilities for exploring, understanding, and validating the requirements in any direction

Example 1 (Figure 1)

Example 1 Like a game (ex. Chess or Draft): “a team’s best strategy consists of thinking ahead to the other team’s best move and acting to block it.” In the figure, use cases appear on the left, and misuse cases are on the right Misuse threat: car theft Use case actor: lawful driver Misuse actor: car thief Risk: driver’s freedom to drive the car if thief can steal it

Example 1 Top-level analysis: driver must be able to lock the car (a derived requirement) to mitigate the threat Next-level analysis (thief’s response): if thief breaks the door lock and shorts the ignition, this requires another mitigating approach – such as, locking the transmission Thus, threat and mitigation forms a balanced zigzag.

Example 2 (Figure 2)

Example 2—Design Tradeoffs (satisfying conflicting user demands) Each design choice opens up new possibilities for both use and misuse Designers must therefore tradeoff one option against the other Example: – Web portal users must be able to access the provided services – Access can be threatened by a variety of security assaults (e.g., sabotage by rogue employees, sophisticated attacks by hackers)

Example 2—Design Tradeoffs (usability) Security can threaten system use if it is so strict that it frustrates lawful users (usability) and leads them to seek alternative services But, loose control that are more comfortable for such users invite misuse Figure 2 illustrates these dilemmas by adding “aggravates” and “conflicts with” relationships between cases

Usability and Misuse Cases Can also apply misuse case solutions to usability, as when a novice operator confused by the user interface becomes a negative agent

Tool Support for Use and Misuse Cases DOORS requirements management tool Scenario Plus (free set of add-ons for doors

References Alexander, I. (2003). Misuse Cases: Use Cases with Hostile Intent. IEEE Software,