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.