Misuse Cases: Use Cases With Hostile Intent Ian Alexander

1. Misuse Cases: Use Cases With Hostile IntentIan Alexander CSC 593: Secure Software Engineering Seminar

2. Topics • Eliciting security requirements • Eliciting safety requirements from failure cases • Interplay of design, functional, and nonfunctional requirements • Eliciting reliability, maintainability, and portability requirements • Eliciting exceptions • Eliciting test cases • Design trade-offs with misuse cases • Putting use and misuse cases to work • Getting started with misuse cases CSC 593: Secure Software Engineering Seminar

3. Definition of Misuse Case • The negative form of a use case • A use case from the point of view of an actor hostile to the system under design CSC 593: Secure Software Engineering Seminar

4. Eliciting Security Requirements • Employ use and misuse cases to model and analyze scenarios in systems under design which improves security by helping to mitigate threats • Develop misuse and use cases recursively, going from system to subsystem levels or lower as necessary. Draw the agents and misuse cases explicitly to help focus attention on the elements of the scenario. CSC 593: Secure Software Engineering Seminar

5. Eliciting Security Requirements • Misuse cases threaten use cases with failure, and appropriate use cases can mitigate known misuse. • After you know the mitigation approaches, you can proceed with development by trading off user requirements (countering misuse) and system constraints (such as cost, weight, size, and development schedule). CSC 593: Secure Software Engineering Seminar

6. Eliciting Security Requirements • Partial Mitigation • some drivers leave their engines running when they leave their vehicles for short periods. Can designers protect against this sort of misuse? CSC 593: Secure Software Engineering Seminar

7. A Use Case-Misuse Case Scenario CSC 593: Secure Software Engineering Seminar

8. Eliciting Safety Requirements From Failure Cases • Derive a use case from the system requirements that describes potentially catastrophic failures (hence can be called a misuse case) • A negative agent such as inclement weather can make for a misuse case or a negative agent • Example: Ice-covered road making a car skid • Easily understood metaphor that emphasizes control in different weather conditions. CSC 593: Secure Software Engineering Seminar

9. Eliciting Safety Requirements From Failure Cases • Misuse cases can help elicit appropriate solutions in the form of subsystem functions such as traction and automatic braking controls. • Handle exception events (skidding) through carefully programmed responses. • can be listed as exception handling scenarios CSC 593: Secure Software Engineering Seminar

10. Exception Scenario CSC 593: Secure Software Engineering Seminar

11. Interplay of design, functional andnonfunctional requirements • A misuse case can be seen as a hostile action that serves as a functional goal, such as “Steal the car.” • Traditionally, a misuse case can be thought of as a nonfunctional requirement (which necessitates the creation of a subsystem function such as a lock) to ensure quality standards. CSC 593: Secure Software Engineering Seminar

12. Interplay of design, functional andnonfunctional requirements CSC 593: Secure Software Engineering Seminar

13. Interplay of design, functional andnonfunctional requirements CSC 593: Secure Software Engineering Seminar

14. Eliciting “ility” requirements • you can elicit and analyze reliability requirements as threats caused by agents that are not necessarily intelligent. Such agents include human error, storms, design errors (such as software bugs), and interference on telecommunication links, which can cause software crashes and other types of failure. • Maintainability and portability requirements can also benefit from use/misuse-case treatment. Here, the negative agents could be an inflexible design or a wired-in device dependence. Thus use/misuse case analysis can be applied to many types of requirements. CSC 593: Secure Software Engineering Seminar

15. Eliciting Exceptions • An exception-handling use case describes how the system under design will respond to an undesirable event to prevent a possibly catastrophic failure. • The response can lead to the resumption of normal operations or to a safe shutdown, as when a train stops after it passes a danger signal. CSC 593: Secure Software Engineering Seminar

16. Eliciting Exceptions • Use exception classes • Simply named categories of exception, generic situations that cause systems to fail. You can generate candidate exception scenarios and elicit requirements to prevent system failure from a proven list of exception classes. • Use requirement templates • Good templates help elicit and validate requirements simply because they remind us of questions to ask, such as “Could there be any portability requirements here?” To elicit exceptions, you step through all the scenarios in the use cases, asking, “Could anything go wrong here?” This is effective and general, but not guaranteed to find all possible exceptions. CSC 593: Secure Software Engineering Seminar

17. Eliciting Exceptions • Devising threats and negative agents with misuse cases is sometimes a more powerful technique than simply stepping through a template or thinking about exceptions, for the following reasons. • Inverting the problem from use to misuse opens a new avenue of exploration, helping to find requirements that might have been missed. CSC 593: Secure Software Engineering Seminar

18. Eliciting Exceptions • 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 by using the structure of the scenarios themselves as a guide, with a more specific intent than a plain search for exceptions provides. • Knowing explicit threats offers immediate justification for the search and indicates the priority of the discovered requirements. CSC 593: Secure Software Engineering Seminar

19. Eliciting Exceptions • Personifying and anthropomorphizing the threats adds the force of metaphor, applying the powerful human faculty of reasoning about people’s intentions to requirements elicitation. CSC 593: Secure Software Engineering Seminar

20. Eliciting Exceptions • Making elicitation into a game makes the search enjoyable and provides an algorithm for it—“Team 1 outthinks Team 2’s best move, and vice versa.” The stopping condition is whether the threat’s size and probability justify the cost of the mitigation, given its probability of defeating a threat. There is an obvious parallel here with cost-benefit analysis. CSC 593: Secure Software Engineering Seminar

21. Eliciting Exceptions • Providing a visual representation of threat and mitigation makes the reasoning behind the affected requirements immediately comprehensible. CSC 593: Secure Software Engineering Seminar

22. Eliciting Test Cases • Good testing goes beyond happy-day scenarios to explore boundary conditions and exceptions. • Products of use/misuse-case analysis that can contribute to effective test planning include • Specific failure modes (especially useful for real-time, embedded, and safety related systems) • Security threats (especially useful for distributed commercial and government systems) CSC 593: Secure Software Engineering Seminar

23. Eliciting Test Cases • Exception-handling scenarios (always useful, often directly translating to test scripts) CSC 593: Secure Software Engineering Seminar

24. Design trade offs with misuse cases CSC 593: Secure Software Engineering Seminar

25. Design trade offs with misuse cases • Make informed decisions by studying possible use cases, misuse cases, threats the misuse cases pose and their mitigations. Weigh one option against another and select the one that best satisfies the needs of the system as well as ensure its security. CSC 593: Secure Software Engineering Seminar

26. Putting use and misuse cases towork • Recursive Decomposition • Integration of hardware level functions into software level • Participative Inquiry Cycle Approach • Have users participate in the design and development process CSC 593: Secure Software Engineering Seminar

27. Getting started with misuse cases • Start an informal workshop • Identify negative agents • Brainstorm a list of misuse cases • For each use case, find a misuse case (s) that might threaten it. • Mitigate the misuse cases Questions/Comments ??? CSC 593: Secure Software Engineering Seminar