Misuse Cases: Use Cases with Hostile Intent

1. Misuse Cases: Use Cases with Hostile Intent Presented by Crystal Nevels February 15, 2007

2. Reference I. Alexander, "Misuse Cases: Use Cases with Hostile Intent," IEEE Software, vol. 20,  no. 1,  pp. 58-66,  Jan/Feb,  2003.

3. Outline • Scenarios • Overview of misuse cases • Applications of misuse cases • Tools • Conclusions

4. Scenarios • Negative scenarios have long been applied in e.g. military and commercial operations planning • The scenarios in which such 'negative' agents attempt to defeat the system under design can be elicited as misuse cases

5. Misuse Cases • Misuse cases are negative use cases • Actor is a hostile agent • Valuable for hazard and threat analysis • Beneficial for eliciting requirements • Generate test cases

6. Applications of Misuse Cases • Eliciting security requirements • Eliciting safety requirements • Interplay of design, functional, and nonfunctional requirements • Eliciting “-ility” requirements • Eliciting exceptions • Developing test cases • Design trade-offs

7. Eliciting Security Requirements • Security requirements exists because people and negative agents pose threats. • Security specifications differ because there are deliberate attempts to break into the system. • Use cases and misuse cases help mitigate threats.

8. Eliciting Security Requirements • Misuse cases occur in specific situations or as continuous threats to a systems. • Misuse cases can be developed recursively.

9. Security Requirements

10. Eliciting Safety Requirements • Failure mode analysis • Analysis depends on accurately identifying failures • Relates possible cause to possible effects • Makes assumptions and measurements • Calculates probabilities • Misuse case analysis can identify possible failures • A negative agent such as bad weather can be represented as a misuse case • Example: Ice-covered road making a car skid • Easily understood metaphor that emphasizes control in different weather conditions

11. Related Work • Karen Allenby and Tim Kelly describe a method for eliciting and analyzing safety requirements using 'use cases. • They do not suggest the use of negative agents associated with their use cases. • Their method is to tabulate the failures, their causes, types, and effects, and then possible mitigations. • They observe that mitigations often involve subsystems, • However, since their 'use cases' describe potentially catastrophic failures and their effects.

12. Eliciting Safety Requirements • Safety requirements scenarios don’t necessarily involve human agents. • Misuse cases can elicit solutions in the form of subsystem functions. i.e. traction and automatic braking controls. • Handle exception events (skidding) through carefully programmed responses. • can be listed as exception handling scenarios

13. Safety Requirements

14. Tool Support for Use and Misuse Cases • Use case tools can be used to display or hide misuse cases. • A tool can automatically produce diagrams and guide requirements elicitation

15. Tool Support for Use and Misuse Cases • Scenario Plus toolkit is designed to handle use and misuse cases • It automatically links underlined references to cases to create 'includes', 'has exception', 'threatens' or 'mitigates' relationships as appropriate. • The Scenario Plus toolkit creates these relationship links automatically, and to display them graphically

16. Rule-Based Linking • Links can be specified from any use/misuse case to any other • Type of link is determined by source/target case • Other types of links can be specified manually

17. Interplay of design, functional andnonfunctional requirements • A misuse case can be seen as a hostile action that serves as a functional goal, such as “ damage the ignition.” • A misuse case can represent a nonfunctional requirement to ensure quality standards.

18. Interplay of design, functional andnonfunctional requirements

19. Interplay of design, functional andnonfunctional requirements

20. Eliciting “-ility” Requirements

21. Eliciting Exceptions • Misuse cases can be used to describe how the system will respond to an undesirable event • The response can lead to the resumption of normal operations or to a safe shutdown

22. Eliciting Exceptions • Devising threats and negative agents with misuse cases is sometimes a more powerful technique for the following reasons: 1) Inverting the problem from use to misuse helps find requirements that might have been missed,

23. Eliciting Exceptions 2) Asking “Who might want this to go wrong?” and “What could they do to make this go wrong?” in the misuse-case approach contributes to searching systematically for exceptions, 3) Knowing explicit threats offers immediate justification for the search and indicates the priority of the discovered requirements,

24. Eliciting Exceptions 4)Providing a visual representation of threat and mitigation makes the reasoning behind the affected requirements immediately comprehensible.

25. Eliciting Test Cases • Products of use/misuse-case analysis that can contribute to effective test planning include • Specific failure modes (for real-time, embedded, and safety related systems) • Security threats (for distributed commercial and government systems) • Exception-handling scenarios (always useful, often directly translating to test scripts)

26. Design Trade-offs with Misuse Cases • Make informed decisions by studying possible use cases, misuse cases, threats and threat mitigations. • Weigh one option against another and select the one that best satisfies the needs of the system as well as ensures its security.

27. Conclusions • Misuse Case models are a promising approach for • Eliciting various non-functional requirements, such as for security, safety, and perhaps usability; • Identifying threats to system operation, • Identifying ways of neutralizing those threats; • Identifying conflicts between requirements and design approaches, whether direct goal conflicts, or indirect through aggravation of Misuse Cases

28. Questions?