Dictionary Thesaurus Word Dynamo Quotes Reference Translator Spanish

Misuse case

Misuse Case has derived from Use case ("it is the inverse of a use case), and is a modeling tool used in the software development business. The concept was created by Guttorm Sindre (Norwegian University of Science and Technology) and Andreas L. Opdahl (University of Bergen, Norway). The basic concept is describing the steps of performing a malicious act against a system, just as you would describe act that the system is supposed to do in a use case.

Basic concepts

A misuse case diagram is created 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 takes 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:mitigate: 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 Eliciting security requirements with misuse cases (2004, by Sindre and Opdahl):

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 over 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

A detailed discussion on this subject can be found at Eliciting security requirements with misuse cases and Capturing Security Requirements through Misuse Cases (both articles by Sindre and Opdahl).

As one might understand, the list above is too comprehensive to be completely filled out every time. Not all the fields are requires filled in at the beginning, and it should thus be viewed upon 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 mattes, is that it should be done like with use case. Do it the way you feel most familiar with, since both variants have both their strengths and their weaknesses.

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

Identify critical assets in the system
Define security goals for each assets
Identify threats to each of these security goals, by identifying the stakeholders that may want to cause harm to the system
Identify and analyze risks for the threats, using techniques like Risk Assessment
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.

Discussions

It is argued that this modeling tool has several strengths:

Using misuse cases as modeling tool lets you treat non-functional requirements (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, at the same time as 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 thus 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.
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).
It relates very good to both Use Case 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. One other weakness is its lack of structure and semantics.