SSDL Phase 1: Security Guidelines, Rules, and Regulations

Security guidelines, rules, and regulations must be considered during the project's inception phase. This first phase of SSDL is considered the umbrella requirement.

A system-wide specification is created that defines the security requirements that apply to the system; it can be based on specific government regulations. One such company-wide regulation could be the Sarbanes-Oxley Act of 2002, which contains specific security requirements. For example, Section 404 of SOX states, "Various internal controls must be in place to curtail fraud and abuse." This can serve as a baseline for creating a company-wide security policy that covers this requirement. Role-based permission levels, access-level controls, and password standards and controls are just some of the things that need to be implemented and tested to meet the requirements of this specific SOX section.

OWASP lists a few security standards, such as the ISO 17799, the International Standard for Information Security Management, a well-adopted and well-understood standard published by the International Organization for Standardization. However, it has rarely been applied specifically to those concerned with managing a secure Web site. When you implement a secure Web application, information security management is unavoidable. ISO 17799 does an excellent job of identifying policies and procedures you should consider. But it does not explain how they should be implemented, nor does it give you the tools to implement them. It is simply a guide of which policies and procedures you should consider. It does not mandate that you should implement them all.

OWASP also recommends the Web Application Security Standards (WASS) project, which aims to create a proposed set of minimum requirements a Web application must exhibit if it processes credit card information. The project's goal is to develop specific, testable criteria that can stand alone or can be integrated into existing security standards such as the Cardholder Information Security Program (CISP), which is vendor- and technology-neutral. By testing against this standard, you should be able to determine that minimal security procedures and adherence to best practices have been followed in the development of a Web-based application.

Another such company-wide security regulation could state, for example, "The system needs to consider the HIPAA privacy and security regulations and be compliant" or "The system will meet the FISMA standards" or "The system will be BASEL II-compatible" or "The system needs to meet the Payment Card Industry Data Security Standard" or "We have to abide by the Graham-Leech-Bliley (Financial Modernization) Act," to name just a few. Sometimes a company is required to adhere to numerous such standards, and the creator of the security policy needs to consider all the requirements dictated in them.

Some systems do not fall under the purview of any regulatory acts or guidelines. In those cases, a security policy still should be developed. This article outlines the beginnings of such a security policy. For example, it is important to follow a secure software development lifecycle (SSDL) that includes secure software installation procedures and a well-thought-out patch management process.

Backup/recovery/availability are beyond the scope of this article, but they should be part of your security policy, too.

In the case of no dictated overarching security standard, you can move directly to Phase 2, Security Requirements.

It is important not only to document the security policy but also to continuously enforce it by tracking and evaluating it on an ongoing basis.

SSDL Phase 2: Security Requirements: Attack Use Cases

Security requirements are the second phase of the SSDL. A common mistake is to omit security requirements from any type of requirements documentation. However, it is important to document security requirements. Not only do security requirements aid in software design, implementation, and test case development, but they also can help determine technology choices and areas of risk.

The security engineer should insist that associated security requirements be described and documented along with each functional requirement. Each functional requirement description should contain a section titled "Security Requirements," documenting any specific security needs of that particular requirement that deviate from the system-wide security policy or specification.

It is important that guidelines for requirement development and documentation be defined at the project's outset. In all but the smallest programs, careful analysis is required to ensure that the system is developed properly. Attack use cases are one way to document security requirements. They can lead to more thorough secure system designs and test procedures.

Defining a requirement's specific quality measure helps rationalize fuzzy requirements. For example, everyone would agree with a statement such as "The system must be highly secure," but each person may have a different interpretation of "highly secure." Security requirements do not endow the system with specific functions. Instead, they constrain or further define how the system will handle any function that shouldn't be allowed. Here is where the analysts should look at the system from an attacker's point of view. Attack use cases can be developed that show behavioral flows that are not allowed or are unauthorized. They can help you understand and analyze security implications of pre- and post conditions. "Includes" relationships can illustrate many protection mechanisms, such as the logon process. "Extends" relationships can illustrate many detection mechanisms, such as audit logging. Attack cases list ways in which the system could possibly be attacked.

Security defect prevention is the use of techniques and processes that can help detect and avoid security errors before they propagate to later development phases. Defect prevention is most effective during the requirements phase, when the impact of a change required to fix a defect is low. If security is in everyone's mind from the beginning of the development lifecycle, they can help recognize omissions, discrepancies, ambiguities, and other problems that may affect the project's security.

Requirements traceability ensures that each security requirement is identified in such a way that it can be associated with all parts of the system where it is used. For any change to requirements, is it possible to identify all parts of the system where this change has an effect?

Traceability also lets you collect information about individual requirements and other parts of the system that could be affected, such as designs, code, or tests, if a requirement changes. When informed of requirement changes, security testers can make sure that all affected areas are adjusted accordingly.

Sample Security Requirements

• The application stores sensitive user information that must be protected for HIPAA compliance. To that end, strong encryption must be used to protect all sensitive user information wherever it is stored.
• The application transmits sensitive user information across potentially untrusted or unsecured networks. To protect the data, communication channels must be encrypted to prevent snooping, and mutual cryptographic authentication must be employed to prevent man-in-the-middle attacks.
• The application sends private data over the network; therefore, communication encryption is a requirement.
• The application must remain available to legitimate users. Resource utilization by remote users must be monitored and limited to prevent or mitigate denial-of-service attacks.
• The application supports multiple users with different levels of privilege. The application assigns users to multiple privilege levels and defines the actions each privilege level is authorized to perform. The various privilege levels need to be defined and tested. Mitigations for authorization bypass attacks need to be defined.
• The application takes user input and uses SQL. SQL injection mitigations are a requirement.

These are just a few examples. A tester who solely relies on requirements for her testing and who usually would miss any type of security testing is now armed with this set of security requirements and can start developing the security test cases.