Skip to content

Eliciting Security Requirements with Misuse Cases

This lecture follows on from the previous one about the secure SDLC, and looks further into how we can get security requirements for a piece of software. Security requirements are statements of needed security functionality to ensure the security properties of the software.

These requirements define new features or additions to existing features, solving a specific security problem, or eliminating some vulnerability. These requirements exist to prevent the repeat of past security failures.

These requirements come from industry standards, legislation, and past vulnerabilities. By addition of the user story or misuse case, we can tie the application to what the user does to the system, instead of looking at what the system offers to the user.

This is done from the attacker's perspective and describes what an attacker or malicious user should not be able to do to the system.

Elicitation

To get security requirements, we first identify the critical assets that need protection. Once this is done, we can begin to define the security goals for the assets, including the CIA triad, in addition to the accountability aspect of the system.

Once we can identify threats to assets, we can derive the misuse cases, and begin to identify and analyse the risks to the systems. From here, we can move to define the security requirements of the system and the overall security use cases of the system. This can be visualized with the following diagram:

Comparison of Functional and Security Requirements

Functional requirements are those that address the function of the system. For example, a system must provide a function to retrieve personnel information. The asset to protect is the personnel information, and the security goal is to protect this information from a breach of confidentiality. Let's imagine a threat scenario: an employee without proper authorisation checks a colleague's paycheck.

The security requirement we can derive here is that only HR and accounting should be able to retrieve this personnel information functionality. The underlying design decision for this system would then be to authenticate users and assign them a role within the system.

Methods and Techniques

As discussed above, techniques include the misuse or abuse cases. In addition to this, we can also refer to the attack trees described in the threat modelling with STRIDE lecture, or from a privacy standpoint with the LINDDUN lecture.

A number of other processes exist for the elicitation of these requirements. These include SQUARE, SREP, SECURE TROPOS, and KAOS.

Use Cases

These describe what a system or software should do. They show a type of complete interaction between a system/software and one or more actors. The actors represent entities that exist outside the system, and interact with the system in some way.

Use cases can be represented diagrammatically, with the actor as a person, an association as a line joining an actor to one or more use cases, and the use cases in an ellipse.

Take, for example, the following use cases diagram:

This diagram shows the use cases for a typical system. The use case shows what the system should do. We can create a misuse case diagram, with a 'misuser' and this misuser triggers one or more misuse cases, where the system does something it should not allow. An example misuse case might look as follows:

Use cases and misuse cases can be shown in the same diagram. A use case is typically threatened by a misuse case. Security use cases are countermeasures against these misuse cases, with the security case as the security requirement.

Building Misuse Cases

We start with a normal use case model, then identify actors, including external attackers and misusers of the system. We need to consider what skills an attacker might have, in addition to the resources an attacker has, and what they want to achieve.

We can then identify misuse cases as the things that the bad actor can do, then begin to identify the threat relationships between different use and misuse cases. With this done, we can begin to identify the security cases needed. An overall security use cases diagram might look as follows:

Example: Mobile Web Shop

Use Cases

The mobile web shop has the following use cases:

MWS-1 – Search for product

The customer selects among product types from a menu, for instance music, TV episodes, and various software. In addition, a search text can be provided. The result will be a list of candidate products. The search result can then be narrowed by further searches, or a new search can be made instead. Alternatively, the customer can select one of the listed products for purchase (MWS-2).

MWS-2 – Buy product

At any time the customer can select one of the displayed products for purchase. The system can support automatic payment based on personal payment information already stored in a customer account. If the customer is not already logged in, s/he must first log in (MWS-5). If personal information has not been stored, the system offers to enter this (MWS-4). Afterwards, the product will be downloaded in the background while the customer may continue with other operations.

MWS-3 – Establish customer account

The customer establishes a customer account – if not having one already. The customer may supply payment information and other information in the profile, for instance about product types for which notification is wanted if something new is available.

MWS-4 – Set customer information

The customer should be able to enter or edit personal information, like name, address, phone number and email address. There is also a sub function for supplying personal payment information (e.g., credit card details) for which security is particularly important.

MWS-5 – Log into customer account

The customer normally supplies username and password for this. On some types of equipment, the customer could also opt to authenticate by means of fingerprint. The MWS-5 function can be initiated from MWS-1 or MWS-2 at any time the customer wants to. It will be called automatically by MWS-2 if the customer is not already logged in.

MWS-6 – Log out from customer account

The customer terminates the session with the online shopping mall. If the customer is idle for 5 min, logout will occur automatically due to a time-out function.

Use Case Diagram

We can then construct a use case diagram for the system:

Misuse Case Diagram

We can then extend the use case diagram to handle possible malicious cases:

Security Use Case Diagram

We can then augment the misuse case diagram, to annotate it with the mitigations for various possible attacks:

Misuse Case Descriptions

Following the diagramming of the misuse cases, it may be a good idea to look at the determination and analysis of security threats, by describing the case.

Misuse cases are described with their name, summary, author, and date as in a normal use case description. Misuse cases can include basic and alternative paths for the sequences of actions that the misusers and proposed system go through to cause harm to the system. A sample misuse case description is given below:

Example

Name

Tamper with database by web query manipulation

Summary

An attacker manipulates the web query, submitted from a search form, to update or delete information, or to reveal confidential information

Basic Paths

Describe the actions that the misusers and the system go through to harm the proposed system:

  • bp–1: The hacker provides some values on a product search form and submits
  • bp–2: The system displays the product(s) matching the query
  • bp–3: The hacker alters the submitted URL, introducing a query error, and resubmits
  • bp–4: The query fails, and the system displays the database error message to the hacker, revealing more about the database structure
  • bp–5: The hacker alters the query further, for instance adding a nested query to reveal secret data or update or delete data, and submits
  • bp–6: The system executes the altered query, changing the database or revealing content that should have been secret

Alternative Paths

Describe ways to harm the proposed system that are not accounted for by the basic path, but are still sufficiently similar to be described as variants of the basic path

  • ap-1: In bp-3 or bp-5, the hacker does not alter the URL in the address window, but introduces errors or nested queries directly into form input fields

Mitigation Points

Identify actions in a basic or alternative path where misuse can be mitigated:

  • mp-1: In bp-4, the exact database error message is not revealed to the client (more difficult to guess table and field names in bp-5)
  • mp-2: In bp-6, the system does not execute the altered query because all queries submitted from forms are explicitly checked in accordance with what should be expected from that form (preventing the misuse case)

Triggers

Describe the states or events in the system or its environment that may initiate the misuse case:

  • tr-1: Always true (can happen at any time)

Preconditions

Describe the system states that make the misuse case possible:

  • pc-1: The hacker can search for products, either because this function is publicly available, or by having registered as a customer

Assumptions

Describe the states in the system’s environment that make the misuse case possible:

  • as-1: The system has search forms feeding input into database queries

Mitigation Guarantee

Describes the guaranteed outcome of mitigating a misuse case:

  • The hacker is unable to access the database in an unauthorised manner through a publicly available web form (see mp-2)

Links to business rules being violated by the misuse:

  • The services shall be available to customers over the internet

Potential Misuser Profile

Describes whatever can be assumed about the misuser:

  • Skilled with Knowledge of databases and query language, or at least able to understand published exploits

Stakeholders and Threats

Specify the threats for each stakeholder involved in the misuse case:

  • st-1: (provider) loss of data if deleted, potential loss of revenue if customers are unable to Order Product, or if prices have been altered, bad will resulting from customer problems in st2
  • st-2: (customers) potentially losing money (at least temporarily) if hacker has increased product prices, unable to order if data lacking, wasting time, more far-reaching issues of loss of privacy (if misuser reveals confidential information about customers) or even money loss (if misuser reveals, e.g., credit card numbers)

Scope

Indicates whether the proposed system in a misuse case is, e.g., an entire business, a system of both users and computers, or just a software system:

  • Entire business and business environment

Comments