We investigate security at the same time as the functional requirements by refining and integrating use, misuse, and mitigation use cases. Security requirements rely on the interactions among normal system execution (use cases), attacks (misuse cases), and necessary security strategies (mitigation use cases), but previous approaches only use a high-level of abstraction. We use refinement to uncover details of each case and the relationships among them before integrating them. We identify and model “includes” and “extends” relationships within each refined case type, and use a condition-driven process that maintains these relationships as refinement continues. We then systematically identify and model “threatens” and “mitigates” relationships to integrate the cases at a detailed level.
An issue with software security is the accuracy and consistency of the requirements. Software security is often investigated after other development stages are complete, thus overlooked or not investigated with the resources that it needs to be successful [
Security is needed in the requirements phase so that work that takes place later in the development process can be based on functional and security requirements. The most popular approach is misuse case modeling [
Our methodology combines misuse case modeling and requirements refinement. Our approach includes three phases. In the first phase, we identify the refined cases from high-level textual descriptions and model “includes” and “extends” relationships. In the second phase, we refine each case type with emphasis on maintenance of “includes” and “extends” relationships. In the third phase, the “threatens” and “mitigates” relationships are identified and modeled among the use/misuse/mitigation use cases.
This paper is structured where Section 2 covers related work. Section 3 covers our approach to refining each case type. Section 4 covers how we maintain the “includes” and “extends” relationships. Section 5 covers the process of identifying, modeling, and maintaining the “threatens” and “mitigates” relationships. We conclude in Section 6.
Misuse cases have roots in traditional use cases to model possible system attackers. Once fully modeled with mitigation use cases, use cases and misuse cases play a game of “cat and mouse” within the model where misuse cases threaten use cases and mitigation use cases prevent misuse cases. A misuse case is simply a use case from the point of view of an actor hostile to the system [
Use case refinement has been successfully applied previously in varying areas of software development; namely user interface design [
Previous refinement efforts do not have explicit steps for guidance, thus these ad-hoc approaches do not produce accurate or consistent refined cases. Our approach is made up of exact steps and conditions that produce details concerning the interplay among uses, misuses, and mitigations. This section introduces refinement concerned with one case type (use, misuse, or mitigation) alone and what happens as they are refined as introduced in
In
1) Identify candidate cases from the high-level textual description.
2) Create initial textual descriptions for each refined case.
3) Identify if any “includes” relationship exists and how to model it for refined cases.
4) Identify if any “extends” relationship exists and how to model it for refined cases.
5) Identify and model appropriate actor assignments for each refined case.
The details of using the “includes” relationship will be introduced in Section 3.1 while the details of the “extends” relationship will be introduced in Section 3.2. Actor assignments will be introduced in Section 3.3.
“Includes” relationships should only be used after a textual description has been written for each use case [
1) Check the refined cases for any “includes” relationship by using custom conditions. This check involves inspecting the preconditions and steps of the refined cases.
2) Identify the refined case that accounts for the common or shared behaviors from the textual descriptions of the refined cases. This is the “included” case.
3) Revise steps in the textual descriptions of the refined cases to reference the “included” case.
4) Model the refined cases per the updated textual descriptions.
The conditions we use to identify “includes” relationships are listed below.
1) If two or more cases share steps that are already accounted for by another refined case, then an “includes” relationship is needed among those refined cases. For example, in
Refinement of individual case type
2) If two or more cases have the same precondition and the precondition is a post-condition of a separate refined case, then an “includes” relationship is needed among those refined cases. For example, in
3) If two or more cases have the same post-condition and the post-condition is accounted for by a separate refined case, then an “includes” relationship is needed among those refined cases. For example, in
Once a condition has been met, the second step is to group these common behaviors into “included” cases to be referenced by the other cases. The third step mandates that the textual description for each involved case is revised to reflect the “included” case. Once the textual descriptions have been revised with the “includes” relationship, a model can be created per the newly revised textual descriptions; this is the fourth and final step in managing the “includes” relationship. The PIS “U-1” use case is used as an example in this section.
Without proper investigation the refined model would include six separate use cases and no identified relationships among them. Because of space concerns, the textual descriptions are not included. Refer to [
We use this same process for modeling “includes” relationships among refined misuse and mitigation use cases.
. Textual description for the “U-1: complete administrative tasks” use case
Use Case: “U-1: Complete Administrative Tasks” |
---|
Precondition |
User has proper permissions |
Postcondition |
User successfully completes the task(s) |
Paths (steps) |
1. Payroll Staff member logs onto the system |
2. System authenticates the Payroll Staff to the system |
3. Payroll Staff member starts system application |
4. Payroll Staff member requests information from the system |
5. Payroll Staff member enters information into the system |
6. Payroll Staff member retrieves information from the system |
Special Requirements: A guest account will have to be assigned permissions each time it is used for individual circumstances |
Assumptions: All PIS users will be in good standing with correct permissions |
Abstraction Level: High Level |
Refined “U-1: complete administrative tasks” use case after “includes” relationship process
Use case modeling uses the “extends” relationship for optional behaviors or adding functionality to a case [
1) Check the higher level case for an “extends” relationship by using conditions.
2) Identify the refined cases that account for the optional or additional behaviors as the originators of the “extends” relationships.
3) Identify the refined case that is the target of the “extends” relationship as the last high-level step that executes before the optional or additional behaviors execute.
4) Revise steps in the textual description of the targeted cases to reference the “extended” case.
5) Model the refined cases per the updated textual description from the targeted case.
The two conditions we use to identify “extends” relationships are listed below.
1) If a high-level case has optional behaviors the in steps then an “extends” relationship is needed. In
2) If a refined case should be accessed by many other refined cases for additional behaviors then an “extends” relationship is needed. In
There will one originating case when the “extends” relationship is used for additional behaviors and two or more originating cases when used for optional behaviors. To illustrate the “extends” process, we use the “S-1” mitigation use case as introduced in
The first condition is true because the second and third steps are optional behaviors. Depending on the request type, it will be either allowed as anonymous or be allowed as valid. We identify the cases that account for the optional or additional behaviors (originating cases) as “S-1.2” and “S-1.3”. We identify which refined case will be the target of the “extends” relationship as the last high-level step that executes before the optional or addi-
Intermediate level “S-1: throttle all requests” mitigation use case
. Textual description for the “S-1: throttle all requests” mitigation use case
Mitigation Use Case: “S-1: Throttle All Requests” |
---|
Precondition |
1. Anonymous request is made to the system |
2. Validated request is made to the system |
Postcondition |
1. DoS Attack requests have been throttled |
Paths (steps) |
1. Request is determined if request is anonymous or valid |
2. Authentic requests are allowed to pass undeterred |
3. A small number of anonymous requests are allowed to pass undeterred |
Abstraction Level: High |
tional behaviors execute (“S-1.1”). Finally, we revise the textual description of the targeted case to account for these originating cases. As soon as the system accepts a request from a PIS user, execution is passed to one of the cases. All valid requests will execute “S-1.2” and have resource limits enforced. All anonymous requests will execute “S-1.3” and have the IP address listened to for possible attacks. The final “S-1” model is introduced in
We developed a way to identify the appropriate actor assignments based on the information documented in the textual descriptions of each refined case as listed below.
1) List the identifier and step from the high-level cases that account for each refined case.
2) Check to see if the human actor executes each step in the high-level cases. If the human actor executes the step, then an actor assignment is needed for the corresponding refined cases.
3) If the human actor does not execute the step, then the case is considered independent from the human actor. For these independent actors the system actor assignment is needed.
We assign actors after the “includes” and “extends” relationships have been modeled, so that the textual descriptions are finalized after being revised during relationship identification.
For mitigation use cases it is not easy to identify which mitigation use case is completed by the “security” actor because the “security” actor is not an actual person. We simply assign the actor to the initial mitigation use case and allow execution to filter down to the remaining cases. This is the only consistent way to assign actors to cases that are executed by an implemented system feature and not by a human actor.
The “includes” and “extends” relationship and actor assignments must be maintained as refinement continues and additional cases are created. In
We developed a condition-driven approach to identify the originating cases and targeted cases for “R”. These conditions are the same when “R” represents an “includes” or “extends” relationship. These conditions are also the same when working with any of the three case types. Our conditions used to maintain the initial “includes” and “extends” relationships are listed below. Conditions 1 - 3 deal with the targeted cases and 4 - 6 deal with the originating cases of “R”.
1) IF “R1” = “includes” THEN “R” target = the originators of “R1”.
This is because “A1.2” has to execute because it initiates the relationship. “A1.1” is not an originator because it is shared behavior of “A1.2” and will execute when “A1.2” executes.
2) IF “R1” = “extends” THEN “R” target = the target of “R1”.
This is because “A1.1” has to execute because it is the first case to execute with additional behaviors attached. “A1.2” is not a target because it is optional or additional behaviors of “A1.1”.
3) IF “R1” = NONE THEN “R” target = the first “A1” case to execute based on case identifier.
This is because “R” targets the first case to execute when the cases are independent.
4) IF “R2” = “includes” THEN “R” originator = the originators of “R2”.
This is because “A2.2” has to execute because it initiates the relationship. “A2.1” is not an originator because it is shared behavior of “A2.2” and will execute when “A2.2” executes.
5) IF “R2” = “extends” THEN “R” originator = the target of “R2”.
This is because “A2.1” has to execute because it is the first case to execute with additional behaviors attached. “A2.2” is not a target because it is optional or additional behaviors of “A2.1”.
6) IF “R2” = NONE THEN “R” originator = the first “A2” case to execute based on identifier.
This is because “R” originates from the first case to execute.
These conditions are mutually exclusive and collectively exhaustive in that only one of each condition (1 - 3 and 4 - 6) can be true and they account for every possibility.
The question remains, what cases in the “A2” subset “includes” or “extends” what cases in the “A1” subset? We use part of the “U-1” use case as an example to illustrate our conditions for identifying the targeted cases and
Generic depiction of continued refinement
originating cases where “U-1.4”, “U-1.5”, and “U-1.6” all include “U-1.3”. Further work is needed to identify exactly what subset case takes part in the relationship.
“U-1.3” only has one refined use case (“U-1.3.1”) so there is obviously no relationship within this case subset. This meets condition #3 which states that when there is no “R1” that “R” targets the first case to execute, so every corresponding use case subset will target “U-1.3.1” with the “includes” relationships. The “U-1.4” subset has no relationships among its refined cases; it meets condition #6, so the “includes” relationship originates from the first originating case that executes. “U-1.4.1” will originate the “includes” relationship with “U-1.3.1”. The “U-1.5” subset has no relationships, so it also meets condition #6 in which the first executing case will originate the “includes” relationship. “U-1.5.1” will originate the “includes” relationship with“U-1.3.1”. The “U-1.6” subset has an “extends” relationship among its refined cases, so it meets condition #5 where an “extends” relationship is present among the originating case subset. The originating cases for the “includes” relationship with the “U-1.3.1” case is the target of the “extends” relationship within the case subset. “U-1.6.1” case originates the relationship with “U-1.3.1”.
The model in
Refined “included” use case model
Final Refined “Included” Use Case Model for “U-1.3”, “U-1.4”, “U-1.5”, and “U-1.6”
1) Request parameters must be entered before information is retrieved. Therefore, it is accurate that “U-1.4.1” comes before “U-1.4.2”.
2) Hours must be entered before assigning withholdings and deductions which must happen before deductions and pay are calculated. Therefore, it is accurate that all three of the use cases execute in order. “U-1.5.1” comes before “U-1.5.2” which comes before “U-1.5.3”.
3) Personal information, pay rate, W-2 information, and deductions can all be retrieved without consideration of the others. Therefore, it is accurate that the “extends” relationship drives the identification of the originating case. The target of the “extends” relationship (“U-1.6.1”) originates the “includes” relationship with the “U-1.3.1” use case.
As shown in Section 3, we use textual descriptions to identify which cases need an actor assigned. If the step indicates that the human actor executes the use case, then that assignment is made. If the human actor is not present, a system actor is needed as introduced in
Assigning actors for misuse and mitigation use cases is similar. We use “attack timing” and “mitigation timing” for the system actor for misuse and mitigation use cases because there is no system in which misuses and mitigations executed.
“Threatens” and “mitigates” relationships integrate functional and security requirements in our approach. When these integrated models are refined, the relationships must be modeled in an accurate and consistent manner.
Refined “U-1.3”, “U-1.4”, “U-1.5”, and “U-1.6” use cases with actor assignment
Relationships between different case types
“R” would be a “mitigates” relationship. “R” is present at the highest level of abstraction as a “threatens” or “mitigates” relationship and now needs to be maintained as refinement continues.
We have three priorities related to the modeling of “threatens” and “mitigates” relationships.
1) The modeling of originating and targeted cases for “R” between case subsets.
2) The revision of these cases when there is “includes” and/or “extends” relationships present within the case subsets. This revision uses the same rules as the condition-driven approach introduced in the previous section.
3) The illustration of “threatens” and “mitigates” relationships at different levels of abstraction.
Section 5.1 introduces the process of modeling “threatens” relationships, while Section 5.2 introduces the process of modeling “mitigates” relationships
We must properly manage this relationship to ensure the correct refined misuse cases are threatening the correct refined use cases as introduced in the following numbered list.
1) Identify threats for each refined use case from the steps in the high-level textual descriptions.
2) Identify threats produced by each misuse from the steps in the high-level textual descriptions.
3) Map each misuse case to any use case that is threatened by it. This models the refined use case as the target of the “threatens” and the exact refined misuse case as the originator.
4) Use the conditions from Section 4 to ensure mapping of “threatens” relationship between the misuse case and the use case subsets when “includes” and “extends” are present.
5) Collapse and expand the model to show “threatens” at varying levels of abstraction.
Refinement uncovered the details of each case type independently of other case types; now these refined cases are integrated together with this process. We use “U-1” and “M-2” as an example of using this process. At a high-level “M-2” threatens “U-1”, but it is unknown exactly which of the refined cases are the originator(s) and target(s). The obvious question is does “M-2” really threaten each of the six use cases that make up “U-1”? To answer this, “M-2” must be investigated for the exact threats that it produces. The steps of the textual description outlines the exact threat that each refined misuse case produces as introduced in
Next, we map the misuse cases to the use cases by comparing these threats (
It may be advantageous to have the ability to collapse any one part of the model to aid in understandability. This must be done only after the relationship has been accurately mapped.
We must also manage the “mitigates” relationship to ensure the correct mitigation use case is mitigating the correct misuse case as introduced in the following numbered list.
1) Identify the mitigations produced by each refined mitigation use case. This extracts the mitigations from each case so that these entries can be used in modeling “mitigates”.
. Refined “M-2” misuse cases and produced threats
Misuse Case | Produced Threat |
---|---|
M-2.1: Compromise Router | Attacker hacks the system in search of login information |
M-2.2: Guess Logon Info | Attacker uses this information to login to the system as a valid user |
M-2.3: View Payroll Information | Attacker view information in the system |
2) Map each mitigation to applicable misuse cases based on the “mitigated by” column as the target of the “mitigates” relationship.
3) Use the conditions to ensure mapping of “mitigates” between mitigation use case and misuse case subsets when there are “includes” and “extends” present in the case subsets.
4) Collapse and expand the model to show “mitigates” at varying levels of abstraction.
This process provides the detailed interactions between mitigation use and misuse cases. The necessary security measures will be identified and modeled in this process. We continue with “M-2” as an example. “S-2” mitigates part of “M-2”, but it is unknown exactly which parts of “S-2” actually prevent “M-2”. Mitigations are harvested from steps in the text description of the mitigation use case. The misuse case provides what is needed to prevent the threat; this allows for the mapping of “mitigates”. “M-2.1” and “M-2.2” are not mitigated by “S-2”. The other mitigation use cases would need to be checked to see which actually prevents these misuse cases.
A check for “includes” or “extends” present within the case subsets is now performed. We use the same conditions to check for accuracy of the “mitigates” relationships and make revisions to the originating or targeted cases of the relationship. In this example, there is an “extends” relationship originating at “S-2.2” and targets “S-2.1”. In terms of the “mitigates” relationship, these cases are the originating cases while “M-2.3” is the target. Referring to
Once “threatens” and “mitigates” have been revised, the three case types can be integrated into one model as introduced in
Use case model with “threatens” relationships
Final use case model with “mitigates” relationship
Final integrated use case model with use, misuse, and mitigation use cases
This model shows exactly what use cases are threatened and how it will be mitigated. Our goal is to createrefined models that reflect the interplay of these case types at a more detailed level than the high-level use/mi- suse/mitigation use case models previously used.
We refine and integrate use, misuse, and mitigation use cases in the requirements phase for the benefit of security requirements by completing three specific phases. First, we refine each case type independently of other case types. Second, we maintain the accuracy and consistency of the cases as refinement continues. Third, we integrate the differing case types into a single model to investigate the detailed interactions among the differing case types.
Our refinement process is driven by the textual descriptions of each case and includes extensive work on modeling “includes” and “extends” accurately and consistently. We created a decision making process which includes steps and conditions to identify and model these relationships as part of the initial refinement of each case. We follow conditions that make an “includes” or “extends” relationship likely among the newly refined cases and apply our steps and conditions to ensure the appropriate relationships among the refined cases. Integration is the main reason for refining; we are not trying to create a functional decomposition of use cases.
The main limitation of our approach is that it is completed without any assistance from automated tools. This causes the amount of time required to appropriately use the approach to be long. It is not a trivial task to identify cases, identify and model relationships within each case type, and accurately identify and model the integrating relationships between the case types. Automated tools not only would help with the time factor of using our approach, but also would eliminate the possibility of human errors. Because of the time it takes to use our approach from start to finish, the overall size of the system is a concern. Our approach is best suited for small information systems that have a need for security and will be executed primarily by human users. Large systems would take a long time to follow our steps in identifying all of the relationships.