| Listen on Google Podcasts | Listen on Mave | Listen on Yandex Music |
Ruslan Rakhmetov, Security Vision
News about the discovery of dangerous vulnerabilities in popular applications and operating systems is published almost daily on dedicated resources, with the most notorious vulnerabilities even receiving their own names - this was the case, for example, with HeartBleed (CVE-2014-0160), EternalBlue (CVE-2017-0144), Log4Shell (CVE-2021-44228). The discovery of such vulnerabilities, configuration errors or protocol implementations becomes a significant event, because after a researcher or vendor publishes technical information, attackers start developing exploits in the hope of attacking unpatched systems (we talked about the importance of vulnerability management process in one of the previous articles).
This post will review NIST SP 800-218, ‘Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities,’ which provides recommendations for using the Secure Software Development Framework, a set of high-level secure software development practices. Following it will help reduce the number of vulnerabilities in code, reduce the potential damage from their exploitation, and eliminate the root causes of vulnerabilities.
NIST SP 800-218 introduces the term Secure Software Development Framework (SSDF), which is a secure software development framework that is a set of basic expedient practices for software development. Implementing the SSDF framework will enable an organisation to meet the following recommendations for secure software development:
- Preparing people, processes, and technology to implement secure development cycles;
- Protecting all software components from unauthorised access and malicious interference;
- Developing secure software products with a minimum number of vulnerabilities;
- Identifying residual vulnerabilities in developed software, responding correctly to fix them and preventing similar vulnerabilities from occurring in the future.
The paper defines SDLC (software development life cycle) as a formal or informal methodology for designing, creating, maintaining software, including firmware (‘firmware’) for hardware devices. Despite the large number of software development methodologies (cascading model, spiral model, agile, DevOps, and others), applying the SSDF framework and secure development practices to any of them will help reduce the number of vulnerabilities in releases, reduce potential damage from exploitation of remaining vulnerabilities, and identify and address the root cause of emerging vulnerabilities to prevent them from occurring in the future. NIST SP 800-218 emphasises the importance of a fundamental rule of secure software development: the strategy of ‘Shifting Left’, i.e. literally ‘shifting left’, means incorporating code security issues as early as possible in the product development lifecycle. Addressing security issues at the earliest stage of product design and specification writing, with further control at the stages of development, release, deployment, upgrades, and support, will help reduce future costs of vulnerability remediation and the consequences of exploitation. NIST SP 800-218 emphasises that the framework's recommendations are flexible and high-level, allowing them to be applied regardless of the specific development, economic sector, IT/OT/IoT infrastructure, development methodology, technology stack or programming language used. In case of using the service model (SaaS, PaaS, CaaS, etc.), it will be reasonable to apply the principle of responsibility sharing between providers, developers, tenants.
The SSDF framework itself consists of four groups of secure development practices with specifics for each recommendation. So, NIST SP 800-218 suggests that the SSDF framework be implemented with the following in mind:
1. Preparing the organisation:
1.1 Establish security requirements for software development, including internal requirements (policies, business objectives, risk management strategy) and external requirements (applicable legal and contractual regulations):
1.1.1 Identify, document and periodically update security requirements for software development infrastructure and processes;
1.1.2 Identify, document and periodically update requirements for software developed by the company;
1.1.3 Communicate security requirements to all third parties supplying software components to the organisation for reuse in software development.
1.2 Allocation of roles and responsibilities:
1.2.1 Create new roles and assign responsibilities, with periodic review of the relevance of assignments;
1.2.2 Provide training for employees responsible for safe development, with periodic certification. 1.2.3;
1.2.3 Obtaining the support of the company's management and communicating the position of top management to all responsible and interested parties.
1.3 Implement safe development automation tools:
1.3.1 Identify specific tools (or their types) for automating secure development processes to mitigate identified risks in software development, taking into account the mutual integration of these tools;
1.3.2 Follow recommendations when implementing, using, maintaining secure development process automation tools. 1.3.3;
1.3.3 Configure secure development process automation tools to create digital artefacts of their application in software development.
1.4 Develop and apply criteria for assessing the safety of software development:
1.4.1 Define evaluation criteria and monitor them as part of the secure software development cycle;
1.4.2 Implement processes and mechanisms to collect and protect the necessary information to support the use of these criteria. 1.4.2 Implement processes and mechanisms to collect and protect the necessary information to support the use of these criteria.
1.5 Implement and maintain a secure software development environment:
1.5.1. Separate and secure all infrastructure segments used in software development (e.g., development, build, test, distribution, etc. segments);
1.5.2 Ensuring cybersecurity and securely configuring the endpoints of developers, architects, testers, etc.
2. Software security:
2.1 Protect all types of software code from unauthorised access and modification:
2.1.1 Handling all types of code (including source code, executables, configuration files) in accordance with the principle of least privilege, granting access only to authorised subjects and entities.
2.2 Providing a mechanism for verifying the integrity and authenticity of the software product:
2.2.1 Providing users with information to verify the authenticity of the software (e.g., by publishing hash sums, signing files with digital signatures).
2.3 Archiving and protecting all versions of the product in order to find and fix vulnerabilities discovered after release:
2.3.1 Securely archive files and related information for each product release;
2.3.2 Collect, protect, update and share with interested parties all software components of each software release, e.g. via the Software Bill Of Materials (SBOM) catalogue. 3.
3. Creating a secure software product:
3.1 Develop software to meet security requirements and mitigate risks:
3.1.1 Use cyber risk modelling options (e.g. threat modelling, cyber attack modelling, attack surface analysis) to assess the risks of using the software;
3.1.2 Track and maintain software security requirements, risks, architectural decisions made;
3.1.3 Where possible, use inbuilt security functions instead of creating proprietary functions and services (e.g., it is preferable to use inbuilt OS functions of logging, authentication, access control).
3.2 Review software architecture to verify compliance with security requirements and cyber risk analyses:
3.2.1 Engage a qualified person not involved in software architecture development and/or use secure development automation tools to review software architecture for security compliance and cyber risk analysis results.
3.3 Where possible, reuse well-secured and well-established software components rather than creating duplicate functionality from scratch:
3.3.1 Acquire/obtain and maintain well-protected and debugged software components (libraries, modules, frameworks) from commercial, open source and other sources;
3.3.2 Creation and support of well-protected software components by own efforts (in-house), guided by the principles of secure software development, in case third-party developers and vendors cannot offer a more suitable software solution;
3.3.3 Verify compliance of purchased/received software components with the company's security requirements, with double-checks during their lifecycle.
3.4 Create source code in accordance with secure code writing practices:
3.4.1 Follow all secure programming practices applicable to the appropriate programming language and development environment.
3.5 Customise compilation, interpretation and build processes to enhance the safety of executable modules:
3.5.1 Use a compiler, interpreter, and assembler equipped with features to enhance the security of executable modules;
3.5.2 Identify compiler, interpreter, and assembler options and features that enhance the security of executable modules, and then configure them and save the settings made.
3.6 Examine and/or analyse human-readable code to identify vulnerabilities and verify compliance with security requirements:
3.6.1 Select methods of code examination (manually by a qualified employee) or code analysis (using automation tools) according to the organisation's requirements;
3.6.2 Perform code examination and/or analysis for compliance with corporate standards of secure software development, documenting and analysing all identified issues and issuing recommendations.
3.7 Perform executable code testing to identify vulnerabilities and verify compliance with security requirements:
3.7.1 Identify the need to test executable code to find vulnerabilities not discovered in previous phases;
3.7.2 Determining the scope and boundaries of testing, creating tests, performing testing, documenting and analysing results, and issuing remediation recommendations;
3.8. Configuring the software to use the most secure default settings:
3.8.1 Create baseline minimum security requirements by identifying all settings that may affect security, developing default settings that will not compromise the security of the software, installation environment, services;
3.8.2 Implement default settings and document them for software administrators.
4. Vulnerability Response:
4.1 Identify and validate vulnerabilities on an ongoing basis:
4.1.1 Collect information from users, software purchasers, and public sources regarding the presence of possible vulnerabilities in the software or third-party software components in use, verifying all valid reports;
4.1.2 Examine, analyse and/or test the software code to identify or confirm the presence of previously unidentified vulnerabilities;
4.1.3 Adopt a policy regarding the publication of vulnerability findings and response to third party vulnerability reports, with roles, responsibilities and processes in place to implement the policy.
4.2 Assess, prioritise, remediate vulnerabilities:
4.2.1 Analyse each vulnerability to gather sufficient information about the risk of exploitation to plan for remediation of the vulnerability or to implement other cyber risk response measures;
4.2.2 Planning and implementing measures to respond to the vulnerabilities discovered.
4.3 Analysing vulnerabilities to identify the root cause of their occurrence:
4.3.1 Conducting analyses of discovered vulnerabilities to identify the root cause of their occurrence;
4.3.2 Conduct root cause analyses over time to identify patterns in the errors made (e.g., failure to meet certain secure development requirements);
4.3.3 Examining software products to find similar vulnerabilities and proactively remediate that class of vulnerabilities;
4.3.4 Reviewing secure software development processes and updating them to prevent or reduce the likelihood of root cause vulnerabilities recurring in updates and new software.
