Misuse Cases

Use Cases with Hostile Intent

Ian AlexanderIndependent Consultanthttp://www.scenarioplus.org.uk

What Happens if You Always Look on the Positive Side?

• At least you relax and are happy

• But you aren't ready for problems when they come up– In business, there are people who want you to fail– On projects, there are many types of cockup– In systems, there are threats and hazards all round– In software, there's a bug in every module

"If anything can go wrong, it will"(The REAL Captain Murphy, USAAF)

So, It Pays to Think Out 'Negative Scenarios'

#1 Either you think out what could happen– and what you mean to do about it

#2 Or you wait until it happens– and you find out whether it's too late to do

anything about it.

Here are some techniques for approach #1.

Understanding Negative Scenarios

• A Scenario* is a sequence of actions leading to a Goal desired by a person or organisation

• A Negative Scenario is a scenario whose Goal is– desired Not to occur by the organisation in question– desired by a hostile agent (not necessarily human)

* This is a different usage from 'four possible future business scenarios'

Negative Scenarios are Not New

'Suppose it turns and charges us before it falls into the pit'

Montignac Caves, Dordogne, France

Use Cases

• Ivar Jacobson, 1992

• Large Telecom Systems (Ericsson switches)

• Add a little bit of functionality to please some user

• Use Case = Design Feature???

• Black? or White-Box??

Use Case Diagram

• UML: like UK, USA, the Unified/United covers a multitude of sins

• Use Cases predate UML and are quite unlike much of it

• "Use Cases are fundamentally a textual form" - Alistair Cockburn

• Bubbles and Stick-Men by themselves aren't terribly informative

Drive the Car

Driver

Steer the Car

Brake the Car

includes

includes

(Unknown) Use Case Structure• Goal

– Primary Scenario• list of steps (Actor, Action)

– Alternative Paths• set of Scenarios branching from 1ry

– Exceptions• set of Scenarios, each with a triggering Event

– AOB• preconditions, trigger, results if successful, minimal

guarantees (successful or not), constraints, ...

Use Case Problems

• Many!– Fragmentation of problems (not necessarily any better

than a mass of Dataflow Diagrams)

– Functional Approach tends to ignore non-functional requirements (Constraints)

– Looking for the Primary and positive first can mean never getting around to looking for Exceptions

– Drawing little bubbles and stickmen can mean never writing Scenarios as Stories (… the Dataflow peril, again)

Misuse Cases

• Guttorm Sindre and Andreas Opdahl, 2000• Actor is a Hostile Agent• Bubble is drawn in inverted colours• Goal is a Threat to Our System• Obvious Security Applications

Drive the Car Steal the Car

Car ThiefCar Thief

threatens

A MiniMax Approach to Security

includes

Use Cases for 'Car Security'

includes

includes

threatens

mitigates

Drive the Car

Steal the Car

Lock the CarCar ThiefCar Thief

Short the Ignition

DriverDriverDriver

Lock the Transmission

threatens

mitigates

• White's Best Move … is to find out Black's Best Move, and counter it

• Seems natural to me to introduce 'threatens', 'mitigates'• Economical use of types of relationship (UML stereotypes)

Anthropomorphize … for Safety

• UML's stick-man looks like 'human agent' but can be of any type (robot, system)

• Anthropomorphizing Forces of Nature is useful: it enables us to use our Social/Soap Opera Brain to reason about threats to our systems

• Misuse Case helps to Elicit Subsystem Functions

has exception

has exception

threatens

mitigates

mitigates

Driver

Control the Car

Weather

Make Car Skid

Control Traction

Control Braking with ABS

Misuse Cases Identify NFRs

• Use Cases are weak on NFRs • Misuse Cases naturally focus on NFRs, e.g. Safety• Response is often a SubSystem Function, possibly

to handle an Exception

In terp lay o f U se & M isuse C ases w ith F un ctiona l & N on-F un ctional R equirem en ts

D river

S yste m Fu nctio n

M is us e C a se

D river

S ub-S yste m Fu nctio n

'M isuser ',S o urce o f T hrea t

'U ser '

F unctio na l R eq uire m e nts

F unctio na l R eq uire m e nts

N on -Fu nctio na l R eq u ire m e nts

Design Trade-Offs

Conflict Analysis builds upon Use/Misuse Case Modelling with additional relationships 'aggravates' and 'conflicts with'

Use Cases for 'Web Portal Security'

threatens

includes

includes

threatens

mitigates

aggravates

aggravates

threatens

mitigates

mitigates

includes

includes

includes

aggravatesthreatens

includes

includes

includes

mitigates

mitigates

mitigates

Rogue Employee

Sabotage

Service User

Access the Services

Service User

Frustrated by Controls

Security

Control Loosely

Hacker

Denial-of-Service Attack

Security

Control Strictly

Hacker

Intrude into System

Log Access AttemptsHacker

Brute-Force Password Attack

Operate Firewall

Hacker

Attack Unblocked Ports

Recognize Users

Impersonate Users

Hacker

conflicts with

A Real Example – Tube Seat Trade-Offs

The seat designers in the workshop quickly came up with 3 candidate solutions, once the conflicts were understood

threatens

threatens

threatens

aggravatesmitigates

aggravates

aggravates

threatens

mitigates

aggravates

mitigates

aggravates

mitigates

threatens

mitigates

Passenger

Sit Comfortably

AccidentCause Injury

Wear Out Seat

Wear & Tear

Misalign Locking Pin

Design Engineer

Weaken Armrest

Vandal

Break Armrest

Design Engineer

Strengthen Armrest

Design Engineer

Omit Armrest

Vandal

Slash Seat

PestHarass Women

Design Engineer

Reinforce Seat

FireBurn Seat

threatensconflicts with

threatens

Benefits of Misuse Cases• Open a new avenue of exploration

• Contribute to searching systematically for exceptions, directed by the structure of the scenarios

• Offer immediate justification for the search and indicate the priority of the requirements discovered

• By personifying and anthropomorphizing the threats, add the force of metaphor to requirements elicitation

• Make the search enjoyable and provide an algorithm for the search. Obvious parallel here with Cost/Benefit analysis

• Make the reasoning behind affected requirements immediately comprehensible

Applications of Misuse Cases

• Eliciting Security Requirements

• Eliciting Safety Requirements

• Identifying Exceptions

• Identifying Test Cases

• Design Trade-offs

Tool Support• Free Scenario Plus toolkit for DOORS

• Graphical and Textual Output (and HTML)• Automatic Linking, Metrics, etc• Automatic Creation of Referenced Use/Misuse

Cases (if user confirms)

Automatic Creation of links between Misuse and Use Cases, by searching for underlined use case names with simple fuzzy matching.

Rule-Based Linking

• Links can be specified (by underlining) from any (Mis)Use Case to any other

• Type of Link is determined by (Source, Target) Case Type, assuming you want to analyse threats/mitigations

• Other Types of Link can be specified manually

Source Case

Case Type Use Misuse

Use includes threatensTargetCase Misuse mitigates includes

Rule governing creation of relationships between Use and Misuse Cases

Summary

• Misuse Cases are a new form of an old technique• Planning has always been 'what-if'• Systems that don't plan to handle Exceptions are

planning to fail at once• Misuse Cases greatly enhance the power of Use Cases• The power of visual metaphor (black) and

anthropomorphism (stick-men) should not be underestimated

• Misuse Cases are useful throughout System Life-Cycle

About...

Ian Alexander is an independent consultant and trainer specialising in Requirements Engineering, often using DOORS. He is the author of the Elipsis 3-Day Requirements Engineering Course, and co-author of its 3-Day Systems Engineering Course. His new book 'Writing Better Requirements' will shortly be published by Addison-Wesley.

He is currently collaborating with DaimlerChrysler Research and Technology on the reuse of requirements between different series of cars. His principal research interest is in improving the requirements engineering process by modelling business goals, processes, constraints, and scenarios. This approach is supported by his Scenario Plus for Use Cases toolkit which is the subject of numerous papers.

He helps to run the BCS Requirements Engineering Specialist Group and the IEE Professional Network for Systems Engineers. He is a Chartered Engineer.