Security Requirements Elicitation

Definitions of Security Requirements

• There is no universally accepted definition of "security requirement" in the literature (Tondel et al, 2008).
• Security Requirements (Haley et al., 2007) can be defined as "constraints on the functions of the system, where these constraints operationalize one or more security goals". In this definition, security requirements operationalize the security goals as follows:
  • They are constraints on the system's functional requirements, rather than being themselves functional requirements.
  • They express the system's security goals in operational terms, precise enough to be given to a designer or architect. Security requirements, like functional requirements, are prescriptive, providing a specification (behavior in terms of phenomena) to achieve the desired effect.
• Software requirements are typically divided into two categories: functional and non-functional. Functional requirements deal with what the system is supposed to do, for example deposit money into a bank account. Non-functional requirements deal with everything else including operational availability, performance, portability, reliability, security, and
  usability.
• Defining requirements in terms of function leaves out key information: what objects need protecting and, more importantly, why the objects need protecting (Haley et al., 2007).
• High-level security goals "tend to make security requirements not specific enough to guide designers and to verify that the requirements are met". Therefore, the security requirements should be able to "express what is to happen in a given situation, as opposed to what is not ever to happen in any situation (Haley et al., 2007).
• Security requirements should be "Smart+ requirements" that means "specific, measurable, appropriate, reasonable, and traceable" (Clasp, www.fortifysoftware.com/ security-resources/clasp.jsp).
• Most requirements engineers (Firesmith, 2003) often "confuse security requirements with architectural security mechanisms" and "end up making architecture and design decisions". For example, a security requirement for a typical security use case for an automatic teller machine might be stated as: "The system shall authenticate users by asking them to insert an ATM card and enter a PIN number". This statement only provides a prescriptive security mechanism while unnecessarily ignoring the use of others such as face recognition, fingerprint analysis, or retinal scan.
• Firesmith (2003) also suggests that security requirements be organized into 12 categories. Among them, 10 of them are for Web applications:
  1. Identification: any security requirement that specifies the extent to which a business, application, component, or center shall identify its externals (e.g., human actors and external applications) before interacting with them.
  2. Authentication: any security requirement that specifies the extent to which a business, application, component, or center shall verify the identity of its externals (e.g., human actors and external applications) before interacting with them.
  3. Authorization: any security requirement that specifies the access and usage privileges of authenticated users and client applications.
  4. Immunity: any security requirement that specifies the extent to which an application or component shall protect itself from infection by unauthorized undesirable programs (e.g., computer viruses, worms, and Trojan horses).
  5. Integrity: any security requirement that specifies the extent to which an application or component shall ensure that its data and communications are not intentionally corrupted via unauthorized creation, modification, or deletion.
  6. Intrusion Detection: any security requirement that specifies the extent to which an application or component shall detect and record attempted access or modification by unauthorized individuals.
  7. Non-repudiation: any security requirement that specifies the extent to which a business, application, or component shall prevent a party to one of its interactions (e.g., message, transaction) from denying having participated in all or part of the interaction.
  8. Privacy: any security requirement that specifies the extent to which a business, application, component, or center shall keep its sensitive data and communications private from unauthorized individuals and programs.
  9. Audit: any security requirement that specifies the extent to which a business, application, component, or center shall enable security personnel to audit the status and use of its security mechanisms.
  10. Maintenance: any security requirement that specifies the extent to which an application, component, or center shall prevent authorized modifications (e.g., defect fixes, enhancements, updates) from accidentally defeating its security mechanisms.

Methodologies of Security Requirements Elicitation

• The methodology should be "palatable to regular software developers and suitable for use in all software development" (Tondel et al., 2008).
• These mechanisms must be "easy to both understand and use"(Tondel et al., 2008).
• The methodology should be "comprised of a series of well-defined steps or tasks" that collectively lead to the elicitation of security requirements. (Tondel et al., 2008)
• Many efforts have been made to develop approaches that integrate security requirements into software and software development, and these approaches undoubtedly have their merits (Davis, 2005; Haley et al., 2009). In order to facilitate the integration process of security requirements, these approaches explicitly define a set of tasks to follow. In a detailed literature survey "lightweight" approaches (Tondel et al., 2008), tasks in security requirements elicitation can be summarized into eight categories:
1. definitions of central concepts (such as attack, asset, and authentication) as part of the requirements engineering process;
2. objectives, or high-level business-centric goals;
3. misuse or threats;
4. assets and their values;
5. coding standards-that is, what language to use or functions to avoid;
6. categorization and prioritization of the security requirements;
7. inspection and validation of requirements for completeness, lack of conflicts, or other matters; and process planning of security activities.
• Tondel et al.'s (2008) survey also indicates that none of the approaches covers all eight categories of task, but they typically recommend the identification of threats, assets, and security objectives (or high-level business-centric goals). Tondel et al. (2008) also suggest the use of such artifacts, such as use cases and misuse cases, to identify threats.

Security Requirements Artifacts

• In requirements engineering, system goals are used to model the high-level objectives of a software system's actors (human users or automated systems). System goals are recognized as powerful drivers for the development process because they help relate system requirements to the business and organizational needs, enable traceability of design rationale, and help analysts identify conflicts and tradeoffs in the early stages of the software development lifecycle. (Anton et al., 2004)
• Security needs arise when actors establish that some assets involved in the system are valuable to the organization and need to be safeguarded. Security goals express this desire, describing the involved assets and the harm to be prevented. "The security requirements satisfy the security goals; the system satisfies the security requirements". (Haley et al., 2007)
• Security objectives are the "high-level requirements or goals that are most important to customers," and the requirements that "must be met to comply with relevant legislation, policies, and standards". (Tondel et al., 2008)

Use Case (Functional Use case)

• Use cases are widely accepted as the best approach to capturing system requirements, in particularly, function requirements.
• Use cases have proven helpful for the elicitation of, communication about, and documentation of functional requirements. (Pauli & Xu, 2005)
• Use cases capture system functionality or functional goals of the system from the perspective of external entities called actors. Use case diagram depicts the use cases with relationship with actors and among themselves. (Supakkul & Chung, 2005)
• Use cases are helpful for determining the rights each actor needs and for considering possible attacks. (Fernandez, 2004)

Misuse Case (Abuse Case or Attack Use Case)

• Sindre and Opdahl (2001) considered misuse cases as "the inverse of use cases". A misuse case specifies a sequence of actions, including variants, that 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.
• A misuse case is simply "a use case from the point of view of an actor hostile to the system under design". (Alexander, 2003)

Use Case vs. Misuse Case

• Use case mitigate misuse case: The use case is a countermeasure against a misuse case, i.e., the use case reduces the misuse case's chance of succeeding. An example is "protect info", which mitigates "steal credit card info. (Sindre & Opdahl, 2005)
• Misuse case threaten use case: The use case is exploited or hindered by a misuse case. For example, the "register customer" use case is threatened by a denial-of-service attack, "flood system", that prevents legitimate users from accessing internet services, including customer registration. (Sindre & Opdahl, 2005)
• Unlike normal use cases that document interactions between an application and its users, misuse cases concentrate on interactions between the application and its misusers who seek to violate its security". (Firesmith, 2003)

Security Use Cases

• A security use case is a "specialized use case" the scope of which is restricted to security issues.

Security Use Cases vs. Misuse Cases

• Misuse cases, as a successful attack case against an application, are "highly effective ways of analyzing security threats but might be inappropriate for the analysis and specification of security requirements". Instead, "security use cases should be used to specify requirements that the application shall successfully protect itself from its relevant security threats" (Firesmith, 2003).
• In Firesmith's Open Process Framework site, the security use case is defined as a "specialized use case" to specify security requirements related to the security threat (i.e., essential use case) and to document the use of a security architectural mechanism (i.e., architectural use case).

Source: (Firesmith, 2003)

Source: (Firesmith, 2003)

A TEMPLATE OF SECURITY USE CASES

(Source: Open Process Framework)

Categorization of Security Requirements (Firesmith, 2003)

• Most requirements engineers are poorly trained to elicit, analyze, and specify security requirements. Very often they have only been given an overview of security architectural mechanisms such as passwords and encryption rather than in actual security requirements. Consequently, they tend to end up specifying architectural security mechanisms that are traditionally used to fulfill the security requirements rather than the true security requirements themselves. 
• Common security requirements for web applications include:
• Identification Requirements: Ensure that users and client applications are identified and that their identities are properly verified.
• Authentication Requirements: Ensure that users and client applications can only access data and services for which they have been properly authorized.
• Authorization Requirements: Detect attempted intrusions by unauthorized persons and client applications.
• Integrity Requirements: Ensure that communications and data are not intentionally corrupted.
• Intrusion Detection Requirements: Detect attempted intrusions by unauthorized persons and client applications.
• Nonrepudiation Requirements: Ensure that parties to interactions with the application or component cannot later repudiate those interactions.
• Privacy Requirements: Ensure that confidential communications and data are kept private. 
• Security Auditing Requirements: Enable security personnel to audit the status and usage of the security mechanisms.
• System Maintenance Security Requirements: Ensure that system maintenance does not unintentionally disrupt the security mechanisms of the application, component, or center.