23 May, 2014

A More Secure Development Lifecycle III: Requirements Gathering Techniques

by Marjorie Meadors

In my last post, I identified security requirements that need to be addressed in any software development project. These requirements are important to building a more secure application. This post will discuss several techniques that are useful in eliciting the security requirements information. My last post in this series will discuss techniques that can be used in the design phase to design a more secure application.

Before I start talking about each technique, I would like to mention that they can be used in any type of SDLC process, including waterfall, agile, or a hybrid of both. Every process gathers requirements so the techniques listed below can be used in any SDLC process.

Several techniques can be utilized to obtain security requirements from SMEs and end users. Brainstorming can elicit preliminary requirements data but, due to its unstructured nature, can miss requirements or focus on trivial requirements. Brainstorming can be good for getting SMEs and end users thinking about security concepts that will be reviewed on the project, but there are several other techniques that produce better overall security requirements.

Surveys/Questionnaires/Interviews

A more structured way to elicit security requirements is through surveys, including questionnaires and interviews. The surveys should include specific and open-ended questions. The open-ended questions will probably generate more questions, which means this will be an iterative process. Some example questions would ask what type of data is processed in the application, what user roles exist, what the recovery requirements are for the application, and if there are any privacy requirements. The surveys and interviews should be presented in an objective way so that answers are not steered in a predetermined direction. Even if you have an initial idea of how the software should be built, you may find a different outcome by letting the requirements develop naturally from the SMEs and end users.

Policy Decomposition

Policy decomposition is a technique that is used to develop security requirements based on internal and external policies. Policies can encompass several of the requirements mentioned previously, including confidentiality, archiving, and auditing/logging.

The process should start with reviewing internal and external policy documents such as the Payment Card Industry Data Security Standard (PCI DSS), the Health Information Portability and Accountability Act (HIPAA), and authentication policy. The policy documents have to be broken into high-level objectives such as data protection, configuration management, and code review. The objectives are then used to create security requirements. An example of a configuration management security requirement derived from policy decomposition is that all software must be tested before deployment in production. This requirement is broken down further into how the software is tested and who is required to approve the test results before deployment. The following diagram from the Official (ISC)2 Guide to the CSSLP by Mano Paul illustrates the process.

Data Classification

Data classification is an exercise that organizes data based on its level of sensitivity. It may be easy to encrypt all application data but that may not be cost effective. Additionally, encrypting all data provides more cipher text than just encrypting select data; an attacker may be able to use the extra cipher text to determine the key. Instead, data should be classified based on confidentiality, integrity, and availability and then encrypted when necessary. For example, if data is publicly disclosed, it should be classified as public and should not be encrypted. NIST Special Publication 800-18 contains a data classification framework that can be used to classify data by the objectives of confidentiality, integrity, and availability. The following diagram from the Official (ISC)2 Guide to the CSSLP by Mano Paul illustrates the data classification process.

Use and Misuse Case Modeling

This technique diagrams the normal and abnormal behavior of an application. A use case model illustrates the sequence of events for a component of the application. The models help to clarify requirements for the application and identify the actors involved in each process.

Misuse cases are use cases that model abnormal behavior. For example, a misuse case model can show what happens when a database is down or when a user does not have access to the database. Many security requirements can be derived from use case and misuse case models.

Use cases can help you determine authentication requirements and authorization rules. By illustrating which actors access the same data at the same time, a use case can provide you sequence and timing requirements. This information can help to define which groups of data should be updated as a transaction to avoid a race condition. If a misuse case shows that a certain type of actor does not have access, that can be captured for access control information. Error and exception management requirements can also be derived from misuse cases. For example, you may decide you need a centralized error handling process based on the number and type of errors the application will generate.

Subject–Object Matrix

The subject-object matrix is created from the use cases. The subjects and objects are populated in a table, the subjects or roles listed across the top and the objects down the side. The intersection of the subjects and objects show whether the subject is allowed to access the object. The matrix can be used to create misuse cases. If a subject should not access an object, a misuse case can be created to identify the scenario to deal with an access attempt. The scenario could involve just a denial of access or a denial and logging. The availability requirement comes into play on this misuse case since the denial of access could help perpetuate a denial of service attack. The subject-object matrix and use case modeling can be used in threat modeling; this will be discussed in my next post on secure design.

An example of a subject-object matrix is displayed below. A CSP can read and write a customer object but cannot access a vendor or inventory object. In addition, a buyer subject can read and write a vendor object but not write an inventory object (the inventory clerk will create that object). Instead of simple read and write access, the matrix can also be created using CRUD (Create-Read-Update-Delete) access to define the relationships at a more detailed level.

After these and any other requirement gathering processes that may be part of your SDLC are completed, a Requirements Traceability Matrix (RTM) is created. The RTM is a table that lists all the business requirements in one column and all the functional and testing requirements in other columns. Security requirements should have their own column so they are not missed in the design phase. This also helps to illustrate how security requirements relate to business requirements, reinforcing how important security requirements are to the success of the application.

An example of an RTM is shown below. As you can see, one of the business requirements does not have a security requirement. This business requirement calls for database passwords to be hashed. If no security requirement states how the hashing should be performed, the developers could choose a hashing algorithm like MD5, which is considered to be cryptographically broken by the U.S. Computer Emergency Response Team (CERT) of the Department of Homeland Security. Having a security requirement that states how the passwords should be hashed will make sure that a potential vulnerability is not built into the application.

More information on these techniques can be found in the Official (ISC)2 Guide to the CSSLP by Mano Paul which is a great resource for information on a secure development lifecycle as well as a good source to use for preparing to take the Certified Secure Software Lifecycle Professional (CSSLP) credential.

My final post in this series will discuss secure software design with a high-level look at the considerations in this phase of the SDLC.