Key Highlights from the New NIST SSDF

The Software Development Lifecycle (SDLC) is a methodology for designing, creating, and maintaining software. There are different variations of the SDLC including waterfall, spiral, and agile. Regardless of which of these variations an organization uses it’s important for an organization to have secure software development practices.

There are three primary reasons for this according to the National Institute of Standards and Technology (NIST):

1) To reduce the number of vulnerabilities in your released software

2) To reduce the impact of exploited vulnerabilities

3) To address the root cause of these vulnerabilities occurring in your applications.

In the security field, it’s always ideal to create applications that are secure by design rather than trying to fix those issues later on. To help companies in this area NIST created what’s called the Secure Software Development Framework (SSDF), which describes a set of high-level practices based on established standards, guidance, and secure software development practice documents.

In this article, we’ll be going over the 1.1 revision of The Secure Software Development Framework that was published on February 3rd, 2022. The SSDF is divided into four groups by NIST and we will be discussing each of these groups in the order they are given:

• Prepare the Organization
• Protect the Software
• Produce Well-Secured Software
• Respond to Vulnerabilities.

Section 1: Prepare the Organization

This section is about ensuring that people, processes, and technology are prepared to perform secure software development at the organizational level.

The first goal here is to ensure that the security requirements for software development are known by everyone involved in the SDLC, so they can be taken into account as the software is being developed. To do this you need to identify and document all security requirements for the software. These requirements should be maintained and updated as the software is developed and new features are added. It’s also important that requirements are communicated to all third parties that will provide commercial software components to the organization for reuse in the software. This way third-party vendors can be required to meet the appropriate level of security standards. If you are using open-source software/code then you need to do your own due diligence to ensure that it meets your security requirements.

Next, you must implement roles and responsibilities for the different people involved in the SDLC. This ensures that everyone inside and outside the organization involved in the SDLC will know exactly what is expected of them. To do this effectively you need to create new roles and alter existing roles to ensure that all parts of the SDLC are covered. These need to be reviewed and maintained regularly. You should also provide role-based training for everyone involved in the process to ensure that they can fulfill their role competently. It’s also necessary to obtain upper management's commitment to secure development and convey that to your team. This will make people take the initiative more seriously and make it more of a focus for the development team.

Third, you want to implement supporting tools for secure development. This allows you to use automation to reduce human effort, minimize errors and increase the reproducibility of your security practices throughout the SDLC. It’s always better to automate security processes than to require a human to perform that action. The first step is to identify what tools you want to include in order to mitigate your identified risks and how these tools will be integrated with each other. Be sure to follow recommended security practices when deploying, operating, and maintaining tools and toolchains in the SDLC. Then configure them to perform optimally in the support of the practices that you defined as an organization.

Fourth, you need to define and use criteria for software security checks throughout the SDLC. Simply put, you need to have a way to measure that the software you create is secure. To do this you need metrics and key performance indicators (KPIs) that you can track throughout the process. Once you understand what your criteria are, you need to implement the processes, mechanisms and controls required to measure the successful implementation of security in your application.

Lastly, you need to ensure that all of the components in your environment that are going to be used in software development are protected from internal and external threats. Do not forget that the environment itself where the software is being developed needs to be protected. There are two main elements to consider:

• You need to separate and protect each component involved in the software development process.
• You need to secure and harden all the development endpoints that will be used during the software development process to ensure they cannot be tampered with.

Failing to do so could lead to a major failure known as a supply chain attack, as demonstrated by the mind-blowing attack of SolarWinds in 2021, where hackers were able to compromise the environment and inject malicious code into the company software.

Section 2: Protect the Software

This means protecting all aspects of your software from unauthorized access and tampering. The biggest source of vulnerabilities for any piece of software will be insecure coding practices found in the source code. You need to be very protective of your codebase to ensure that all changes to the code are well tracked, documented, and align with secure coding practices.

Secure coding practices include monitoring for leaked secrets. As you're working on software with multiple developers and teams, there’s a high probability that company secrets will find their way into codebases. To prevent this, it’s important to have solutions that can monitor your repos, and ensure that your company information isn’t leaked at any point in the development lifecycle. 

This also means making sure that the code, which is your intellectual property, is not leaked to people that may steal it and use it to launch their own business ventures. Code should only be shared on a need-to-know basis.

Secondly, you should have a means of verifying software integrity. In the first section, we discussed the importance of having controls to protect the software. This section explains that you also need to have a means of confirming that the software has not been tampered with upon release. A common way to do this is through the use of cryptographic hashes, by creating hashes before and after release or just periodically you can be sure that the code has not been altered in any way.

Lastly, you need to have the capability to archive and protect each software release that you have. This way you can identify, analyze and eliminate any vulnerabilities in software after its release. It’s important that you continue to examine your software after release for bugs and security vulnerabilities, it’s unlikely that you will be able to detect all vulnerabilities during the initial creation of the application.

Section 3: Produce Well-Secured Software

This section focuses on what needs to be done during the design and development phase of the SDLC to produce secure software. The first thing that needs to be done is to design your application specifically to meet your security requirements and mitigate security risks. Addressing the security issues during the design phase is very important for improving software security and makes the entire process much more efficient.

Secondly, once you have a design in mind for the software it should be reviewed to ensure it meets your security requirements. This should be done by your in-house security experts to ensure that it will meet your standards.

Third, you should make plans to reuse working and secure code rather than trying to write that code from scratch. By reusing quality code you reduce the risk of introducing new security issues, decrease production time and ensure good functionality.

Fourth, you should make sure to configure your compilation, interpreter, and build processes to ensure good executable security. Some cyberattacks such as a buffer overflow take advantage of vulnerabilities during runtime to exploit applications. You can eliminate some of these vulnerabilities by having the proper configurations for executable security. For example, you should enable features that warn you about insecure coding practices, and features that randomize or obfuscate execution characteristics such as memory location, to make sure that all the developers’ tools are properly configured for maximum security.

Fifth, you need to review human-readable code to find vulnerabilities. One good way to do this is to perform a manual code review, which is where someone manually reads the code to find vulnerabilities.

Sixth, you need to test your executable code to find vulnerabilities. This can be done using software tools such as dynamic application testing and static application testing tools. Using software tools you can scan your code and test it at runtime to find vulnerabilities without the need for human intervention.

Lastly, you need to configure your software to have secure settings by default. When deciding what the default settings of your application are you need to ensure that the software will be in a secure configuration after installation. While it may be necessary to include some features that aren’t secure to allow for certain use cases, this should not be the default setting of the application.

Section 4: Respond to the Vulnerabilities

The last section of the SSDF is about responding to vulnerabilities that you find in your applications. First, NIST recommends that you identify and confirm vulnerabilities in your application on an ongoing basis. After release, as more users start to use your application you will begin to see many errors and bugs that may not have been found during testing. It’s important that you continuously look for vulnerabilities that may be affecting your application.

Second, you need to have a means for assessing, prioritizing, and remediating the vulnerabilities in your software. If you have several vulnerabilities in your software you need to have a means for prioritizing the most severe vulnerabilities so that they can be addressed first. Next, you need to have a process for how vulnerabilities are fixed, tested in a non-production environment, and finally pushed to production. It’s very important that you test the corrected version of the application before pushing it out to the production environment.

Third, look for the root cause of the vulnerability. Fixing a vulnerability may not necessarily fix the root cause of the issue. It’s important to identify the root cause for each vulnerability to ensure that there won’t be similar issues in the future or current vulnerabilities affecting the application that you aren’t aware of.

Key Highlights from the New NIST SSDF

• Newly Recommended Practices: NIST Introduced the practice of “Implementing and Maintaining Secure Environments for Software Development.” This expands the focus from just being on the application itself and now includes the environment in which the application is being developed as well as the tools that are being used.
• Newly Recommended Tasks:

1. Documenting security requirements that your created software must meet.
2. Added recommendations for collecting and sharing data for all components of software releases.
3. Advocates for the tracking of software security requirements, risks, and design decisions.

• Added Practical Examples: Each suggested practice and sub-tasks have multiple practical examples of how these can be implemented in your organization. This can be leveraged by organizations to develop practical, actionable steps to improve security in your organization.

Conclusion

Securing the SDLC is an integral part of creating secure software applications. Designing applications that are secure by design is far superior to creating applications and trying to secure them afterward. As highlighted by this 1.1 revision by the NIST, security starts with securing the environment the application will be developed in (the build environment).

You also need to ensure that the application is coded according to the best practices and doesn’t have any inherent security vulnerabilities (you can have a look at our secure coding practices here).

Lastly, you need to continuously look at your application to find new vulnerabilities after the launch, and remediate them when they are detected. If you would like to stay informed as NIST releases new executive orders related to cybersecurity, sign up for our newsletter. We will be writing articles explaining all of them as they are released.