Misuse case

Example of the Misuse case principle, which could be used in thinking about capturing security requirements.

Misuse Case is a business process modeling tool used in the software development business. The term "Misuse case" or "mis-use case" has derived from use case, meaning it is the inverse of a use case.^[1] The concept was created in the 1990s by Guttorm Sindre of the Norwegian University of Science and Technology, and Andreas L. Opdahl of the University of Bergen, Norway. The basic concept is describing the steps of performing a malicious act against a system, just as you would describe an act that the system is supposed to perform in a use case.^[2]

Overview

The required behaviour of software and other products under development is often specified in Use cases, which are essentially structured stories or scenarios describing what should happen when the software or product is used. In contrast, a Misuse Case describes or at least names something that should not happen, a Negative Scenario. The threat thus posed often leads to new requirements, which again may be expressed in Use Cases.

It is argued that this modeling tool has several strengths:

• Using misuse cases as a modeling tool lets you treat non-functional requirements (e.g., typical security requirements, platform requirements, etc.) in a way more similar to functional requirements than with many other tools.
• It makes you focus on security from the very beginning, and at the same time, it helps you avoid taking premature design decisions.
• It is a very good tool for enhancing the communication between the developers and the stakeholders and is a valuable tool to use for verifying that the developer(s) and the stakeholder(s) agree on critical system solutions. This is in particular true regarding Trade-off analysis.^[3]
• Creating misuse cases will often trigger a chain reaction which makes it easier to identify both functional and non-functional requirements. The discovery of a misuse case will often lead to the creation of a new use case as a counter measure (which in turn might be subject for yet a new misuse case).^[4]
• It relates very well to both use cases and UML making employing the model more seamless than what would be the situation with many other tools.

It also has some weaknesses. Its simplicity is one of them; it often needs to be combined with more powerful tools in order to establish an adequate plan for the accomplishment of a project.^[4] One other weakness is its lack of structure and semantics.

From use to misuse case

In an industry it's 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 it format explicitly conveys each actor's goals and the flows the system must implement to accomplish them.^[6]

The level of abstraction of an 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 an use case" is 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]

Area of use

The area where misuse case are the most used is security.^{[citation needed]} Nowadays with the ever growing importance of IT system in our modern economy, the capability to protect your data has become vital for almost every company.^{[by whom?]}

When it comes to application security the "common sense" can't be used anymore.^{[by whom?]} Because hackers use most of the time black hole already present in software to gain access to something they should not have had access to.^{[citation needed]} So the best way to avoid leaving some "black holes" for malicious persons, is to take the same point of view as them and to describe what they might be able to do.^{[citation needed]}

The idea is to "draw a usecase but from a hacker's point of view". So that during the implementation phase all the behavior related to the application are known (good and bad) and can be taken in consideration to choose the good way to go.^{[citation needed]}

Basic concepts

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:

• Misuse case : A sequence of actions that can be performed by any person or entity in order to harm the system.
• Misuser : The actor that initiates the misuse case. This can either be done intentionally or inadvertently.

Diagrams

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 2 new relations to be used in the diagram:

mitigates

A use case can mitigate the chance that a misuse case will complete successfully.

threatens

A misuse case can threaten a use case, e.g. by exploiting it or hinder it to achieve its goals.

These new concepts together with the existing ones from use case gives the following meta model, which is also found as fig. 2 in Sindre and Opdahl (2004).^[2]

Descriptions

There are two different way of describing a misuse case textual; one is embedded in a use case description template - where you add an extra description field called Threats. This is the field where you fill in your misuse case steps (and alternate steps). 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:

• Misuse case name
• Summary
• Author
• Date
• Basic path
• Alternative paths
• Mitigation points
• Extension points
• Triggers
• Preconditions
• Assumptions
• Mitigation guarantee
• Related business rules
• Potential misuser profile
• Stakeholders and threats
• Terminology and explanations
• Scope
• Abstraction level
• Precision level

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 gives by Sindre and Opdahl on that matter is that it should be done as with use cases. Do it the way you feel most familiar with, since both variants each have their strengths and their weaknesses.

Sindre and Opdahl proposes the following 5 steps for using misuse cases to identify security requirements:

1. Identify critical assets in the system
2. Define security goals for each assets
3. Identify threats to each of these security goals, by identifying the stakeholders that may want to cause harm to the system
4. Identify and analyze risks for the threats, using techniques like Risk Assessment
5. Define security requirements for the risks.

It is suggested to use a repository of reusable misuse cases as a support in this 5-step process.

Research

Current field of research

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 you find a flaw, 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 ^[10] "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.

Future improvement

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 embedd 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 ^[11] 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."^[12]

See also

• Use case diagram
• Steps for Business Analyst To Gather Security Requirements from Misuse Cases [1]
• Exception handling
• Threat model (software)

References

1. ^ ^{a b c} Sindre and Opdahl (2001). "Capturing Security Requirements through Misuse Cases"
2. ^ ^{a b c} Sindre and Opdahl (2004). "Eliciting security requirements with misuse cases"
3. ^ Initial Industrial Experience of Misuse Cases in Trade-Off Analysis (2002, by Ian Alexander)
4. ^ ^{a b} Misuse cases help to elicit non-functional requirements (2003, by Ian Alexander)
5. ^ Jacobson, "Object-oriented software engineering: a use case driven approach", 1992 Addison-Wesley, Boston
6. ^ Gunnar Peterson, John Steven "Defining Misuse within the Development Process", IEEE SECURITY & PRIVACY, NOVEMBER/DECEMBER 2006
7. ^ Ian Alexander "Misuse case : use cases with hostile intent", presentation
8. ^ Guttorm Sindre, Andreas L. Opdahl, "Templates for Misuse Case Description"
9. ^ Ian Alexander "Misuse case : use cases with hostile intent"
10. ^ Raimundas Matulevičius, Nicolas Mayer, Patrick Heymans, "Alignment of Misuse Cases with Security Risk Management"
11. ^ Fabricio A. Braz, Eduardo B. Fernandez, Michael VanHilst, "Eliciting Security Requirements through Misuse Activities"
12. ^ Lillian Røstad, "An extended misuse case notation: Including vulnerabilities and the insider threat"