Misuse cases and Abuse cases extending Use case diagrams

Presentation of use case diagrams

Use case diagrams are part of the standard object modelling language UML dened by the Object Management Group2 _{(OMG). The objective of this kind of diagram is}

to capture the functional requirements of an IS, by describing the typical interactions between the users of the system and the system itself [Fow03]. Use case diagrams are a notation suited for early requirements, because they can be used before dening any internal structure of the IS. It represents external behavior of the system-to-be. In a nutshell, a use case diagram describes what the system should do and it does not specify how it carries it out.

A use case diagram represents a set of scenarios tied together by a common goal, like in Figure 3.4 about the running example. The gure illustrates an excerpt of the production of construction plan. Within a use case diagram, the rst concept is the one of actor. An actor is a role that a user plays with respect to the IS. Two actors are represented in Figure 3.4: Engineer and Drawer. Actors are related to use cases with

3.2 Security-oriented modelling languages 61

Figure 3.4: Use case diagram representing a fragment of the production of construction plan

association relationships, showing an interaction between an actor and a use case in which (s)he participates. A use case is a set of actions performed by the system and requested by the actors. It represents an objective to be fullled by the system-to-be, motivated by the need of one (or several) actors. Examples of use cases are Design 3D mock-ups, Design technical plans and Establish structure calculation. A use case can be related to another use case by an include relationship. It indicates that the source use case is composed among other things of the destination use case. Establish structure calculation is related in this way to Update parameters and Collect context information. Two other relationships between use cases exist [Pen03] (not represented in Figure 3.4). First, the extend relationship proposes an alternative use case (end of the graphical link) of an initial one (start of the graphical link). Its selection depends on a condition needed to be expressed. This relationship is equivalent to the extensions of the textual descriptions of use cases, as depicted below. Second, the generalisation relationship identies an inheritance relationship between actors or between use cases.

Figure 3.5: Example of use case textual description on the structure calculation establishment (inspired from [Fow03])

Textual descriptions are associated with a use case diagram3_{. They are meant}

to further describe the use cases and therefore the system functionalities, but also the interaction with the actors [Coc01]. Various textual formats exist and a typical one is proposed in Figure 3.5, inspired from [Fow03]. It illustrates the Establish structure calculation use case. The information provided is the goal level and the typical steps to follow for the main success scenario. Other alternative scenarios can be considered and are written in the extensions part. An extension within a use case names a condition (Engineer is not on the building site) resulting, if satised, in dierent steps from those described in the main success scenario to be performed sequentially (Third party collects context information and Engineer inserts the information in the application should be performed instead of Engineer collects context information). Finally, the include relationship represented in the graphical use case is expressed in the textual description by underlined words, which suggest a hyperlink4_.

Misuse cases

Use cases are as suited for identifying functional requirements. However, they are generally neglect non-functional requirements, like security requirements. In such a context, Misuse cases is introduced in 2000 [SO00, SO01], aiming at extending `tra- ditional' use cases with negative use cases specifying the behaviors not wanted in the proposed IS. A misuse cases diagram can be seen as a use case from the point of view of an actor hostile to the system [Ale02]. It also has two representations: a graphi- cal diagram (Figure 3.6) and a textual specication (Figure 3.7). Misuse cases come with a security requirements process, which outcome is the elicitation of suited security requirements. The process consists of the 5 following steps [SO05]:

1. Identify critical assets 2. Dene security goal 3. Identify threats

4. Identify and analyse risks 5. Dene security requirements

Graphical misuse cases

Misuse cases reuse the main concepts existing in use cases diagrams: actors and use cases, coming with the associated relationships: association relationship, includes re- lationship and extends relationship. Figure 3.6, representing a misuse cases diagram, is therefore built on the same basis as the use case diagram from Figure 3.4. Mis- use cases introduces new concepts related to security. The main one is misuse case (e.g., Steal login information) which describes a sequence of actions, including variants, which a system or other entity can perform, interacting with misusers of the entity and causing harm to some stakeholder if the sequence is allowed to complete

3_{Use cases are also often complemented with other (behavioural) models in addition to text.} 4_{In many tools it is really a hyperlink}

3.2 Security-oriented modelling languages 63

Figure 3.6: Example of misuse cases diagram

[SO05]. A misuser (e.g., Crook) is an actor that initiates misuse cases, either inten- tionally or inadvertently [SO05]. Two relationships may be dened between use cases and misuse cases. A threatens relationship targets a use case (Establish structure calculation) that a misuse case (Steal login information) wants to harm. A mit- igates relationship characterises how some security use cases (e.g., Perform awareness training) can be dened as countermeasures against the misuse cases.

Textual template

Textual descriptions also play an important part when representing misuse cases [SO01, SO05]. Two ways of expressing misuse cases textually are suggested: a lightweight description and an extensive description. A lightweight description is an embedded description of a textual use case (such as suggested in [KG00, Coc01, BDG05]) by extending them with an entry called Threats. An extensive description supports a de- tailed determination and analysis of security threats [SO01, SO05] based on a template of elds. Figure 3.7 is an example of the entries of the extensive template as proposed and described in [SO05].

Abuse cases

Abuse case models were proposed in 1999, motivated by the gap existing between security specialists and software developers, having both their own supporting models [MF99]. Like Misuse cases, it is an adaptation of the use case modeling technique aiming at capturing and analysing security requirements in a simple way. As use cases, abuse cases are described using use case diagrams and use case textual descriptions. They are considered as helpful during the requirements, design and testing phases of a security engineering process and have been used in the context of building security assurance arguments [McD01].

Figure 3.7: Example of the misuse cases template on the `Steal login information' misuse case

abuse case is considered as complementary to misuse cases because [SO05]:

• Abuse case models focus specically on security requirements and their relation to design and testing (not illustrated in Figure 3.8 and 3.9), whereas misuse cases diagrams focus on elicitation of security requirements in relation to other requirements.

• Abuse cases do not show use cases and abuse cases in the same diagram, contrarily to Misuse cases which also show the relations between misuse cases and use cases.

• Abuse cases provide more details concerning actors in their textual descriptions, whereas misuse cases descriptions are more complete than abuse case description. The proposed process for building an abuse case model is:

1. Identify the actors 2. Identify the abuse cases 3. Dene abuse cases

4. Check granularity (to be sure to have neither too many nor too few abuse cases) 5. Check completeness and minimality (to be sure each abuse case results eectively

in harm to the system and none of the critical abuse cases has been omitted) Graphical abuse cases

An abuse case is dened as a specication of a type of complete interaction between a system and one or more actors, where the results of the interaction are harmful to the

3.2 Security-oriented modelling languages 65

Figure 3.8: Example of abuse case model

system, one of the actors, or one of the stakeholders in the system [MF99]. Exam- ples of abuse cases are Browse building plans with hacking tools, Remote DoS5

attack and Modify structure calculation (Figure 3.8). An abuse case model thus represents (one or more) interactions between an actor (e.g., Malicious engineer or Crook) and the system resulting in harm to a resource associated with one of the actors, one of the stakeholders, or the system itself. About the representation of ac- tor and related abuse cases, the standard UML notation of actor and use case is used, in the aim to be compliant with the existing software supporting UML (cf. Figure 3.8).

Figure 3.9: Example of textual descriptions for the Crook actor and the `Browse building plans with hacking tools' abuse case

Textual description

Abuse case models are completed by two textual description: actor description and abuse case description. Concerning actors, three key characteristics have been dened as relevant to correctly understand the abuse case model: resources (e.g., hardware and software, available time, nancial resources, etc.), skills (e.g., technical skills re- lated to network protocols, cryptography, operating systems, etc.) and objectives (e.g., vandalism, theft, terrorism, etc.). An example of textual description is proposed for Crook in Figure 3.9. Concerning abuse cases textual description, it provides infor- mation about potential harm that will occur as a result of the abuse, privilege range allowing the attacker to carry out this abuse, and abuse interaction proposing the scenario underlying the abuse case. The textual description of the abuse case Browse building plans with hacking tools is presented in Figure 3.9. This description could also come with a diagram illustrating the path to be used by the actor to full the abuse case [MF99].