In a previous post, we received a question asking, "what is a secure software development lifecycle"? This is an excellent question, and one that I receive quite often from organizations during an application security assessment.
Let's quickly review the Software Development Lifecycle, also known as the SDLC. The goal of an SDLC is to provide a process for project teams to follow when developing software. A series of steps are completed, each one with a different deliverable, eventually leading to the deployment of functioning software to the client.
Several different SDLC models exist, including Waterfall, Spiral, Agile, and many more. While each of these models is very different, they were all designed without software security in mind. Failing to include software security in the development lifecycle has many consequences:
- Releasing critical vulnerabilities to production
- Putting customer data at risk
- Costly follow-up releases to secure the application
- Development teams believing security is someone else's job
- And the list goes on?
Requirements:
The requirements phase traditionally allows time for meeting with the customer, understanding the expectations for the product, and documenting the software requirements. In a Secure SDLC, the requirements phase is where we start building security into the application. Start by selecting a security expert to make security-related decisions for the project team. Send the entire project team through application security awareness training. Ensure the software requirements include security requirements for the development team. Identify any privacy or compliance laws that may impact the product.
Design:
The design phase traditionally allows time to choose the platform and programming language to meet the product requirements. The software is broken up into modules, system interfaces are documented, and the overall system architecture is created. In a Secure SDLC, more security-specific steps must be complete. Attack surface analysis and threat modeling will be done to identify potential vulnerabilities, the high-risk interfaces, and any countermeasures. Specify how system authentication will be performed and where secure communication is required.
Construction:
The construction phase is where we actually start building the product. Development teams build components and libraries based on the design and requirements documents. In a Secure SDLC, provide secure coding guidelines to the development team. Ensure that development team uses the security libraries available in the framework for security-specific tasks (e.g. encoding, validation, data access, authentication, authorization, etc.). As each component is completed, scan the source code with a code analyzer that searches for vulnerabilities, also known as a static analysis tool. The scans present immediate feedback to developers, allowing them to correct vulnerabilities as code is written.
Verification:
The verification phase is where quality assurance and customers test the product to ensure it meets the requirements. The tests plans typically cover unit testing, integration testing, stress testing, and user acceptance testing. In a Secure SDLC, perform testing to identify vulnerabilities in the live running application. Dynamic analysis, also known as penetration testing, submits malicious parameters to the application in an attempt to compromise the system. Again, providing the feedback to the development team so identified issues can be corrected before product delivery.
Maintenance:
Once verification is complete, the product is delivered to the customer. The maintenance phase is where product support and monitoring takes place. Future enhancements are sent back to the requirements phase, and the process repeats itself. In a Secure SDLC, continuously monitor the application for security-specific events and provide feedback directly to the development team. This allows them to detect and react quickly to an attack, taking further action if necessary.
Conclusion:
While this post describes a very high level Secure SDLC, the intent is to show you how integrating security into each phase helps the project team understand the importance of security. This understanding helps keep team members engaged during security discussions because they recognize the threats facing their applications. As the software is built, security issues are identified early in process, ultimately delivering more secure products to the customer.
We encourage you to continue exploring the Secure SDLC and visit a number of more in-depth resources on this topic.
The STH.Developer awareness program (http://www.securingthehuman.org/developer) contains over 30 minutes of Secure SDLC awareness training content.
Jim Bird, an expert on Secure Software Development, has written a few in-depth posts on the SANS Software Security blog covering Secure Agile and DevOps proceses.
http://software-security.sans.org/blog/2012/07/09/what-appsec-can-learn-from-devops
http://software-security.sans.org/blog/2012/02/22/agile-development-teams-can-build-secure-software
Eric Johnson (Twitter: @emjohn20) is a Senior Security Consultant at Cypress Data Defense, Application Security Curriculum Product Manager at SANS, and a certified SANS instructor. He is the lead author and instructor for DEV544 Secure Coding in .NET, as well as an instructor for DEV541 Secure Coding in Java/JEE. Eric serves on the advisory board for the SANS Securing the Human Developer awareness training program and is a contributing author for the developer security awareness modules. Eric previously spent 10 years working on web and mobile application penetration testing, secure code review, risk assessment, static source code analysis, security research, and developing security tools in the financial industry. He completed a bachelor of science in computer engineering and a master of science in information assurance at Iowa State University, and currently holds the CISSP, GWAPT, GSSP-.NET, and GSSP-Java certifications.
