First, create a system-wide specification 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.
Phase 2: Document Security Requirements, Develop Attack Use Cases
A common mistake is to omit security requirements from any type of requirements documentation. Not only do security requirements aid in software design, implementation and test case development, they also can help determine technology choices and areas of risk.
Phase 3: Perform Architectural and Design Reviews; Identify and Define Threat Models
Security practitioners need a solid understanding of the product’s architecture and design so that they can devise better and more complete security strategies, plans, designs, procedures and techniques. Early security team involvement can prevent insecure architectures and low-security designs, as well as help eliminate confusion about the application’s behavior later in the project life cycle.
Phase 4: Use Secure Coding Guidelines; Differentiate Between Design and Implementation Vulnerabilities
To understand how vulnerabilities get into all software, the developer must learn how to prevent them from sneaking into programs and must be able to differentiate design versus implementation vulnerabilities.
A design vulnerability is a flaw in the design that precludes overflows, and their output can help developers learn to prevent the errors in the first place.
Phase 5:Black-,White- And Gray-Box Testing
Black-, white- and gray-box testing refer to the perspective of the tester when designing test cases—black from outside with no visibility into the application under test, white from inside with total source code visibility, and gray with access to source code and the ability to seed target data and build specific tests for specific results.
Phase 6: Determine the Exploitability of Your Vulnerabilities
Ideally, every vulnerability discovered in the testing phase of the SSDL can be easily fixed. But depending on the cause, whether a design or implementation error, the effort required to address it can vary widely.
Determining a vulnerability’s exploitability involves weighing five factors:
• The access or positioning required by the attacker to attempt exploitation
• The level of access or privilege yielded by successful exploitation
• The time or work factor required to exploit the vulnerability
• The exploit’s potential reliability
• The repeatability of exploit attempts
To determine exploitability, the risks of each vulnerability are used to prioritize, comparing them against each other; then, based on risk and priority, to address the vulnerabilities and other development tasks (such as new features).
This is also the phase in which you can manage external vulnerability reports.
Secure Software Development Lifecycle (SSDL) was introduced by Elfriede Dustin in 2006.
Recent Comments