CSC 593: Secure Software Engineering SeminarSlide #1 Misuse Cases: Use Cases With Hostile Intent Ian...

CSC 593: Secure Software Engineering Seminar Slide #1

Misuse Cases: Use Cases With Hostile Intent

Ian Alexander


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


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


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.



• 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).



• Partial Mitigation some drivers leave their engines

running when they leave their vehicles for

short periods.

Can designers protect against

this sort of misuse?


A Use Case-Misuse Case Scenario


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.


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


Exception Scenario


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.


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.


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.


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.



• 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.



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.



Personifying and anthropomorphizing

the threats adds the force of metaphor,

applying the powerful human faculty of

reasoning about people’s intentions to

requirements elicitation.



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.



Providing a visual representation of

threat and mitigation makes the reasoning

behind the affected requirements immediately comprehensible.


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)


Eliciting Test Cases

Exception-handling scenarios (always

useful, often directly translating to test

scripts)


Design trade offs with misuse cases


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.


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


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 SeminarSlide #1 Misuse Cases: Use Cases With Hostile Intent Ian...

Documents

Transcript of CSC 593: Secure Software Engineering SeminarSlide #1 Misuse Cases: Use Cases With Hostile Intent Ian...