Misuse CasesUse Cases with Hostile IntentIan AlexanderA version of this article appeared in IEEE Software, January 2003Humans have analyzed negative scenarios ever since they first sataround Ice Age campfires debating the dangers of catching a woollyrhinoceros: 'What it turns and charges us before it falls into the pit?' A more recentscenario is 'What if the hackers launch a denial-of-service attack?'. Modern systemsengineers can employ a misuse case–the negative form of a use case–to document andanalyze such scenarios1-3. A Misuse Case is simply a Use Case from the point of view of anActor hostile to the system under design. Misuse Cases turn out to have many possible applications, and tointeract with Use Cases in interesting and helpful ways.Eliciting Security RequirementsSecurity Requirements exist because people and agents that they create (such as computer viruses) pose realthreats to systems. Security differs from all other specification areas as someone is deliberately threatening tobreak the system. Employing Use and Misuse Cases to model and analyze scenarios in systems under designcan improve security by helping to mitigate threats.Some misuse cases occur in highly specific situations, whereas others continually threaten systems. Forinstance, a car is most likely to be stolen when parked and unattended; whereas a Web server might suffer adenial-of-service attack at any time.You can develop misuse and use cases recursively, going from system to subsystem levels or lower asnecessary. Lower-level cases can highlight aspects not considered at higher levels, possibly forcing anotheranalysis. The approach offers rich possibilities for exploring, understanding, and validating the requirements inany direction. Drawing the agents and misuse cases explicitly helps focus attention on the elements of the12/23/2009 Misuse Cases…easynet.co.uk/…/misuse_cases_hostil… 1/11scenario.Figure 1. Use/misuse-case diagram of car security requirements. Use-case elements appear on the left; the misuse cases are on the right.Let's compare Figure 1 to games such as chess or Go. A team's best move consists of thinking ahead to theother team's best move and acting to block it. In Figure 1, if the misuse being threatened is the theft of a car,the White player is the lawful Driver and the Black player is the Car Thief. The driver's freedom to drive thecar is at risk if the thief can steal the car. So, the driver needs to be able to lock the car – a derivedrequirement, which mitigates the threat. This is at the top level of the analysis. The next level is started byconsidering the thief's response. If this is to break into the car and to short the ignition, thus defeating the lock,a mitigating approach – as for instance locking the transmission, or requiring a digital code from the key toauthenticate the driver – is required. In this way, what starts out as an apparently simple hardware-only designmay call for software subsystems. Threats to e-commerce and other commercial systems can be morecomplex, but may be analysed in the same way.Figure 1 also shows that threat and mitigation form a balanced zigzag pattern of play and counterplay. This"game" can be reflected in an inquiry cycle style of development. Both use and misuse cases may includesubsidiary cases of their own kind, but their relationships to cases of the opposite kind are never simpleinclusion. Instead, Misuse Cases threaten Use Cases with failure, and appropriate Use Cases can mitigateknown Misuse Cases.Where such mitigation approaches are already known, development may proceed by selecting which possibledesign features can be afforded – transmission locks cost money and cannot necessarily be provided on allmodels of car. So, there is a trade-off between the user requirements (countering misuse) and the constraints(e.g. cost, weight, size, development schedule).Where suitable mitigation approaches are not yet known, development and Use/Misuse Case analysis canproceed together, initially but not exclusively top-down. Possible mitigation approaches can be identified,studied, prototyped, evaluated and then selected if suitable. Mitigations may demand new subsystems orcomponents; the existence of these new devices may in turn engender new types of threat. These threats canbe analysed in their turn to evaluate the need for further counter-measures. In this situation, analysis anddesign are intertwined as the design choices crystallize and the system requirements can be stated morespecifically.Security threats are rarely neutralized completely by mitigation measures. Thieves pick locks and break intosystems through unsuspected access paths. Partial mitigations are still useful as long as they afford a realisticincrease in protection at reasonable cost. The goal of neutralizing all possible threats is of course wishfulthinking and cannot be stated as a requirement.For example, drivers often do not lock their cars when they stop and leave their vehicles for short periods.12/23/2009 Misuse Cases…easynet.co.uk/…/misuse_cases_hostil… 2/11They may even leave their keys in the ignition and the engine running, presenting thieves with excellent if briefopportunities. Can designers protect against this sort of misuse? There are plainly more cases to consider thanthose diagrammed above. Even a regular Use Case such as 'Stop at Traffic Signal' presents an opportunityfor theft.Safety Requirements from Failure CasesMisuse Cases are not limited to eliciting Security Requirements, or threats from human agents.Karen Allenby and Tim Kelly describe a method for eliciting and analysing functional safety requirements foraero-engines using what they call 'use cases' [Allenby & Kelly 2001]. They are of course well aware of therange of conventional hazard analysis techniques, but observe that functional hazards should be intimatelyderived from system requirements: it is inappropriate for safety engineers to go away and invent functions bythemselves. Therefore they perceive a need for a method of deriving hazards from known system functions,proposing use cases for this purpose. They do not suggest the use of negative agents associated with their usecases. Their method is to tabulate the failures, their causes, types, and effects, and then possible mitigations.They observe that mitigations often involve subsystems, i.e. the procedure implies a recursive decomposition.However, since their 'use cases' describe potentially catastrophic failures and