Security Requirements

Definition

Security Requirement

a user-oriented quality requirement that specifies a minimum required amount of a quality subfactor of the security quality factor

Objectives

The typical objectives of security requirements are to:

• Ensure that access by users and client applications is controlled:
  • Ensure that users and client applications are identified.
  • Ensure that their identities are properly verified.
  • Ensure that users and client applications can only access data and services for which they have been properly authorized.
• Detect attempted intrusions by unauthorized persons and client applications.
• Ensure that unauthorized malicious programs (e.g., viruses) do not infect the application or component.
• Ensure that communications and data are not intentionally corrupted.
• Ensure that parties to interactions with the application or component cannot later repudiate their interactions.
• Ensure that confidential communications and data are kept private.
• Enable security personnel to audit the status and usage of the security mechanisms.
• Ensure that applications and centers survive attack, possibly in degraded mode.
• Ensure that centers and their components and personnel are protected against destruction, damage, theft, or surreptitious replacement (e.g., due to vandalism, sabotage, or terrorism).
• Ensure that system maintenance does not unintentionally disrupt the security mechanisms of the application, component, or center

Types

The following are different types of security requirements:

1. Access Control:
   1. Identification Requirements
   2. Authentication Requirements
   3. Authorization Requirements
2. Immunity Requirements
3. Integrity Requirements
4. Intrusion Detection Requirements
5. Nonrepudiation Requirements
6. Privacy Requirements
7. Security Auditing Requirements
8. Survivability Requirements
9. Physical Protection Requirements
10. System Maintenance Security Requirements

Guidelines

The following guidelines have been found to be useful when producing security requirements:

• The scope of a security requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
• For guidelines that are specific to individual types of security requirements, see the guidelines sections of following webpages:
  1. Access Control:
     1. Identification Requirements
     2. Authentication Requirements
     3. Authorization Requirements.
  2. Immunity Requirements.
  3. Integrity Requirements.
  4. Intrusion Detection Requirements.
  5. Nonrepudiation Requirements.
  6. Privacy Requirements.
  7. Security Auditing Requirements.
  8. Survivability Requirements.
  9. Physical Protection Requirements.
  10. System Maintenance Security Requirements.
• Security Policy.
  A security requirement is typically a detailed requirement that implements an overriding security policy.
• Correctness.
  Security requirements depend on correctness requirements because implementation defects are often bugs that produce security vulnerabilities. Thus, using a type-unsafe languages such as C can result in array boundary defects that can be exploited to run malicious scripts.
• Feasibility.
  It is impossible to build a 100% secure business, application, component, or center. Increasing security typically:
  • Increases the associated cost.
  • Increases the associated schedule.
  • Decreases the associated usability.
• Security Use Cases versus Misuse Cases.
  Security requirements can be specified by security use cases, whereas misuse or abuse cases can be used to analyze the security threats that drive the security requirements.
  • The user client external (human actor or application) of a use case is replaced by a misuser (e.g., cracker or disgruntled employee) who attempts to violate the security of a business, application, component, or center.
  • The normal user-initiated interactions of the user case are replaced by the misuser-initiated attack interactions of the misuse case.
  • The required application or component response interactions and postconditions of the user case are replaced by the required application or component security-oriented responses and postconditions of the misuse case.

  Note that whereas goals drive use case requirements, threats drive misuse case requirements.

  Note also that a very common problem with using misuse cases as a requirements approach is that they often assume the prior existance of architectural security mechanisms to be thwarted, and thus misuse cases may be better suited for security threat analysis and the generation of security test cases than for specifying security requirements. If misuse cases are to be used for requirements, they should be ‘essential’ misuse cases that do not contain unnecessary architecture and design constraints.

• Threats vs. Goals.
  Whereas most requirements are based on higher level goals, security requirements are driven by security threats. Thus, whereas most requirements are stated in terms of what must happen, security requirements are often specified in terms of what must not be allowed to happen. Part of security engineering is therefore similar to (and can be thought of as a specialized form of) risk management. Therefore, base the security requirements on the results of a thorough security risk assessment by the security team. Such an assessment identifies the significant threats and their associated estimated frequencies, individual losses, and yearly losses. This allows the requirements team to ensure that the security requirements are cost effective.
• Provide Security Training.
  Most requirements engineers are not trained at all in security, and the few that have been trained have only been given an overview of security architectural mechanisms such as passwords and encryption rather than in actual security requirements. Thus, the most common problem with security requirements, when they are specified at all, is that they tend to be accidentally replaced with security-specific architectural constraints that may unnecessarily constrain the security team from using the most appropriate security mechanisms for meeting the true underlying security requirements.
• Requirements vs. Architectural Mechanisms and Design Decisions.
  Care should be taken to avoid unnecessarily and prematurely specifying architectural mechanisms for fulfilling unspecified security requirements (e.g., specifying the use of user identifiers and passwords as identification and authentication requirements). The requirements team is often not qualified to make architecture decisions, and doing so may cause problems in the relationship between the requirements team and the architecture team. Specifying security constraints may also unnecessarily prevent the architecture team from choosing different, and potentially better, security mechanisms (e.g., biometric devices such as retina scanners, fingerprint readers) to meet the real underlying security requirements. If specific security architectural mechanisms and designs must be specified (e.g., for legal, constractural, or similar reasons), then specify them as architectural and design constraints, not as security requirements.
• Validating Security Requirements.
  Security requirements typically require security-specific testing in addition to the traditional types of testing. Test cases may be based on misuse cases that are analogous to the test cases developed for use case based functional testing. Also, load and stress testing can be useful for testing Denial of Service (DoS) attacks.