Requirements for Secure Software

Requirements for security functionality in software-intensive systems are often confused with requirements for secure software. The first category includes functions that implement a security policy, such as an information security policy in a software-intensive information system. These are the functional areas of access control, identification, authentication and authorization, and the functions that perform encryption, decryption, and key management These functions prevent the violation of the security properties of the system or the information it processes, such as unauthorized access, modification, denial of service, disclosure, etc. They are also known as security service requirements.

The second category of requirements directly affects the likelihood that the software itself will be secure. These are the nonfunctional—or property—

requirements that collectively ensure that the system will remain dependable even when that dependability is threatened. These requirements are often directed toward reducing or eliminating vulnerabilities in the software. They are more closely tied to process, to the software development plan, and to project management direction. These requirements deal with things like input validation, exception handling, sandboxing, etc.

Software Security Assurance State-of-the-Art Report (SOAR) 13 Intended Audience.5 Assumptions and Constraints.

Section 5 SDLC Processes and Methods and the Security of Software

Microsoft calls the second category Security Objectives and recommends Security ObjectivesSecurity Objectives that developers define security objectives and security requirements early in the process. Security objectives are goals and constraints that affect the confidentiality, integrity, and availability of the data and the application software. [171]

Significantly influencing both categories of requirements is an understanding of the threat environment, calculations of risk, and identification of mitigation strategies.

5.2.1 Software Requirements Engineering

The software requirements phase covers everything that needs to occur before design begins. Inputs may include the system specification, with functions allocated to software, and a software development/project plan. Inputs come from many sources, including the customer, users, management, QA and test groups, and as systems requirements allocated to software. The main output of the requirements phase is the requirements specification that defines both functional and nonfunctional aspects of the software. The end of phase is marked by acceptance of the specification by the customer and other stakeholders. The requirements may be modified in the course of the development effort as needs for changes are identified.

Figure 5-6 shows a high-level view of the tasks and artifacts involved in the requirements phase of a software development effort.

Figure 5-6. Requirements Engineering for Survivable Systems [172]

2EQUIREMENTS

%LICITATION

$OMAIN5SER

%XISTING 2EGULATIONS

3TANDARDS ETC

2EQUIREMENTS

AND 2EQUIREMENTS

$OCUMENTATION

2EQUIREMENTS

$OCUMENT

3YSTEM

$OCUMENT

2EQUIREMENTS 6ALIDATION

!GREED 5PON 2EQUIREMENTS

Software Security Assurance State-of-the-Art Report (SOAR)

13 Intended Audience.6 Context.

Section 5 SDLC Processes and Methods and the Security of Software

There is a rich body of work and results on requirements engineering, as well as tools and techniques to support the processes. Unfortunately, most of this work does not explicitly consider security. Work that does is usually concerned with security requirements in the sense of requirements engineering for the security functionality in a system, such as access controls. Our concern, however, is the engineering of requirements for security as an emergent property of a software system. Although the implementation of security functionality may coincidentally satisfy many requirements for security as a software property, different analyses will be needed to attain these different objectives.

The purpose of this section is to highlight differences between

requirements phase activities as they are normally performed and how they could be adapted and augmented to increase the security of the software under development. Figure 5-7 shows examples of additional activities and artifacts for increasing software security overlaid on the generic requirements process.

Figure 5-7. Secure Software Additions to Requirements Engineering Process

For Further Reading

“Requirements Engineering” [web page], (Washington DC: US CERT)

Available from: https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements.html

5.2.1.1 Traditional Requirements Methods and Secure Software Specification

To begin with, the source of security requirements problems are not limited to the security domain. Many software security problems originate in the inadequate or inaccurate specification of the requirements for the software or from the mismatch between the interpretation of the requirements during

2EQUIREMENTS

Software Security Assurance State-of-the-Art Report (SOAR) 13 Intended Audience.7

Section 5 SDLC Processes and Methods and the Security of Software

development and their actual intent. [173] Requirements engineering is hard to do, and harder to do well. The number of requirements needed to adequately define even a small software project can be very large. That number grows exponentially with the effects of large size, complexity, and integration into evolving operational environments.

Some of the security-specific issues involved in requirements engineering that have been cited by various authors include—

u The people involved are not likely to know or care (in a conscious sense) about nonfunctional requirements. They will not bring them up on their own. Stakeholders have a tendency to take for granted

nonfunctional security needs.

u Traditional techniques and guidelines tend to be more focused on functional requirements.

u Security controls are perceived to limit functionality or interfere with usability.

u It is more difficult to specify what a system should not do than what it should do.

u Stakeholders must understand the threats facing a system in order to build defenses against them, but the threat environment faced by the delivered system will be different from the threat environment existing at the time of requirements development because the threats are evolving.

u The users who help define the system are not typically the abusers from whom the system must be protected.

u It requires creativity, experience, and a different mindset to define the bad things that could happen.

u There may be security issues involving development team personnel, including access to security-competent development or integration contract services. Parts of the development may be outsourced or offshored. Risk assessment and/or vulnerability information may be classified, precluding access by developers without clearances.

u There may be lack of understanding of how a component fits into the larger system, i.e., a component that may behave securely when operating in stand alone made may not behave securely when assembled with other components (see Section 5.1.1.2 for more information on security issues of component-based development).

u There are questions of who will be held accountable (professionally and/or contractually/legally) for software that turns out to be insecure.

Currently, developers bear (at least some) responsibility for failed functionality (i.e., functional requirements that are not satisfied in the implemented system). Can this already-accepted accountability be expanded to include comparable failures in security (i.e., security was specified, but not achieved in the implemented system)? What about responsibility for not specifying security requirements in the first place,

Software Security Assurance State-of-the-Art Report (SOAR)

13 Intended Audience.8

Section 5 SDLC Processes and Methods and the Security of Software

even when the intended execution environment for the software is known to be high-risk? If accountability can be enforced, who should be held responsible? The developer? The accreditor?

Secure software requirements engineering can usefully draw on work in related disciplines, such as—

u Software safety, e.g., medical devices, nuclear power

u Software survivability (also referred to as fault tolerance), e.g., telephone systems

u Embedded systems, e.g., space applications, weapons systems

u Software reliability (unreliable software contains defects that become vulnerabilities)

u Information systems (in particular, requirements for availability and integrity, also accountability and nonrepudiation).

The techniques and solutions in these disciplines are not sufficient for software security as is, because they tend to defend against natural dangers, i.e., hazards, whereas software must defend against malicious users and hostile attacks, i.e., threats. The threat landscape is more dynamic and much less predictable than hazards are.

Security has generally been included with the other nonfunctional requirements for software, such as performance and quality requirements.

During the requirements phase, nonfunctional security requirements are captured and defined as attributes of the software, but the process does not end there. The nonfunctional security requirements need to be mapped to functional requirements so that they can be built into the software and tested appropriately. For example, a requirement such as “The software must not be susceptible to buffer overflows” could be mapped to functional requirements for input validation and for use of only type-safe/memory-safe programming languages. Some of the use case adaptations to abuse and misuse cases (see Section 5.2.3.2.1) make this mapping step explicit.

By mapping the nonfunctional to functional requirements, the security requirements become a part of the overall requirements analysis process.

Potential conflicts with other functional requirements can be identified (and resolved). Not all of the nonfunctional requirements may be addressable as software functions, and so may need to be allocated back to the system level.

Certain types of pervasive security requirements may be best addressed as part of the system’s security policy, e.g., “All input from users must be validated to ensure its conformance with the expected format and length of that type of input.”

Software Security Assurance State-of-the-Art Report (SOAR) 13 Intended Audience.9

Section 5 SDLC Processes and Methods and the Security of Software

5.2.1.2 Security Experts on the Requirements Team

Although not all of the roles listed below will have the same level of

involvement, all should have input and should be able to review the results.

Unlike the conventional requirements team members—stakeholders, users, developers, project managers, software architects, quality assurance and testing—these additional roles serve more as consultants and advisors:

u Security Engineers—Security engineers can serve as liaisons to the systems-level, to resolve issues of what security can be incorporated into software and what is outside.

u Risk Analysts—Risk assessment and threat analysis are key sources for requirements that affect the security of the software, especially for later in the analysis and prioritization of security.

u Certifiers and Accreditors—Software that is to be certified or accredited must meet the requirements for the particular certification’s standard or assurance level.

u Information Assurance (IA) Experts—IA experts with experience in defending and repairing existing software can provide insight on how to define and build new software.