Secure Development - SAMM - Security Requirements

This post continues my 12-part series about the Software Assurance Maturity Model (SAMM). Today we will be talking about Security Requirements, the second security practice in the Construction function. Almost all software development is driven by a set of business requirements, but unfortunately security is often not factored into these requirements at the start of a project. To address this issue, analysts and managers should work to integrate Security Requirements into a development project from the beginning. Security Requirements serve as a "hook" for security: once security has been written into the requirements, it will naturally follow the development lifecycle through design, development, testing, and deployment to production. As with all other requirements, it is critical that Security Requirements meet the standard criteria: for example, they must be complete, consistent, testable, and feasible.

First Maturity Level

The first step for an organization is to review the expected security functionality of each project under development (or in an enhancement/release cycle). One method for eliciting comprehensive security requirements is to review all functional requirements with the stakeholders while focusing on "expectations for data security, access control, transaction integrity, criticality of business function, separation of duties, uptime, etc." The resulting security requirements should explicitly state the application's security-related behavior. For example, while reviewing the following functional requirement, many additional security requirements can be discovered:

Functional Requirement: Bank customers must be able to view their account transaction history from the past 90 days via a web browser.

Sample Derived Security Requirements

1. Customers must be authenticated by two-factor authentication (password plus a token code) before being allowed to access any account information.
2. The application must require at least 256-bit SSL end-to-end encryption for all customer or account information data transmission.
3. Once a customer is logged in, his authenticated session shall expire after 5 minutes of inactivity and shall never exceed 1 hour regardless of activity.
4. If a customer forgets his password, he must perform the following steps before being allowed to reset his password: 1) answer one previously defined security question, 2) provide his full ATM card number, and 3) prove ownership of the e-mail address associated with the account by clicking on a unique link sent to that address.
5. When setting up online access to an account, customers must be required to set up three security questions to support Requirement 4.
6. The security questions referenced in Requirements 4 and 5 should not ask about any publicly available information, such as mother's maiden name, high school attended, etc.
7. The unique link being e-mailed in Requirement 4 should have an entropy of at least 256 bits to prevent brute-force guessing.
8. (and many more: as you can see, even a seemingly simple functional requirement can dictate a variety of security requirements)

Additionally, organizations should use the requirements phase to integrate industry best practices derived from a variety of sources, such as public guidelines, internal standards or policies, or regulatory/compliance requirements. A few examples of public best-practice guidance include ITIL, COBIT, and SAS 70--but there are countless others, depending on location, industry, etc. Examples of regulatory/compliance requirements are PCI-DSS (credit card data), HIPAA (healthcare data), Sarbanes-Oxley (covers financial disclosure and internal controls/audit), along with many other industry-specific standards. These best practices should be integrated into the development process by writing specific requirements (security or regular requirements) rather than relying on bolt-on solutions later in the lifecycle.

Second Maturity Level

At this level, organizations should work to increase the granularity of security requirements and use known risks to drive security requirements. For increased granularity, an access control matrix can be very helpful in explicitly and comprehensively specifying the application's expected security behavior. The matrix lists roles on one axis and resources/capabilities on the other. At the intersection of both, it should note the type of access desired: for example, read/write/delete.

The project team should use any known risks (from business risk profiles, application threat models, design/code reviews, or security testing) to generate new security requirements and refine existing ones. Specific abuse cases can also be used to define security requirements that directly address such cases. In general, the organization should encourage its project teams to look for new risks and respond (where possible) by specifically addressing them via security requirements, rather than simply documenting them.

Third Maturity Level

At the highest maturity level, organizations should mandate a security requirements audit process internally and also require third-party developers to adhere to security best practices by writing security language into supplier agreements. The internal security requirements audit process should ensure that the activities at the first and second maturity levels are being performed properly: specific security requirements derived from functional requirements, best practices written into requirements, access control matrix, and directly addressing known risks. If there are unfulfilled security requirements, they should be listed along with a justification and estimated implementation date.

Third-party software is often a major source of risk if not managed properly. Whether the software is being custom-written by a third party or is a COTS package, the vendor should be held accountable for security via its contract. In the case of custom-written software, your organization should require the vendor to follow the security requirements process and to add specific security activities to their development process: for example, design reviews, code reviews, and security testing. Unfortunately, this approach does not work for COTS software being developed under the vendor's own process. However, in this case your organization should request and review documentation on the security practices used during development and write clauses into your contract that give the vendor responsibility for potential security issues in the future.

Summary

Security Requirements are at the heart of the secure development lifecycle: they explicitly define the application's security properties and behaviors, and they ensure that security is considered throughout the lifecycle. Next time, we will talk about the final practice in the Construction function: Secure Architecture. This practice encourages organizations to move toward secure design patterns, re-usable security components, and a centralized security infrastructure.