In the traditional software development lifecycle (SDLC), security testing is often an afterthought, and security verification and testing efforts are delayed until after the software has been developed. Vulnerabilities are an emergent property of software which appear throughout the design and implementation cycles. Therefore, you need to adopt a "before, during, and after" approach to software development.

It is not possible to "test" security into software. Many statistics show that the earlier a defect is uncovered, the cheaper it is to fix. Consequently, it is important to employ many processes throughout the lifecycle.

A full lifecycle approach is the only way to achieve secure software, preaches Chris Wysopal, experienced security practitioner, and my coauthor on The Art of Software Security Testing. This article discusses the importance of incorporating and addressing security issues early on in the lifecycle. It outlines a process called the Secure Software Development Lifecycle (SSDL), which includes early placement of security quality gates. It discusses how security needs should be addressed in the software development lifecycle, starting with the earliest phases.

Fitting Security Testing into the Software Development Lifecycle

The SSDL represents a structured approach toward implementing and performing secure software development. The SSDL approach mirrors the benefits of modern rapid application development efforts. Such efforts engage the stakeholders early on, as well as throughout analysis, design, and development of each software build, which is created in an incremental fashion.

Adhering to the SSDL, security issues are evaluated and addressed early in the system's lifecycle, during business analysis, throughout the requirements phase, and during design and development of each software build. This early involvement allows the security team to provide a quality review of the security requirements specification, attack use cases, and software design. The team also will more completely understand business needs and requirements and the risks associated with them. Finally, the team can design and architect the most appropriate system environment using secure development methods, threat-modeling efforts, and so on to generate a more secure design.

Early involvement is significant because requirements or attack use cases comprise the foundation or reference point from which security requirements are defined and by which success is measured. The security team needs to review the system or application's functional specification.

Security test strategies should be determined during the functional specification/requirements phase. If you keep system security in mind, the product design and coding standards can provide the proper environment.

The SSDL is geared toward ensuring successful implementation of secure software. It has six primary components:

• Phase 1: Security guidelines, rules, and regulations
• Phase 2: Security requirements: attack use cases
• Phase 3: Architectural and design reviews/threat modeling
• Phase 4: Secure coding guidelines
• Phase 5: Black/gray/white box testing
• Phase 6: Determining exploitability

Once it's been determined that a vulnerability has a high level of exploitability, the respective mitigation strategies need to be evaluated and implemented.

In addition, a process needs to be in place that allows for deploying the application securely. Secure deployment means that the software is installed with secure defaults. File permissions need to be set appropriately, and the secure settings of the application's configuration are used.

After the software has been deployed securely, its security needs to be maintained throughout its existence. An all-encompassing software patch management process needs to be in place. Emerging threats need to be evaluated, and vulnerabilities need to be prioritized and managed. See the section "Patch Management: Managing Vulnerabilities" for more details.

Infrastructure security, such as firewall, DMZ, and IDS management, is assumed to be in place. Backup/recoverability and availability plans need to be in place. The focus of the SSDL described here is to address secure development processes. No matter how strong your firewall rule sets are or how diligent your infrastructure patching mechanism is, if your Web application developers haven't followed secure coding practices, attackers can walk right into your systems through port 80.

It is often unclear whose job security is. Roles and responsibilities need to be defined, as discussed in the section "Roles and Responsibilities" later on.

Attack Patterns to Apply Throughout the SSDL

1. Define security/software development roles and responsibilities.
2. Understand the security regulations your system has to abide by, as applicable.
3. Request a security policy if none exists.
4. Request documented security requirements and/or attack use cases.
5. Develop and execute test cases for adherence to umbrella security regulations, if applicable. Develop and execute test cases for the security requirements/attack use cases described throughout this article.
6. Request secure coding guidelines, and train software developers and testers on them.
7. Test for adherence to secure coding practices.
8. Participate in threat modeling walkthroughs, and prioritize security tests.
9. Understand and practice secure deployment practices.
10. Maintain a secure system by having a patch management process in place, including evaluating exploitability.