Overview
Threats and vulnerabilities in the software and application landscape continue to grow. With each passing day, new vulnerabilities in software and applications are discovered and exploited. Many organizations invest in the requisite machines to fulfil the functional requirements of their software but do not focus on the security of the software. Software development life cycle (SDLC) refers to a methodology that ensures the production of high-quality software by following a set of processes.
Incorporating security in this life cycle is vital as it helps developers identify vulnerabilities and bugs during the design phase and helps reduce the cost of fixing bugs after the software has been deployed and made publicly available.
NIST has developed a framework for the secure development of software known as the Secure Software Development Framework (SSDF). This framework is incorporated into the SDLC to make it more secure. Implementing this framework in the SDLC will help developers and software engineers weed out vulnerabilities in their software, mitigating potential threats to the software, and identify the root cause of these vulnerabilities to prevent future occurrences.
State of Software Security
Before we discuss the NIST’s SSDF, let’s have a look at the current state of software security. The need for implementing security in SDLC will be best understood once we have some insight into the threat landscape and the current state of the software and application ecosystem.
According to a Veracode Report, the following chart shows some common flaws found in applications. The common weakness enumeration (CWE) framework categorizes different flaws into a hierarchy. The OWASP Top 10 and SANS 25 also categorize different types of flaws based on their severities. Security personnel and developers use these frameworks to identify the most important security flaws and plan mitigation methods and countermeasures based on the severity of these flaws.
Source: Veracode
The SSDF
Vulnerabilities that get created because security has not been incorporated in the SDLC create serious troubles for the organizations and customers. Adversaries are always on the lookout to exploit any vulnerabilities they find in softwares or applications. It is very important to consider security even as the application is being designed. According to a report by the Systems Science Institute at IBM, the estimated cost to fix a bug found during implementation can be six times more than the cost of one identified during the design of the software or application.
To cater to issues related to software security, NIST has developed the SSDF. The framework introduces a set of high-level practices that need to be incorporated into every SDLC to ensure secure software development.
As the NIST white paper related to SSDF provides a comprehensive list of practices, we are going to mention a few of them below.
One thing that needs to be kept in mind is that although most of the practices defined in the SSDF can be applied to any software development environment, it’s not necessary that it is applicable in all cases.
The NIST white paper categorizes the practices into the following groups:
1. Prepare the Organization Ensuring that the organization’s people, processes and technology are prepared to execute secure software development at the project or at the organizational level.
2. Protect the Software The software should be protected from any changes and breaches in confidentiality.
3. Produce Well-Secured Software The software developed and released should have the least number of vulnerabilities
4. Respond to Vulnerabilities
Ensure that vulnerabilities are identified properly and proper steps are taken thereafter to weed out these vulnerabilities and ensure that they do not appear in the future.
SSDF Practices
Some of the NIST SSDF practices are discussed below. The categorization is in such a way that practices against each group are given. Against each practice, there is a task, an implementation example and a reference.
1. Prepare the Organization
Defining security requirements for software development
The security requirements for secure software development should be known at all times to ensure that they are available during the SDLC implementation cycle.
Task
Identify all the security requirements of the organization’s software development processes, update and maintain the requirements throughout the process.
Implementation examples
- Define policies that will ensure fulfilment of the organization’s security requirements for the software. Secure coding practices are to be included for developers to follow whilst developing the software.
- After a vulnerability in the software is reported, review and update the security requirement.
- A periodic review must be conducted for all security requirements.
References:
- BSIMM10: CP1.1, CP1.3, SR1.1
- BSA: SC.1-1, SC.2, PD.1-1, PD.1-2,PD.1-3, PD.2-2
- ISO 27034: 7.3.2
- MSSDL: Practice 2
- NIST CSF: ID.GV-3
- OWASP TEST: Phase 2.1
- PCI LRAP: 2.1
- SAMM15: PC1-A, PC1-B, PC2-A, SR1-A, SR1-B, SR2-B
2. Protect Software
Protection of all types of code from intentional changes and unauthorized access
Ensure that there are no intentional or unintentional changes to the code that go against the security requirements. Code that is not accessible to the public must be protected in a way that adversaries find it hard to steal or compromise.
Task
The principle of least privilege would be implemented while storing codes such as source code and executable code so that only intended or authorized personnel have access to it.
Implementation examples
- All source codes will be stored in a code repository and access should be restricted according to the sensitivity of the code.
- Use hashes for integrity checks on files.
- Version control checks will be implemented on repositories to track changes to the code and ensure accountability of each developer account.
- All changes to the code should be reviewed and approved.
References:
- BSA: IA.1, IA.2-2, SM.4-1
- IDASOAR: Fact Sheet 25
- NIST CSF: PR.AC-4
- OWASPASVS: 1.10, 10.3.2, 14.2
- PCISSLRAP: 6.1
- SCSIC: Vendor Software Delivery, Integrity Controls, Vendor Software Development Integrity Controls
3. Produce Well-Secured Software
Design software to meet security requirements and mitigate security risks
Software design security requirements should be identified and evaluated. Evaluate risk associated with the software during the production phase and take appropriate steps to reduce them. The software development process will be more efficient if security risks and requirements are addressed in the software design phase.
Task
The security risk of the software will be assessed by using different types of risk modeling techniques such as threat modeling, attack surface mapping etc.
Implementation examples
- Collaborate with teams that are responsible for threat modeling to create threat and attack models and use a risk-based approach to identify and mitigate vulnerabilities.
- Sensitive data will be passed through rigorous assessments such as access control, authentication, credential management etc.
- Vulnerability reports will be reviewed for all past software.
References
- BSA: SC.1-3, SC.1-4
- BSIMM10: AM1.3, AM1.5, AM2.1,AM2.2, AM2.5, AM2.6, AM2.7
- IDASOAR: Fact Sheet 1
- ISO27034: 7.3.3
- MSSDL: Practice 4
- NIST CSF: ID.RA-*
- OWASPASVS: 1.1.2, 1.2, 1.4, 1.6, 1.8,1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13
- OWASPTEST: Phase 2.4
- PCISSLRAP: 3.2
- SAMM15: DR1-A, TA1-A, TA1-B, TA3-B
- SCAGILE: Tasks Requiring the Help of Security Experts 3
- SCFPSSD: Threat Modeling
- SCTTM: Entire guide
4. Respond to Vulnerabilities
Identify and confirm vulnerabilities on an ongoing basis
Ensure that vulnerabilities in the software are identified quickly so that they can be mitigated in a timely fashion, thus reducing the window of opportunity for potential attackers.
Task
Potential vulnerabilities in software and third-party components that are being used should be investigated properly by collecting information from public sources and consumers.
Implementation examples
- Use vulnerability programs to efficiently report vulnerabilities within a software.
- Use threat intelligence sources to understand how vulnerabilities are being exploited in general.
References
- BSA: SC.1-3, SC.1-4
- BSIMM10: AM1.3, AM1.5, AM2.1,AM2.2, AM2.5, AM2.6, AM2.7
- IDASOAR: Fact Sheet 1
- ISO27034: 7.3.3
- MSSDL: Practice 4
- NISTCSF: ID.RA-*
- OWASPASVS: 1.1.2, 1.2, 1.4, 1.6, 1.8,1.9, 1.11, 2, 3, 4, 6, 8, 9, 11, 12, 13
- OWASPTEST: Phase 2.4
- PCISSLRAP: 3.2
- SAMM15: DR1-A, TA1-A, TA1-B, TA3-B
- SCAGILE: Tasks Requiring the Help of Security Experts 3
- SCFPSSD: Threat Modeling
- SCTTM: Entire guide
Conclusion
Incorporating SSDF into your SDLC will ensure that vulnerabilities are identified before the application is implemented and made available for use. Thus, the threat landscape will decrease, adversaries will find it harder to exploit vulnerabilities and the software will be less prone to attacks or compromise.
