12h 39m remaining

CHAPTER 7

Requirements

In this chapter you will

• Learn basic terminology associated with software requirements

• Examine functional requirements used to implement security in systems

• Examine use cases as they apply to the requirements of a system

• Learn to build abuse cases to examine security properties of a system

• Examine operational requirements used to implement security in systems

Requirements are the blueprint by which software is designed, built, and tested. As one of the

important foundational elements, it is important to manage this portion of the software development

lifecycle (SDLC) process properly. Requirements set the expectations for what is being built and how it is

expected to operate. Developing and understanding the requirements early in the SDLC process are

important, for if one has to go back and add new requirements later in the process, it can cause

significant issues, including rework.

Functional Requirements

Functional requirements describe how the software is expected to function. They begin as business

requirements and can come from several different places. The line of business that is going to use the

software has some business functionality it wishes to achieve with the new software. These business

requirements are translated into functional requirements. The IT operations group may have standard

requirements, such as deployment platform requirements, database requirements, Disaster

Recovery/Business Continuity Planning (DR/BCP) requirements, infrastructure requirements, and more.

The organization may have its own coding requirements in terms of good programming and

maintainability standards. Security may have its own set of requirements. In the end, all of these

business requirements must be translated into functional requirements that can be followed by

designers, coders, testers, and more to ensure they are met as part of the SDLC process.

Role and User Definitions

Role and user definitions are the statements of who will be using what functionality of the software. At a

high level, these will be in generic form, such as which groups of users are allowed to use the system.

Subsequent refinements will detail specifics, such as which users are allowed which functionality as part

of their job. The detailed listing of what users are involved in a system form part of the use-case

definition. In computer science terms, users are referred to as subjects. This term is important to

understand the subject-object-activity matrix presented later in this section.

Objects

Objects are items that users (subjects) interact with in the operation of a system. An object can be a file,

a database record, a system, or program element. Anything that can be accessed is an object. One

method of controlling access is through the use of access control lists assigned to objects. As with

subjects, objects form an important part of the subject-object-activity matrix. Specifically defining the

objects and their function in a system is an important part of the SDLC. This ensures all members of the

development team can properly use a common set of objects and control the interactions appropriately.

Activities/Actions

Activities or actions are the permitted events that a subject can perform on an associated object. The

specific set of activities is defined by the object. A database record can be created, read, updated, or

deleted. A file can be accessed, modified, deleted, etc. For each object in the system, all possible

activities/actions should be defined and documented. Undocumented functionality has been the

downfall of many a system when a user found an activity that was not considered during design and

construction, but still occurred, allowing functionality outside of the design parameters.

Subject-Object-Activity Matrix

Subjects represent who, objects represent what, and activities or actions represent the how of the

subject-object-activity relationship. Understanding the activities that are permitted or denied in each

subject-object combination is an important requirements exercise. To assist designers and developers in

correctly defining these relationships, a matrix referred to as the subject-object-activity matrix is

employed. For each subject, all of the objects are listed, along with the activities for each object. For

each combination, the security requirement of the state is then defined. This results in a master list of

allowable actions and another master list of denied actions. These lists are useful in creating appropriate

use and misuse cases, respectively. The subject-object-activity matrix is a tool that permits concise

communication about allowed system interactions.

Use Cases

Use cases are a powerful technique for determining functional requirements in developer-friendly

terms. A use case is a specific example of an intended behavior of the system. Defining use cases allows

a mechanism by which the intended behavior (functional requirement) of a system can be defined for

both developers and testers. Use cases are not intended for all subject-object interactions, as the

documentation requirement would exceed the utility. Use cases are not a substitute for documenting

the specific requirements. Where use cases are helpful is in the description of complex or confusing or

ambiguous situations associated with user interactions with the system. This facilitates the correct

design of both the software and the test apparatus to cover what would otherwise be incomplete due to

poorly articulated requirements.

EXAM TIP Use cases are constructed of actors representing users and intended system behaviors, with

the relationships between them depicted graphically.

Use-case modeling shows the intended system behavior (activity) for actors (users). This combination is

referred to as a use case, and is typically presented in a graphical format. Users are depicted as stick

figures, and the intended system functions as ellipses. Use-case modeling requires the identification of

the appropriate actors, whether person, role, or process (nonhuman system), as well as the desired

system functions. The graphical nature enables the construction of complex business processes in a

simple-to-understand form. When sequences of actions are important, another diagram can be added

to explain this. Figure 7-1 illustrates a use-case model for a portion of an online account system.

FIGURE 7-1 Use-case diagram

Abuse Cases (Inside and Outside Adversaries)

Misuse or abuse cases can be considered a form of use case illustrating specifically prohibited actions.

Although one could consider the situation that anything not specifically allowed should be denied,

making this redundant, misuse cases still serve a valuable role in communicating requirements to

developers and testers. Figure 7-2 illustrates a series of misuse cases associated with the online account

management system.

FIGURE 7-2 Misuse-case diagram

In this diagram, the actor is now labeled as unauthorized. This is different from the previous

authenticated user, as this misuse actor may indeed be authenticated. The misuse actor could be

another customer, or an internal worker with some form of access required to manage the system.

Through brainstorming exercises, the development team has discovered the possibility for someone

with significant privilege—that is, a system administrator—to have the ability to create a new payee on

an account. This would enable them to put themselves or a proxy into the automatic bill-pay system.

This would not be an authorized transaction, and to mitigate such activity, a design of an out-of-band

mechanism—that is, email the user for permission—makes it significantly more difficult for this activity

to be carried out, as the misuser must now also have email access to the other user’s information to

approve the new payee. What this misuse case specifically does is draw attention to ensuring that

authenticated but not authorized users do not have the ability to interact in specific ways. As use cases

also drive testing, this misuse case ensures that these issues are also tested as another form of defense.

Misuse cases can present commonly known attack scenarios, and are designed to facilitate

communication among designers, developers, and testers to ensure that potential security holes are

managed in a proactive manner. Misuse cases can examine a system from an attacker’s point of view,

whether the attacker is an inside threat or an outside one. Properly constructed misuse cases can trigger

specific test scenarios to ensure known weaknesses have been recognized and dealt with appropriately

before deployment.

NOTE SAFECode has made significant contributions to development and distribution use cases. They

have published a useful document describing “Practical Security Stories and Security Tasks for Agile

Development Environments,” available for use and free download at

https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf.

Sequencing and Timing

In today’s multithreaded, concurrent operating model, it is possible for different systems to attempt to

interact with the same object at the same time. It is also possible for events to occur out of sequence

based on timing differences between different threads of a program. Sequence and timing issues such

as race conditions and infinite loops influence both design and implementation of data activities.

Understanding how and where these conditions can occur is important to members of the development

team. In technical terms, what develops is known as a race condition, or from the attack point of view, a

system is vulnerable to a time of check/time of use (TOC/TOU) attack.

EXAM TIP A time of check/time of use attack is one that takes advantage of a separation between the

time a program checks a value and when it uses the value, allowing an unauthorized manipulation that

can affect the outcome of a process.

Race conditions are software flaws that arise from different threads or processes with a dependence on

an object or resource that affects another thread or process. A classic race condition is when one thread

depends on a value (A) from another function that is actively being changed by a separate process. The

first process cannot complete its work until the second process changes the value of A. If the second

function is waiting for the first function to finish, a lock is created by the two processes and their

interdependence. These conditions can be difficult to predict and find. Multiple unsynchronized threads,

sometimes across multiple systems, create complex logic loops for seemingly simple atomic functions.

Understanding and managing record locks is an essential element in a modern, diverse object

programming environment.

Race conditions are defined by race windows, a period of opportunity when concurrent threads can

compete in attempting to alter the same object. The first step to avoid race conditions is to identify the

race windows. Then, once the windows are identified, the system can be designed so that they are not

called concurrently, a process known as mutual exclusion.

Another timing issue is the infinite loop. When program logic becomes complex—for instance, date

processing for leap years—care should be taken to ensure that all conditions are covered and that error

and other loop-breaking mechanisms do not allow the program to enter a state where the loop controls

will fail. Failure to manage this exact property resulted in Microsoft Zune devices failing if they were

turned on across the New Year following a leap year. The control logic entered a sequence where a loop

would not be satisfied, resulting in the device crashing by entering an infinite loop and becoming

nonresponsive.

EXAM TIP Complex conditional logic with unhandled states, even if rare or unexpected, can result in

infinite loops. It is imperative that all conditions in each nested loop be handled in a positive fashion.

Secure Coding Standards

Secure coding standards are language-specific rules and recommended practices that provide for secure

programming. It is one thing to describe sources of vulnerabilities and errors in programs; it is another

matter to prescribe forms that, when implemented, will preclude the specific sets of vulnerabilities and

exploitable conditions found in typical code.

Application programming can be considered a form of manufacturing. Requirements are turned into

value-added product at the end of a series of business processes. Controlling these processes and

making them repeatable is one of the objectives of a secure development lifecycle. One of the tools an

organization can use to achieve this objective is the adoption of an enterprise-specific set of secure

coding standards.

Organizations should adopt the use of a secure application development framework as part of their

secure development lifecycle process. Because secure coding guidelines have been published for most

common languages, adoption of these practices is an important part of secure coding standards in an

enterprise. Adapting and adopting industry best practices are also important elements in the secure

development lifecycle.

One common problem in many programs results from poor error trapping and handling. This is a

problem that can benefit from an enterprise rule where all exceptions and errors are trapped by the

generating function and then handled in such a manner so as not to divulge internal information to

external users.

EXAM TIP To prevent error conditions from cascading or propagating through a system, each function

should practice complete error mitigation, including error trapping and complete handling, before

returning to the calling routine.

Logging is another area that can benefit from secure coding standards. Standards can be deployed

specifying what, where, and when issues should be logged. This serves two primary functions: it ensures

appropriate levels of logging, and it simplifies the management of the logging infrastructure.

Secure Coding Standards

Secure coding standards have been published by the Software Engineering Institute/CERT at Carnegie

Mellon University for C, C++, and Java. Each of these standards includes rules and recommended

practices for secure programming in the specific language.

Operational Requirements

Software is deployed in an enterprise environment where it is rarely completely on its own. Enterprises

will have standards as to deployment platforms, Linux, Microsoft Windows, specific types and versions

of database servers, web servers, and other infrastructure components.

Software in the enterprise rarely works all by itself without connections to other pieces of software. A

new system may provide new functionality, but would do so touching existing systems, such as

connections to users, parts databases, customer records, etc. One set of operational requirements is

built around the idea that a new or expanded system must interact with the existing systems over

existing channels and protocols. At a high level, this can be easily defined, but it is not until detailed

specifications are published that much utility is derived from the effort.

NOTE A complete SDLC solution ensures systems are secure by design, secure by default, and secure in

deployment. A system that is secure by design but deployed in an insecure configuration or method of

deployment can render the security in the system worthless.

One of the elements of secure software development is that it is secure in deployment. Ensuring that

systems are secure by design is commonly seen as the focus of an SDLC, but it is also important to

ensure systems are secure when deployed. This includes elements such as secure by default and secure

when deployed. Ensuring the default configuration maintains the security of an application if the system

defaults are chosen, and since this is a common configuration and should be a functioning configuration,

it should be secure.

Deployment Environment

Software will be deployed in the environment as best suits its maintainability, data access, and access to

needed services. Ultimately, at the finest level of detail, the functional requirements that relate to

system deployment will be detailed for use. An example is the use of a database and web server.

Corporate standards, dictated by personnel and infrastructure services, will drive many of the selections.

Although there are many different database servers and web servers in the marketplace, most

enterprises have already selected an enterprise standard, sometimes by type of data or usage.

Understanding and conforming to all the requisite infrastructure requirements are necessary to allow

seamless interconnectivity between different systems.

Requirements Traceability Matrix

The requirements traceability matrix (RTM) is a grid that assists the development team in tracking and

managing requirements and implementation details. The RTM assists in the documentation of the

relationships between security requirements, controls, and test/verification efforts. A sample RTM is

illustrated in Table 7-1. An RTM allows the automation of many requirements, providing the team to

gather sets of requirements from centralized systems. The security requirements could be brought in en

masse from a database based on an assessment of what systems and users will be involved in the

software. Software with only internal users will have a different set of requirements from that of a

customer interface across the Web. Having predefined sets of requirements for infrastructure, security,

data sources, and the like and using the RTM to promulgate them to the development teams will go a

long way in ensuring critical requirements are not overlooked.

Table 7-1 Sample Requirements Traceability Matrix

An RTM acts as a management tool and documentation system. By listing all of the requirements and

how they can be validated, it provides project managers the information they need to ensure all

requirements are appropriately managed and that none are missed. The RTM can assist with use-case

construction and ensure that elements are covered in testing.

Connecting the Dots

Requirements are the foundational element used in the development of any project. They come from

many sources. This chapter looked at functional requirements and operational requirements through

the lens of secure software design. In the first section of the book, threat modeling was covered, and

one of the key outputs from the threat modeling process is a set of requirements to mitigate known and

expected threats. The key to understanding requirements is that they represent all of the knowledge

one has with respect to building a project. The easiest set of requirements are those that represent the

features that a customer is asking for, but this is just the tip of the iceberg. Customers will never give

you the requirement “it needs to work” because, of course, that is always implied. The challenge is to

enumerate and document all of the related security, functional, and operational requirements that are

not stated because they are “implied.”

The task of creating a good list of security requirements is challenging at first, as there are so many

details, so many “sources of information,” that the sheer organization of it all is overwhelming. But as a

team goes from project to project, using a core list, refining it and adding to it, a more comprehensive

set can be developed over time. The bottom line to the story is simple: if you want a development team

to do something, it needs to be enumerated in the requirements for the project. Although this is

Chapter 7, a third of the way through the book, this is the true entry point for all work expectations in a

software development project. Every concept throughout this book only becomes a part of the team’s

effort through the requirements process.

Chapter Review

In this chapter, an examination of requirements associated with a system was covered. The chapter

began with a description of functional requirements and how these can come from numerous sources,

including the business, the architecture group to ensure interoperability with the existing enterprise

elements, and the security group to ensure adherence to security and compliance issues. The concepts

of users and roles, together with subjects and objects and the allowed activities or actions, were

presented. This chapter also covered the development of a subject-object-activity matrix defining

permitted activities.

Use cases and misuse cases were presented as a means of communicating business requirements and

security requirements across the SDLC. These tools can be powerful in communicating ambiguous

requirements and in ensuring that specific types of security issues are addressed. Other security

concerns, such as sequence and timing issues, infinite loops, and race conditions, were discussed. The

use of enterprise-wide secure coding standards to enforce conformity across the development

processes was presented. This is the first foundational element in defining an enterprise methodology

that assists in security and maintainability, and assists all members of the development team in

understanding how things work.

Operational and deployment requirements are those that ensure the system functions as designed

when deployed. To complete an examination of the requirements across a system, a requirements

traceability matrix was presented, communicating the relationship between requirements and

programmatic elements.

Quick Tips

• Functional requirements are those that describe how the software is expected to function.

• Business requirements must be translated into functional requirements that can be followed by

designers, coders, testers, and more to ensure they are met as part of the SDLC process.

• Role and user definitions are the statements of who will be using what functionality of the software.

• Objects are items that users (subjects) interact with in the operation of a system. An object can be a

file, a database record, a system, or a program element.

• Activities or actions are the legal events that a subject can perform on an associated object.

• The subject-object-activity matrix is a tool that permits concise communication about allowed system

interactions.

• A use case is a specific example of an intended behavior of the system.

• Misuse or abuse cases can be considered a form of use case illustrating specifically prohibited actions.

• Sequence and timing issues, such as race conditions and infinite loops, influence both design and

implementation of data activities.

• Secure coding standards are language-specific rules and recommended practices that provide for

secure programming.

• A complete SDLC solution ensures systems are secure by design, secure by default, and secure in

deployment.

• The requirements traceability matrix (RTM) is a grid that allows users to track and manage

requirements and implementation details.

Questions

To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of

preparedness, answer the following questions and then check your answers against the list of correct

answers found at the end of the chapter.

1. An activity designed to clarify requirements through the modeling of expected behaviors of a system

is called what?

A. Functional requirement decomposition

B. Requirement traceability matrix

C. Threat modeling

D. Use-case modeling

2. Business requirements are translated into _____ for the development team to act upon.

A. Programming rules

B. Data lifecycle elements

C. Functional requirements

D. Data flow diagrams

3. The “who” associated with programmatic functionality is referred to as what?

A. Role or user

B. Object

C. Activity or action

D. Program manager

4. Subjects interact with ______ in the operation of a system.

A. Users

B. Objects

C. Data

D. Actions

5. Presenting a known attack methodology to the development team to ensure appropriate mitigation

can be done via what?

A. Use case

B. Misuse case

C. Security requirement

D. Business requirement

6. Race conditions can be determined and controlled via what?

A. Multithreading

B. Mutual exclusion

C. Race windows

D. Atomic actions

7. Enterprise secure coding standards ensure what?

A. Certain types of vulnerabilities are precluded

B. Code is error free

C. Code is efficient

D. Security functionality is complete

8. A grid to assist the development team in tracking and managing requirements and implementation

details is known as a:

A. Functional requirements matrix

B. Subject-object-activity matrix

C. Use case

D. Requirements traceability matrix

9. Functional requirements include all of the following except:

A. Determining specific architecture details

B. Deployment platform considerations

C. DR/BCP requirements

D. Security requirements

10. Access control lists are assigned to _____ as part of a security scheme.

A. Users

B. Roles

C. Objects

D. Activities

11. To prevent error conditions from propagating through a system, each function should:

A. Log all abnormal conditions

B. Include error trapping and handling

C. Clear all global variables upon completion

D. Notify users of errors before continuing

12. Corporate standards, driven by defined infrastructure services, will drive:

A. Deployment environment requirements

B. Database requirements

C. Web server requirements

D. Data storage requirements

13. Complex conditional logic can result in _______ for unhandled states.

A. Infinite loops

B. Race conditions

C. Memory leaks

D. Input vulnerabilities

14. Use cases should be constructed for:

A. All requirements

B. All requirements that have security concerns

C. Business requirements that are poorly defined

D. Implementation features that need testing

15. To assist designers and developers in correctly defining the relationships between users and the

desired functions on objects, a ______ can be employed.

A. Functional requirements matrix

B. Requirements traceability matrix

C. Use case

D. Subject-object-activity matrix

Answers

1. D. Defining use cases provides a mechanism by which the intended behavior (functional

requirement) of a system can be defined for both developers and testers.

2. C. Functional requirements begin as business requirements and can come from several different

places.

3. A. Role and user definitions are the statements of who will be using what functionality of the

software.

4. B. Subjects interact with objects as defined in the subject-object-activity matrix. Although data could

be considered an object, object is the more complete answer.

5. B. Misuse cases can present commonly known attack scenarios and are designed to facilitate

communication among designers, developers, and testers to ensure that potential security holes are

managed in a proactive manner.

6. C. Race conditions are defined by race windows, a period of opportunity when concurrent threads

can compete in attempting to