Misuse Cases
In my previous article “What is security,” I wrote about software security. In it, I tried to illustrate two statements.
The first statement is that security is a non-functional property of a program, and is determined not by what the program does, but by what it does not.
The second statement, which is very closely related to the first, is that the “security functions” are anti-functions: they take away opportunities from users who should not have access to some software functionality.
In particular, this means that security functions, as one of the means to achieve this security itself, cannot be described by the same methods that describe “normal”, basic functionality. For this purpose, other approaches should be used. To date, several methods have been proposed to solve this problem. One of the most popular of these is the method of abuse options - misuse cases - which this article is devoted to.
The method of describing and analyzing security requirements using abuse options was first proposed more than 10 years ago. The authors are two specialists: Guttorm Sindre and Andreas Lothe Opdahl [1]. Subsequently, they also significantly developed this method [2,3,4]. Another specialist, Ian Alexander added the author's approach, proposed new applications [5,6,7]. Anyone who is interested and would like to seriously get acquainted with the use of abuse options, I recommend reading the articles on the links. I also recommend using the search on the Internet and see the latest materials, as the method continues to be researched and developed.
For the rest, I will try to briefly describe this approach and demonstrate its use with a very simple, trivial example.
I think everyone who is reading this article now knows that the functional requirements for the software are often described with the help of use cases, use cases. Each use case is a sequence of actions in which, from the beginning to the end, the legitimate user will solve one of his tasks, achieve one of his goals, using the functions of the program. That is, use cases describe what the program should do.
But we want to describe what the program should not do. For this and serve options abuse.
Abuse options are extensions of use cases. With each such option, the way in which an intruder can achieve one of his goals is described, while causing damage to the system’s owner.
Together with abuse options, use cases are created that describe the effect of security functions designed to prevent unwanted use of the program.
As with use cases, abuse options can be presented both in graphic and in test form. Of course, as with pure use cases, any combination of graphical diagrams and text is permissible.
In the graphical presentation of information, abuse options are drawn together with use cases. So that they differ among themselves, several new elements and several relations between them are added to represent the first.
First, the element is added, meaning the offender. If the same person can act both as a legitimate user and as an intruder, he appears on the diagram twice, once as a legitimate user, and a second time as an intruder. Graphically, the intruder is indicated in the same way as the legitimate user, but is highlighted in a different color.
Secondly, the element designating the purpose of the violator is added. This element - a variant of abuse - is indicated in the same way as the purpose of the legitimate user - the use case. In order to distinguish the use case from the abuse case, the latter is indicated in a different color, just like the intruder.
Thirdly, two relationships are added. The relation “threaten” refers to the fact that this intruder’s goal can be achieved using this system functionality. The “mitigate” relationship refers to the fact that this security feature is used to reduce the risk of this abuse option.
In the textual representation of abuse options, templates are introduced that correspond to new graphic elements, and new fields in templates that correspond to new relations.
These extensions are quite enough to describe the functional security requirements.
To get acquainted with the method, let's consider an extremely simplified example.
Suppose we have a program that makes it possible to read a certain document.
Obviously, anyone, including the unauthorized, user can read the same document using the same functionality. Add a description of this fact to the diagram.
So we got a description of the existing vulnerability in our program: the ability for an unauthorized user to gain access to a confidential document. And we want to find an opportunity to eliminate it.
We can decide that access control can prevent the use of functions in a way that is harmful to us. To control access, we need to pre-authenticate the user. We require the user to enter a name and password.
After analyzing the resulting project, we note that authentication can be circumvented by selecting a password. Add this fact to the chart.
To eliminate the detected vulnerability, we will require the program to detect several consecutive unsuccessful attempts to enter a password and block the corresponding user.
The analysis of the received project shows that the intruder, possibly different from the first, got the opportunity to block the work of an authorized user.
Suppose at this stage we decided that we can allow such a lock. Since there are no vulnerabilities to be fixed, the analysis can be considered complete.
Thus, we received a description: the functionality of the program associated with this functionality weaknesses and security features designed to reduce the vulnerability of the program. The diagram also indicates the vulnerabilities of the program, the existence of which is recognized as valid.
')
The example given in the previous section is extremely primitive, not complete. To illustrate the work with the method of greater and not necessary. But I would still like to draw attention to the missing information, which is fundamentally necessary for an adequate analysis of the functional safety requirements.
Not enough business context.
Let us recall that with the help of abuse options we describe the ways in which the violator:
Therefore, first of all we must understand who may be interested in attacking the program being developed, and what are its goals, resources, and opportunities. There may be several groups of potential violators that differ in these parameters.
We also need to understand which events may damage the program owner, assess their degree of harmfulness.
Obviously, the business context must be understood and described before the modeling begins.
The architecture of the simulated application is not defined.
We note first that in the example we decided to use access control as a protection mechanism, and this entailed the need for authentication. We could decide that data encryption could be used in this situation. Having supplied all legitimate users with keys, we would receive a system that would be comparable in security with that obtained in the example. That is, it is obvious that the two solutions are not equivalent, but so far no information has been provided that would allow to choose from two possible protection options.
Indeed, let's look at two options for the architecture.
Let in the first case of diagrams describe a system that will work on a server located in a protected room; users will only have remote access and only using the described functionality. Access control in this case is likely to be the best solution.
In the second case, let us imagine that the program will work on the user's personal laptop and its main task will be to protect the document when the media is stolen. Probably in this case, encryption is the best of the two solutions.
Note that architecture dependency is one of the manifestations of the non-functional nature of security.
In our simple example, this dependence is obvious, and it is easy to notice. In a more complex situation, interdependence may be more subtle, and its identification will be a difficult task. Security may depend on the physical characteristics of the system: where the information is entered, where it is stored, processed, how it is transmitted. Security can also depend on the logical architecture: on the functionality of the individual components of the system, on their interconnections.
Part of the architecture is already known at the very beginning of the project, and remains unchanged. Another part of the architecture is developed based on an analysis of the functional requirements, and this part of the architecture may change somewhat during the course of the project. In turn, these changes may necessitate a return to the analysis of the requirements for security functions.
Virtues
One of the most important advantages of the method is that it is built as an extension of an existing, time-tested, widely understood method of describing functionality. This means that the description made using abuse options will be clear to both developers and the customer.
Another very important advantage is that the method makes it easy to track the relationship between the main function and the security functions that need to be added to the program in order to prevent abuse. Thus, we can postpone the implementation of the security function until it is really needed.
disadvantages
The disadvantage of the method is that it is an extension of the standard description method. And, if you use automated use cases, then it may turn out that the program that you are using does not support this extension. Then you will have to either abandon the abuse options, or abandon automation, at least in part.
But the main drawback of the method, in my opinion, is an excessive focus on the description of the functionality. A large amount of information on which the adoption of a decision on protective measures depends to a large extent is located in other documents and on other diagrams.
The method can trigger decision-making without taking into account all the available information, or even before security-critical decisions about the application architecture are made.
The method of abuse options is a tool with its own advantages and disadvantages. Like any other tool, it is good for solving a certain range of tasks and using it correctly.
There are other methods for describing and analyzing security requirements. They can be used both as an alternative to the one described and in conjunction with it. But this is a topic for other articles.
The first statement is that security is a non-functional property of a program, and is determined not by what the program does, but by what it does not.
The second statement, which is very closely related to the first, is that the “security functions” are anti-functions: they take away opportunities from users who should not have access to some software functionality.
In particular, this means that security functions, as one of the means to achieve this security itself, cannot be described by the same methods that describe “normal”, basic functionality. For this purpose, other approaches should be used. To date, several methods have been proposed to solve this problem. One of the most popular of these is the method of abuse options - misuse cases - which this article is devoted to.
Where is it described
The method of describing and analyzing security requirements using abuse options was first proposed more than 10 years ago. The authors are two specialists: Guttorm Sindre and Andreas Lothe Opdahl [1]. Subsequently, they also significantly developed this method [2,3,4]. Another specialist, Ian Alexander added the author's approach, proposed new applications [5,6,7]. Anyone who is interested and would like to seriously get acquainted with the use of abuse options, I recommend reading the articles on the links. I also recommend using the search on the Internet and see the latest materials, as the method continues to be researched and developed.
For the rest, I will try to briefly describe this approach and demonstrate its use with a very simple, trivial example.
Expansion of use cases
I think everyone who is reading this article now knows that the functional requirements for the software are often described with the help of use cases, use cases. Each use case is a sequence of actions in which, from the beginning to the end, the legitimate user will solve one of his tasks, achieve one of his goals, using the functions of the program. That is, use cases describe what the program should do.
But we want to describe what the program should not do. For this and serve options abuse.
Abuse options are extensions of use cases. With each such option, the way in which an intruder can achieve one of his goals is described, while causing damage to the system’s owner.
Together with abuse options, use cases are created that describe the effect of security functions designed to prevent unwanted use of the program.
As with use cases, abuse options can be presented both in graphic and in test form. Of course, as with pure use cases, any combination of graphical diagrams and text is permissible.
In the graphical presentation of information, abuse options are drawn together with use cases. So that they differ among themselves, several new elements and several relations between them are added to represent the first.
First, the element is added, meaning the offender. If the same person can act both as a legitimate user and as an intruder, he appears on the diagram twice, once as a legitimate user, and a second time as an intruder. Graphically, the intruder is indicated in the same way as the legitimate user, but is highlighted in a different color.
Secondly, the element designating the purpose of the violator is added. This element - a variant of abuse - is indicated in the same way as the purpose of the legitimate user - the use case. In order to distinguish the use case from the abuse case, the latter is indicated in a different color, just like the intruder.
Thirdly, two relationships are added. The relation “threaten” refers to the fact that this intruder’s goal can be achieved using this system functionality. The “mitigate” relationship refers to the fact that this security feature is used to reduce the risk of this abuse option.
In the textual representation of abuse options, templates are introduced that correspond to new graphic elements, and new fields in templates that correspond to new relations.
These extensions are quite enough to describe the functional security requirements.
Simplest system
To get acquainted with the method, let's consider an extremely simplified example.
Suppose we have a program that makes it possible to read a certain document.
Obviously, anyone, including the unauthorized, user can read the same document using the same functionality. Add a description of this fact to the diagram.
So we got a description of the existing vulnerability in our program: the ability for an unauthorized user to gain access to a confidential document. And we want to find an opportunity to eliminate it.
We can decide that access control can prevent the use of functions in a way that is harmful to us. To control access, we need to pre-authenticate the user. We require the user to enter a name and password.
After analyzing the resulting project, we note that authentication can be circumvented by selecting a password. Add this fact to the chart.
To eliminate the detected vulnerability, we will require the program to detect several consecutive unsuccessful attempts to enter a password and block the corresponding user.
The analysis of the received project shows that the intruder, possibly different from the first, got the opportunity to block the work of an authorized user.
Suppose at this stage we decided that we can allow such a lock. Since there are no vulnerabilities to be fixed, the analysis can be considered complete.
Thus, we received a description: the functionality of the program associated with this functionality weaknesses and security features designed to reduce the vulnerability of the program. The diagram also indicates the vulnerabilities of the program, the existence of which is recognized as valid.
')
What is missing in this example
The example given in the previous section is extremely primitive, not complete. To illustrate the work with the method of greater and not necessary. But I would still like to draw attention to the missing information, which is fundamentally necessary for an adequate analysis of the functional safety requirements.
Not enough business context.
Let us recall that with the help of abuse options we describe the ways in which the violator:
- reaches its goals;
- harms the owner of the system.
Therefore, first of all we must understand who may be interested in attacking the program being developed, and what are its goals, resources, and opportunities. There may be several groups of potential violators that differ in these parameters.
We also need to understand which events may damage the program owner, assess their degree of harmfulness.
Obviously, the business context must be understood and described before the modeling begins.
The architecture of the simulated application is not defined.
We note first that in the example we decided to use access control as a protection mechanism, and this entailed the need for authentication. We could decide that data encryption could be used in this situation. Having supplied all legitimate users with keys, we would receive a system that would be comparable in security with that obtained in the example. That is, it is obvious that the two solutions are not equivalent, but so far no information has been provided that would allow to choose from two possible protection options.
Indeed, let's look at two options for the architecture.
Let in the first case of diagrams describe a system that will work on a server located in a protected room; users will only have remote access and only using the described functionality. Access control in this case is likely to be the best solution.
In the second case, let us imagine that the program will work on the user's personal laptop and its main task will be to protect the document when the media is stolen. Probably in this case, encryption is the best of the two solutions.
Note that architecture dependency is one of the manifestations of the non-functional nature of security.
In our simple example, this dependence is obvious, and it is easy to notice. In a more complex situation, interdependence may be more subtle, and its identification will be a difficult task. Security may depend on the physical characteristics of the system: where the information is entered, where it is stored, processed, how it is transmitted. Security can also depend on the logical architecture: on the functionality of the individual components of the system, on their interconnections.
Part of the architecture is already known at the very beginning of the project, and remains unchanged. Another part of the architecture is developed based on an analysis of the functional requirements, and this part of the architecture may change somewhat during the course of the project. In turn, these changes may necessitate a return to the analysis of the requirements for security functions.
Advantages and disadvantages
Virtues
One of the most important advantages of the method is that it is built as an extension of an existing, time-tested, widely understood method of describing functionality. This means that the description made using abuse options will be clear to both developers and the customer.
Another very important advantage is that the method makes it easy to track the relationship between the main function and the security functions that need to be added to the program in order to prevent abuse. Thus, we can postpone the implementation of the security function until it is really needed.
disadvantages
The disadvantage of the method is that it is an extension of the standard description method. And, if you use automated use cases, then it may turn out that the program that you are using does not support this extension. Then you will have to either abandon the abuse options, or abandon automation, at least in part.
But the main drawback of the method, in my opinion, is an excessive focus on the description of the functionality. A large amount of information on which the adoption of a decision on protective measures depends to a large extent is located in other documents and on other diagrams.
The method can trigger decision-making without taking into account all the available information, or even before security-critical decisions about the application architecture are made.
Conclusion
The method of abuse options is a tool with its own advantages and disadvantages. Like any other tool, it is good for solving a certain range of tasks and using it correctly.
There are other methods for describing and analyzing security requirements. They can be used both as an alternative to the one described and in conjunction with it. But this is a topic for other articles.
Literature
- G. Sindre and AL Opdahl, “Eliciting Secutiry Requirements by Misuse Cases”, Proc. TOOLS Pacific 2000, Nov 2000.
- G. Sindre and AL Opdahl, “Template for Misuse Case Description”, International Workshop Requirements Engineering: Foundation for Software Quality (REFSQ 2001), 2001.
- G. Sindre, AL Opdahl, and GF Brevik, “Generalization / Specialization of a Cause for a Symposium on Requirements Engineering for Information Security, 2002.
- G. Sindre and AL Opdahl, “Eliciting Security Requirements with Misuse Cases” Requirements Engineering Journal, 10 (1): 34–44, 2005.
- I. Alexander, “Modeling the Interplay of Conflicting Goals” , Proceedings Eighth International Workshop on Requirements Engineering: Foundation for Software Quality, September 2002
- I. Alexander, “Initial Industrial Experience of Misuse Cases in Trade-Off Analysis” , Proceedings of the IEEE Joint International Requirements Engineering Conference, September 2002
- I. Alexander, “Misuse Cases: Use Cases with Hostile Intent” IEEE Software, 2003
Source: https://habr.com/ru/post/117218/
All Articles