There are different Software Development Life Cycle models such as build and fix models, waterfall model, V-model, Prototyping, incremental model, spiral model, Rapid application development model, and agile model. All these models deal with the following phases: 1) Requirements gathering, 2) Design, 3) Development, 4) Testing/Validation, and 5) Implementation/release/maintenance. Some of the SSDLCs that have been proposed include MS Security Development Lifecycle (MS SDL), NIST 800-64, OWASP CLASP (Comprehensive, Lightweight Application Security Process), and Cigital’s Security Touchpoints.
The traditional SDLC model has security testing in the testing phase, which usually results in too many issues detected too late. So the SSDLC proposes that security be considered at all phases. The SSDLC start with a project plan and a security plan to ensure that all the phases are executed properly. A core security training can precede all other activities. The requirement gathering phase is utilized to gather security requirements with respect to confidentiality, integrity, and availability along with the project requirements. This should be followed by security risk assessment as well as privacy risk assessment with respect to the vulnerabilities and threats, the probabilities of exploitation and the consequences. This is followed by privacy risk assessment and private risk rating is assigned. The security risk acceptance levels are defined. The design phase is used to accomplish attack surface analysis and threat modeling. The attack surface analysis identifies the amount of code that and functionality that can be made accessible to untrusted users. Threat modeling allows an understanding of various threats that can affect the code and how the resulting program can be compromised .
During the coding phase, only approved tools and approved options for the tools are used, all interfaces and APIs are analysis and unsafe interfaces are not used. Static code analysis is used to ensure correct coding practices are followed. In the testing/validation phase a separation of environment (production, development, and testing) is ensured. Dynamic analysis is used by running the code with the help of tools to find issues. Fuzzers are used to induce failure to detect flaws and failures. This is followed by an attack surface review that ensures that any changes to the design and implementation changes do not introduce new attack surfaces. For the release phase, and incident response plan is created and security service plans are created to handle the problems due to code inherited from other groups. A final security review is conducted and then the code is archived after it is released. During the maintenance phase, the incident response plan is executed .
It is suggested that a Software Capability Maturity Model Integration (CMMI) be used as a framework for developing software. The goal of CMMI is to establish an effective software development infrastructure and engineering principles in an organization so that they can achieve continuous improvement through sustained effort and focus. It addresses all the phases of the software development process such as the requirements gathering and analysis, concept definition, design, development, installation, and maintenance. Security engineering practices can be evaluated and improved upon. This helps a software development vendor to develop from an organization that has ad hoc processes to an organization that has continuous process improvements so that the software process quality improves, the lifecycle of development is reduced, and allows to exhibit more proactive approach. It provides the organization best practices and a standardized approach to develop software at the organization level.
There are five levels of CMM, each with a level of maturity of the processes. The “Initial” level has ad hoc processes, so there are no defined processes or very few defined processes and success depends on individual effort. There is no assurance of quality as the results are unpredictable. All organizations are at this level initially. The “Repeatable” level has the basic project management processes, change control, quality assurance processes defined and established. Schedule, cost, and functionality can be tracked and the processes for similar applications can be repeated for each project. There are no formal defined process models. The next level is “Defined” where the management and engineering processes for software projects are defined and integrated in to the software development lifecycle and related processes. This will be at the organization level. Individual projects use this process directly or a tailored version of it, based on the individual project’s requirements for developing and maintaining the software. The organization has established the ground work for quantitative process improvement. The fourth level is “Managed” level. The software process and product are quantitatively measured and controlled. The measures for understanding and controlling the software process and product are defined, collected, analyzed to achieve this. This is fed into the process-improvement program. The fifth level is “Optimizing”, which enables continuous process improvement by quantitative feedback from the process where the collection of metrics for understanding and controlling the process are institutionalized. These measures are used to improve the process and the metrics collected again. This is repeated again and again so that there is a continuous improvement.
An organization should constitute a patch and vulnerability group (PVG), which is the central point for vulnerability remediation. Its duties include OS and application patching, configuration changes, inventory the organizations hardware, operating systems, and software applications, monitor different sources for vulnerability announcements, patch and non-patch remediation, threat vectors, prioritize the remediation efforts, conduct testing, and train administrators on how to apply the patches or remediation. They should also look at the appropriate automated patch management tools that can expedite the process and deploy them in a phased manner. They should assess and mitigate the risks of using those automated patch management tools and standardize the configurations for the organization wide patch management tools. The effectiveness of these tools is continuously measured and corrective actions are applied when needed.
Software Configuration Management (SCM) automates the change control process. A product that is used for SCM provides a methodical control of changes of the software products so that traceability and integrity of the software product is maintained. The project plan should specify the configuration management plan and the SCM should be used to enforce it. The SCM ensures accountability. It is recommended that central code repositories are maintained so that SCM can track and enforce version control as well as manage concurrency, versioning, and synchronization. Advanced algorithms are used to merge changes in a file when multiple users check in and check out software products. Enabling versioning also helps rollback to any of the previous versions. An archive copy of any file that is checked into the SCM system can be made and a log can be created as to what the changes were, who made the changes, and when they were made. Some SCMs allow check out of partial or complete copies of repositories by individuals to work on the files. They can later be committed to the master repository. They can also update their personal copies of the repositories that they have checked out. This is done through the process of synchronization.
References
Cigital. (2016, january 21). SSDLC 101: What Is the Secure Software Development Life Cycle? Retrieved from cigital.com: https://www.cigital.com/blog/what-is-the-secure-software-development-lifecycle/
Eric Conrad, S. M. (2010). CISSP Study Guide. (K. Riggins, Ed.) Burlington, MA: Syngress.
Harris, S. (2013). All-in-one CISSP Exam Guide (6th ed.). New York, NY: McGraw-Hill Companies.
Microsoft. (2016, February 14). What is the Security Development Lifecycle. Retrieved from microsoft.com: https://www.microsoft.com/en-us/sdl/default.aspx
Peter Mell, T. B. (2013). Creating a patch and vulnerability management program: Recommendations of the NIST (Special Publication 800-40 v2.0) . Gaithersburg, MD: NIST.
