Misuse case - AbsoluteAstronomy.com

Misuse Case is a business process modeling

Business process modeling

Business Process Modeling in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analyzed and improved. BPM is typically performed by business analysts and managers who are seeking to improve process efficiency and quality...

tool used in the software development business. The term "Misuse case" or "mis-use case" has derived from use case

Use case

In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...

, meaning it is the inverse of a use case. The concept was created in the 1990s by Guttorm Sindre of the Norwegian University of Science and Technology

Norwegian University of Science and Technology

The Norwegian University of Science and Technology , commonly known as NTNU, is located in Trondheim. NTNU is the second largest of the eight universities in Norway, and, as its name suggests, has the main national responsibility for higher education in engineering and technology...

, and Andreas L. Opdahl of the University of Bergen

University of Bergen

The University of Bergen is located in Bergen, Norway. Although founded as late as 1946, academic activity had taken place at Bergen Museum as far back as 1825. The university today serves more than 14,500 students...

, 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.

Overview

The required behaviour of software and other products under development is often specified in Use case

Use case

In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...

s, 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.
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 well to both use cases and UML
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

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.

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 have become popular for requirements 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.

The level of abstraction of an use case model

Use case diagram

A use case diagram in the Unified Modeling Language is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals , and any dependencies between those use...

makes it an appropriate starting point for design activities, thanks to the use of UML

Unified Modeling Language

Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...

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

1990s

File:1990s decade montage.png|From left, clockwise: The Hubble Space Telescope floats in space after it was taken up in 1990; American F-16s and F-15s fly over burning oil fields and the USA Lexie in Operation Desert Storm, also known as the 1991 Gulf War; The signing of the Oslo Accords on...

, the concept of "inverse of an use case" is born in Norway

Norway

Norway , officially the Kingdom of Norway, is a Nordic unitary constitutional monarchy whose territory comprises the western portion of the Scandinavian Peninsula, Jan Mayen, and the Arctic archipelago of Svalbard and Bouvet Island. Norway has a total area of and a population of about 4.9 million...

.

The contrast between the misuse case and the use case

Use case

In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...

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".
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).

Another description of the difference is by 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

Object Management Group

Object Management Group is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on modeling and model-based standards.- Overview :...

: the Unified Modeling Language

Unified Modeling Language

(UML) and the Systems Modeling Language

Systems Modeling Language

The Systems Modeling Language is a general-purpose modeling language for systems engineering applications. It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems. SysML was originally developed by an open source specification...

(SysML), and this use of drawing the agents and misuse cases of the scenario explicitly helps focus attention
on it.

Area of use

The area where misuse case are the most used is security. Nowadays with the ever growing importance of IT system in our modern economy, the capability to protect data has become vital for almost every company.

When it comes to application security the "common sense" can't be used anymore. 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. 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.

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.

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).

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:

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
Risk assessment
Risk assessment is a step in a risk management procedure. Risk assessment is the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat...
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.

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 "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". 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 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."

Overview

From use to misuse case

Area of use

Basic concepts

Diagrams

Descriptions

Current field of research

Future improvement

See also