Software development follows what is called a Software Development Lifecycle, or S D L C. It is a process used for developing software. There are several different models which all include the phases of Planning, Defining, Designing, Building, Testing, and Deployment & Maintenance.
The different SDLC models have different time periods for each of the phases and different things they focus on. Some of the more popular SDLC models including Waterfall, Agile, Iterative, Spiral, and V. These models are efficient in satisfying individual requirements of software development organizations, however, none of these models have been built with the consideration of security.
Prior to the inception of the secure SDLC, all security-related activities were performed only as part of the Testing phase. This approach resulted in a high number of undetected vulnerabilities, improper handling of private customer data, an increased number of data breaches caused by cyber-security attacks, and a more expensive Software Development Lifecycle.
In order to avoid the cost and risk associated with the SDLC, organizations started to implement security as a continuous concern in their SDLC model. The Secure SDLC is the process of adding application security into all phases of the SDLC to minimize the risk of vulnerabilities in code. This is the focus of building an effective application security program.
There are multiple secure SDLC frameworks that can be followed such as Building Security in Maturity Model (BSIMM), OWASP’s Software Assurance Maturity Model (SAMM), Microsoft Security Development Lifecycle (SDL), ISO/IEC 27034, among others. All of the frameworks have many similarities and in these lessons we are going to focus on best practices from all of them with a little more emphasis on OWASP’s Software Assurance Maturity Model (SAMM).
The SAMM model is technology and SDLC process agnostic and includes Governance, Design, Implementation, Verification, and Operations.
For each of these phases, there are multiple security practices. There is no one security practice that is a silver bullet. Instead, it is the combination of these practices within the SDLC that will reduce the risk of vulnerabilities in software and mitigate the effects when the inevitable vulnerabilities do exist.
Let’s briefly look at the phases of the Secure SDLC:
Governance is focused on building an overall plan, setting the ground rules, standards and regulations, as well as activities related to how an organization should manage its software development process. This phase includes guidelines for employee education and training on cybersecurity, aiming to increase their security awareness around application security. The Governance phase should be conducted as soon as possible. Getting everyone on the same page with expectations and gaining buy-in in an application security program is important and probably the hardest part. In addition, training developers on secure coding has a high return on investment. In Governance, you will develop policies, gain buy-in, and train.
The Design phase involves the identification of potential attacks, defining appropriate security requirements to protect the services and data at the core of the application. This phase helps organizations gain a better understanding of the risk and facilitates risk management while also promoting the inclusion of security-related requirements during the software development process. For software that has already been developed post-production analysis can be done to identify and mitigate the risks although it is more complex. In Design, you will add security functions to your applications.
Implementation promotes the importance of building software in a standardized, repeatable manner and offers guidelines on how to ensure the security and integrity of your applications are not compromised during their deployment. Additionally, it is important to specify how security bugs should be collected, recorded, and analyzed in order to increase security. In Implementation you will create secure build and deployment scripts as well as implement bug tracking software.
Verification is focused on how security testing of the application should be performed. This includes traditional penetration testing and vulnerability assessment audits, automated and manual source code review, and quality assurance tests. Selecting the right Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools are key. In Verification, you will ensure security testing is conducted on applications to find and fix vulnerabilities.
The operations phase specifies how an organization should respond to security incidents, as well as different practices that should be considered to reduce the chances of security incidents proactively. Moreover, it promotes activities required to maintain security throughout the product life cycle. In Operations you will develop an incident response plan, ensure you are logging and backing up applications and data, and put in place additional protections such as monitoring and Web Application Firewalls.