Misuse Case. Determine Dangers Faced by the System.
What do you need Misuse Cases for? What advantages do they offer and how are misuse cases created?
Misuse cases are "upside down" use cases with which to collect features that the system should not allow. This way, you can find security measures that increase the quality of the system.
A misuse case can attack a use case. On the other hand, a use case is in the position to weaken or prevent misuse cases. That is why there are two new types of relationships in the use case diagram.
A misuse case is always linked with a misactor: A person who, deliberately or accidentally, causes damage to the system.
What does the software have to be able to do? Which features should it provide? These are typical questions that requirements engineering attempts to clarify. For this, use cases are created and normally the use case diagram is used to visualize it. But what about about stakeholders’ goals and desires that don’t fit into that? “The system must be completely secure!” is an example of something your customers might say. Good, you think, and create a security requirement that should increase the quality of the system. But this is rather broadly described and difficult to examine. Could a use case be formed from this? Unfortunately, the answer to this is: no, use cases are only recommended for functional requirements – so, descriptions of implementable features. To be able to derive quality requirements (non-functional requirements), you have to think the other way around – what should the system NOT be able to do? Or in this case: what should the system hinder so that it is secure? And then misuse cases come into play.
Use Our Tool with Templates for Misuse Cases and Misactors
Learn more about requirements modeling
with objectiF RPM or objectiF RM »
What Is a Misuse Case?
Misuse cases were described for the first time in 2001 by Guttorm Sindre and Andreas Opdahl, two Norwegian professors in the area of information system development, for requirements in the area of system security. They explained the known requirements process with use cases and use cases diagrams. A misuse case can be imagined as an inside-out use case – so, a feature that should not be implementable in a system. It offers another viewpoint of the system to manage security requirements. Above all, these requirements are very meaningful according to the Kano model of stakeholder satisfaction.
Advantages of Misuse Cases
Quality is increased because non-functional requirements are noticed
Developers and customers can better understand the system
Model is easy to understand and use
Measures are immediately visible because risks and counter-measures are visualized
Risk analysis is possible early on
Risks can be recognized customer-specifically
Traceability is ensured because features to increase security have to be revised
A short and sweet definition of a misuse case:
A misuse case describes features the system cannot allow.
They are needed to determine non-functional requirements, like security requirements.
A misuse case is always linked with a misactor
How Are Misuse Cases Created?
Misuse cases, like use cases, are collected in text with the help of a template in a use case specification. The name and the description are the minimum amount of necessary information. You can also enter the flow that leads to the success of the misuse cases and so to the failure of the system. Apart from that, the inside-out use case can also be presented in a use case diagram. Like with use cases, it is recommended to use both methods.
The creation of misuse cases is closely linked to the creation of use cases and therefore with the requirements engineering. When modelling use cases, it is best to link them in with misuse cases straight away. This way, you keep an overview of the features, but also of the risks to the system. The creation of the diagram with the use cases, misuse cases and their relationship to each other occurs in an iterative process.
The creation process is composed of the following steps:
- Determine the functionality of the system and create use cases
- Identify the system’s risks or threatening actors and create misuse cases and misactors
- Link misuse cases with the use cases that they endanger
- Determine the features that misuse cases could prevent, and link them with use cases
- Repeat steps 1 – 4 and refine the use cases and misuse cases
Like with use cases, you can also examine misuse cases through test cases so that you can create test cases with the modelling of the use case diagrams. Except with misuse cases, you check that an undesired feature can be successfully prevented.
Incidentally, it is also possible to consider misuse cases more abstractly. For example, an actor can become a misactor if they are exposed to a bad user interface:
Misuse Cases in Comparison with Use Cases
Properties of a Use Case
Can be derived from functional requirements
Creates value for the organization or stakeholders
Can be recorded purely textually and/or in a use case diagram
Is linked with an actor
Is linked with use cases through include relationships
Is linked with use cases through extend relationships
Can be checked with test cases (Is the feature fulfilled?)
Properties of a Misuse Case
Can be derived from non-functional requirements (Quality requirements)
Prevents loss of value for the organization or stakeholders
Can be recorded purely textually and/or in a use case diagram
Is linked to a misactor
Linked with use cases through attack relationships
Linked with use cases through prevent relationships
Can be checked with test cases (undesired functionality prevented)
Relationship between a Misuse Case and a Use Case
Misuse cases communicate with use cases. For this connection, you support yourself on contain relationships and expand relationships that are already known from the use case diagram. As explained already, a misuse case can threaten the functionality of a use case. For such a relationship, the include relationship will then be modified and provided with a signal word like threatens or attacks.
If a use case stops a misuse case or can neutralize it to a certain degree, then you link this use case with an extend relationship and the signal word mitigates or prevents.
Use Our Tool with Templates for Misuse Cases and Misactors
Try objectiF RPM or objectiF RM free of charge for 30 days »
Example of Misuse Cases in a Use Case Diagram
A car owner would like to secure their vehicle by doing it through the Keyless Go technology. A thief, on the other hand, would like to steal the car – they endanger the system and are therefore a misactor. This works for the thief as long as they can break the lock of the vehicle or intercept the radio signal of the keyless go system. Because the thief could intercept the signal to lock the car, this misuse case endangers the use case Lock car keyless and an attack relationship arises. From both use cases, the system derives a quality requirement: it has to recognize the duration of the signal transfer so as to be able to recognize an attack by a third party.
At the same time, the use case Lock vehicle keyless stops the thief from stealing the vehicle – a prevent relationship links both use cases.
Use misuse cases for your projects
A system doesn’t just consist of features that you can directly implement. Instead, you encounter the requirements of your stakeholders that concern quality and performance features like scalability, security or reliability. Unfortunately, such non-working requirements as these are difficult to formulate as use cases. Only with misuse cases can you get a view of your system that also covers quality features – above all, concerning security. And that way develop the system right the first time. Use a tool that offers a textual template for creating misuse cases and generates use case diagrams to visualize the relationship between your use cases, misuse cases, actors, misactors and their relationships with each other.
Try it out right now. Free for 30 days!