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 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 between 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.
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.
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(n):
A. Functional requirements matrix
B. Subject-object-activity matrix
C. Use cases
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 between 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 alter the same object. They are caused by multithreading and are resolved through atomic actions under mutual exclusion conditions. The key is in detecting when they occur.
7. D. Secure coding standards are language-specific rules and recommended practices that provide for secure programming.
8. D. The requirements traceability matrix (RTM) is a grid that allows users to track and manage requirements and implementation details.
9. A. The specific architecture details come from requirements, but are not specified directly as functional requirements.
10. C. Access control lists are associated with users, objects, and activities, but are assigned to objects.
11. B. 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.
12. A. Deployment environment requirements include issues such as corporate standards for databases, web services, data storage, and more.
13. A. Complex conditional logic with unhandled states, even if rare or unexpected, can result in infinite loops.
14. C. Use cases are specifically well suited for business requirements that are not well defined.
15. D. To assist designers and developers in correctly defining the relationships between users (subjects), objects, and activities, a matrix referred to as the subject-object-activity matrix is employed.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.