Misuse case is a business process modeling tool used in the software development industry. The term Misuse Case or mis-use case is derived from and is the inverse of use case.[1] The term was first used in the 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway. It describes the process of executing a malicious act against a system, while use case can be used to describe any action taken by the system.[2]
Use cases specify required behaviour of software and other products under development, and are essentially structured stories or scenarios detailing the normal behavior and usage of the software. A Misuse Case on the other hand highlights something that should not happen (i.e. a Negative Scenario) and the threats hence identified, help in defining new requirements, which are expressed as new Use Cases.
This modeling tool has several strengths:
Its biggest weakness is its simplicity. It needs to be combined with more powerful tools to establish an adequate plan for the execution of a project. One other weakness is its lack of structure and semantics.
In an industry it is important to describe a system's behavior when it responds to a request that originates from outside : the use cases [5] have become popular for requirements [1] between the engineers thanks to its features like the visual modeling technique, they describe a system from an actor's viewpoint and its format explicitly conveys each actor's goals and the flows the system must implement to accomplish them.[6]
The level of abstraction of a use case model makes it an appropriate starting point for design activities, thanks to the use of UML use case diagrams and the end user's or domain expert's language. But for software security analyses, the developers should pay attention to negative scenarios and understand them. That is why, in the 1990s, the concept of "inverse of a use case" was born in Norway.
The contrast between the misuse case and the use case is the goal: the misuse case describes potential system behaviors that a system's stakeholders consider unacceptable or, as Guttorm Sindre and Andreas L. Opdahl said, "a function that the system should not allow".[1] This difference is also in the scenarios: a "positive" scenario is a sequence of actions leading to a Goal desired by a person or organization, while a "negative" one is a scenario whose goal is desired not to occur by the organization in question or desired by a hostile agent (not necessarily human).[7]
Another description of the difference is by [8] that defines a use case as a completed sequence of actions which gives increased value to the user, one could define a misuse case as a completed sequence of actions which results in loss for the organization or some specific stakeholder.
Between the "good" and the "bad" case the language to represent the scenario is common: the use case diagrams are formally included in two modeling languages defined by the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language (SysML), and this use of drawing the agents and misuse cases of the scenario explicitly helps focus attention on it.[9]
Misuse case are most commonly used in the field of security.[10] With the ever-growing importance of IT system, it has become vital for every company to develop capability to protect its data.[11]
Hence, for example a misuse case might be used to define what a hacker would want to do with the system and define his or her requirements. A developer or designer can then define the requirements of the user and the hacker in the same UML diagram which in turn helps identify the security risks of the system.[12]
A misuse case diagram is created together with a corresponding use case diagram. The model introduces 2 new important entities (in addition to those from the traditional use case model, use case and actor:
The misuse case model makes use of those relation types found in the use case model; include, extend, generalize and association. In addition, it introduces two new relations to be used in the diagram:
These new concepts together with the existing ones from use case give the following meta model, which is also found as fig. 2 in Sindre and Opdahl (2004).[2]
There are two different ways of describing a misuse case textual; one is embedded in a use case description template - where an extra description field called Threats can be added. This is the field where misuse case steps (and alternate steps) can be filled in. This is referred to as the lightweight mode of describing a misuse case.
The other way of describing a misuse case, is by using a separate template for this purpose only. It is suggested to inherit some of the field from use case description (Name, Summary, Author and Date). It also adapts the fields Basic path and Alternative path, where they now describe the paths of the misuse cases instead of the use cases. In addition to there, it is proposed to use several other fields too:
As one might understand, the list above is too comprehensive to be completely filled out every time. Not all the fields are required to be filled in at the beginning, and it should thus be viewed as a living document. There has also been some debating whether to start with diagrams or to start with descriptions. The recommendation given by Sindre and Opdahl on that matter is that it should be done as with use cases.
Sindre and Opdahl proposes the following 5 steps for using misuse cases to identify security requirements:
It is suggested to use a repository of reusable misuse cases as a support in this 5-step process.
Current research on misuse cases are primarily focused on the security improvements they can bring to a project, software projects in particular. Ways to increase the widespread adoption of the practice of misuse case development during earlier phases of application development are being considered: the sooner a flaw is found, the easier it is to find a patch and the lower the impact is on the final cost of the project.
Other research focuses on improving the misuse case to achieve its final goal: for [13] "there is a lack on the application process, and the results are too general and can cause a under-definition or misinterpretation of their concepts". They suggest furthermore "to see the misuse case in the light of a reference model for information system security risk management (ISSRM)" to obtain a security risk management process.
The misuse cases are well known by the population of researchers. The body of research on the subject demonstrate the knowledge, but beyond the academic world, the misuse case has not been broadly adopted.
As Sindre and Opdahl (the parents of the misuse case concept) suggest: "Another important goal for further work is to facilitate broader industrial adoption of misuse cases".[2] They propose, in the same article, to embed the misuse case in a usecase modeling tool and to create a "database" of standard misuse cases to assist software architects. System stakeholders should create their own misuse case charts for requirements that are specific to their own problem domains. Once developed, a knowledge database can reduce the amount of standard security flaws used by lambda hackers.
Other research focused on possible missing concrete solutions of the misuse case: as [14] wrote "While this approach can help in a high level elicitation of security requirements, it does not show how to associate the misuse cases to legitimate behavior and concrete assets; therefore, it is not clear what misuse case should be considered, nor in what context". These criticisms might be addressed with the suggestions and improvements presented in the precedent section.
Standardization of the misuse case as part of the UML notation might allow it to become a mandatory part of project development. "It might be useful to create a specific notation for security functionality, or countermeasures that have been added to mitigate vulnerabilities and threats."[15]
