NIST and secure software development

Security is not merely a one-time issue but an ongoing one. For example, a house may be secure at the time of its construction, but if, over the years, it is not diligently cared for and improvements are not implemented to protect it, it may cease to be so. This everyday example can be transferred to cybersecurity and software protection. That’s why NIST has developed the Secure Software Development Framework (SSDF), a guide to help companies implement secure practices throughout the software lifecycle.

The U.S. National Institute of Standards and Technology (NIST) has become a true benchmark in cybersecurity. Its guidelines and frameworks are used by companies and cybersecurity professionals worldwide. In such a way, many of its methodologies are considered standards worldwide. The same happens with the knowledge generated by OWASP or CIS.

The digitalization of the economy and society has generated enormous advantages and opportunities, both for companies and citizens. However, it has also meant an increase in cyber exposure. The more digitized a company or public administration is, the more exposed it is to cyber-attacks.

In addition, the tactics and techniques of malicious actors are becoming increasingly sophisticated and potentially more dangerous.

Both of these issues have led to an increase in supply chain attacks. In other words, malicious actions that seek to attack a company or its customers by exploiting the software of one of its suppliers.

This article will analyze the NIST Secure Software Development Framework and its usefulness in software securitization.

Why use the Secure Software Development Framework?

In February 2022, NIST published version 1.1. of its Secure Software Development Framework, stating that it was born out of a perceived gap. The institute believes that only some software development lifecycle models delve deeply enough into the issue of security.

Many developers focus, unsurprisingly, on the quality of the software they design and produce, its usability, or its technical complexity. However, security should have a central position when developing software.

This scenario opens the door to cyberattacks and allows the spread of supply chain attacks that seek to harm software producers and, above all, the companies that use them. This has been demonstrated in famous supply chain attacks against software companies such as Solarwinds Orion, Kaseya or Ledger.

With this dangerous scenario, NIST proposes, with its Secure Software Development Framework, to implement a series of best practices throughout all phases of the software lifecycle.

This Secure Software Development Framework aims to:

1. Reduce the number of vulnerabilities in the software present in the market.
2. Mitigate the impact that the exploitation of uncured vulnerabilities could have.
3. Analyze the root causes of vulnerabilities to prevent future weaknesses.
4. Facilitate communication between software suppliers and consumers and help companies establish control systems for third-party software.

2. Best practices to achieve results

To achieve the objectives outlined above, the Secure Software Development Framework proposes four recommendations that, in turn, articulate the set of best practices that make up this framework:

• Companies must ensure that their professionals, processes and tools are prepared to carry out secure software development throughout the lifecycle of the solutions they produce.
• Organizations must protect all the components used in their software, paying special attention to their manipulation and unauthorized access.
• Companies have to produce secure software in the early stages of the lifecycle and in all versions of their solutions, reducing vulnerabilities to a minimum.
• Companies must be able to identify residual vulnerabilities in software releases and have effective mechanisms in place to address them.

The structure of the Secure Software Development Framework is very simple and intuitive. Each recommendation is translated into a set of practices. The guide defines each practice and establishes the tasks that must be carried out to implement it.

Furthermore, to facilitate its use by any company, the Secure Software Development Framework includes practical examples of implementing the practices and tasks. Finally, it incorporates the references used in its design that can be useful when implementing the Secure Software Development Framework, including reference materials such as OWASP standards or CIS guides.

All this makes the Secure Software Development Framework an open methodology, which is not focused on establishing how best practices should be implemented but on achieving results.

2.1. Preparing the organization

All actions we undertake in our lives require preparation. It is commonly said that no one is born learned, to which we could add that no one is born prepared.

Preparing a company to ensure that the software it develops is secure requires the implementation of five practices:

1. Define the security requirements for software development. To do this, it is necessary to gather internal sources, such as the security risk management strategy, and external sources, such as the regulations in force that must be complied with. It is also necessary to communicate these requirements to software component suppliers to use in the company’s software.
2. Establish roles and responsibilities. It is important that both internal and external professionals are clear about their roles, receive adequate training and assume their responsibilities throughout the software life cycle.
3. Implement support toolchains. Automation plays an essential role in protecting software throughout its lifecycle, helping professionals detect vulnerabilities, optimize practices and document them.
4. Define and use criteria to verify software security during all phases of development.
5. Implementing and maintaining secure environments for software development. It is essential to ensure that all environmental components are protected against external and internal attacks.

2.2. Protect software

In addition to implementing secure work and organizational practices, it is crucial to protect the software code and to have protocols and methodologies in place to verify the security of each software version:

1. Protect the code from unauthorized access and prevent tampering. Unauthorized changes to the code can override implemented security features or introduce new vulnerabilities. In addition, unauthorized access can make it easier for criminals to find vulnerabilities and even lead to the theft of the software or source code and intellectual property infringement.
2. Establish a mechanism to verify the integrity of each software version. Not only is it important for the organization to internally verify the security of each version it releases, but buyers must also have the necessary mechanisms to ensure that the software they purchase is legitimate and has not been tampered with.
3. Collect and archive each software release to detect and remediate vulnerabilities. Documenting and retaining each released version facilitates the ability to analyze, mitigate and eliminate vulnerabilities discovered after the release.

2.3. Produce well-protected software

This group contains the largest number of practices to be implemented:

1. Design software to meet security requirements and mitigate risks. Considering requirements and risks from the software requirements and design phase is key to improving development.
2. Review the design to verify that requirements are met, and risks are duly reported.
3. Reuse previous, well-protected software, where feasible, rather than reimplement functionality. This reduces costs and development time and the possibility of introducing new vulnerabilities to the software.
4. Employ secure coding practices when creating software source code.
5. Configure the compilation, interpretation and build processes to improve the security of executables. Again, this practice allows for the reduction of costs and vulnerabilities.
6. Perform an audit of source code (SAST), scripts and other human-readable code to look for vulnerabilities and ensure compliance with security requirements before the software is released.
7. Test the executable code before it is released into production to detect vulnerabilities and check compliance with security requirements before the software is released and vulnerabilities can be identified and exploited. In this sense, the execution of DAST (Dynamic application security testing) plays a fundamental role.
8. Configure the software parameters securely. The objective is that, at the time of installation, the software is not deployed with weak security configurations, susceptible to successful attacks. In this sense, infrastructure security audits or pentesting services can be executed before production deployment.

2.4. Identifying and responding to vulnerabilities

The last of the groups of practices that make up the Secure Software Development Framework focuses on the vulnerabilities that solutions may have and how to address them:

1. Search for and detect vulnerabilities on an ongoing basis to identify them as early as possible and be able to remediate them more quickly, depending on the risk they pose to the organization.
2. Assess, prioritize and remediate vulnerabilities.
3. Analyze vulnerabilities and identify their causes to reduce the occurrence of further vulnerabilities in the future.

3. Who is the Secure Software Development Framework aimed at?

A priori, the target audience of the Secure Software Development Framework is solution producers. However, the scope of this methodology transcends this typology of actors.

The NIST guide outlining its Secure Software Development Framework defines three targets for which this framework can be extremely useful: software developers and purchasers.

3.1. Managers within companies that produce software

The first target of the Secure Software Development Framework is the owners and managers of software development companies, project managers and professionals in charge of corporate cybersecurity.

The Secure Software Development Framework operates like a dictionary or an encyclopedia for these first-level profiles. It provides them with a common language to exchange information and communicate, aiming to secure software throughout its lifecycle.

This is largely because the NIST Secure Software Development Framework is a document of little technical complexity but has been designed to be understood and used by software developers and other professional profiles such as those mentioned above.

Implementing the good practices articulated in this tool is not only the responsibility of the developers but also of other actors, especially those with decision-making capacity within the company.

3.2. Software developers

Professionals who develop software must consider the best practices compiled by NIST and carry out the tasks proposed to protect the software throughout its life cycle. The institute includes in this category commercial-off-the-shelf software developers, product vendors, government software developers, custom software developers, and companies’ in-house development teams…

The Secure Software Development Framework is broad enough to be useful to any company, regardless of its size, economic sector or level of maturity concerning cybersecurity. And to be used in all types of software development: web applications, mobile, SaaS, ICS, IoT… Regardless of the technologies, platforms, languages or programming environments developers use.

All this is possible because the framework does not establish the methodologies and techniques to carry out each practice but focuses, as mentioned above, on the results. Thus, it is left to the companies to select the procedures that best fit their resources and needs to achieve the goals proposed by the Secure Software Development Framework.

It should also be noted that the Secure Software Development Framework is not only intended to be implemented by producers when they launch a new development project. Rather, its practices can help a company move from a classic software development model to a more modern, agile and secure one.

3.3. Software buyers

Both companies and public administrations that purchase software should feel challenged by the NIST Secure Software Development Framework, even if they are not in charge of the software development. Why?

1. Even if they do not produce the software, they use it. This means that, through a supply chain attack, a company can be the victim of a cyberattack based on a vulnerability in the software that the company has contracted. Therefore, any fully optimized security strategy must take supply chain attacks into account and establish measures to continuously analyze the security of the software used by the company.
2. Companies and administrations can use the best practices that make up the Secure Software Development Framework to evaluate software suppliers before acquiring them. As well as in software management during the various phases of its life cycle.

This methodology helps all organizations understand and internalize the practices that contribute to securing the software they work with daily. As well as the risks associated with not paying attention to the security of vendor solutions.

By operating as a standard, the NIST Secure Software Development Framework becomes a manual that companies can consult to ensure that their suppliers are implementing good software development practices.

4. Combating supply chain attacks is everyone’s business

The NIST Secure Software Development Framework demonstrates, both in its practices and tasks and in the definition of its target audience, that securing software is a daunting task that involves multiple stakeholders.

While software development companies play a central role in protecting themselves against cyberattacks, the increase in supply chain attacks shows that companies that procure software must also implement best practices for secure software development.

The European Union Agency for Cybersecurity (ENISA) has analyzed the main supply chain attacks in recent years, such as those that have affected companies like Mimecast, SITA or Accellion. As a result of this work, ENISA has concluded that:

• 62% of the attacks took advantage of the trust in the supplier on the part of the client company.
• 66% of the attacks focused on the software suppliers’ code to attack the client companies.
• 58% of the supply chain attacks were aimed at accessing sensitive data: personal information of the companies’ customers and intellectual property…

What lessons can we learn from these findings?

• Companies must blindly trust their suppliers and ensure that they employ good security practices, for which the NIST Secure Software Development Framework is very useful, as we have already pointed out.
• Continuously testing software code is crucial to detect vulnerabilities before criminals exploit them.
• Data protection is a general central issue in the cybersecurity industry, and for secure software development in particular.

4.1. Reducing exposure to supply chain attacks

In light of the above, many companies should consider engaging services to reduce exposure to supply chain attacks. Such services should be performed at multiple levels, both in the software development phases, during and after the software has been deployed in production. Some of these services are:

• SAST (Static Application Security Testing) /SCA (Software composition analysis) services.
• Identification of vulnerabilities in the software or possible dependencies that have been integrated as part of the final solution.
• DAST (Dynamic Application Security Testing) analysis. Automated or manual dynamic testing ensures no vulnerabilities are published in production environments or final software solutions.
• Execution of security audits to identify possible vulnerabilities, facilitating the execution of the secure software development framework.

4.2. A continuous work that expands in time

As demonstrated in several supply chain attacks such as Solorigate, vulnerabilities can arise in one of the periodic software updates. What does this demonstrate? The need for software producers and the companies that consume them to consider cybersecurity best practices on an ongoing basis, not just in the early stages of the software lifecycle.

The practices included in the Secure Software Development Framework are not intended to be performed only once, but some must be performed continuously (e.g., analyzing source code). In contrast, others must be re-evaluated periodically (e.g., defining security requirements). Why?

Because technologies change rapidly, attackers devise new methodologies and tactics to carry out their fraudulent actions. In addition, cybersecurity regulations are also expanding rapidly, as evidenced by the DORA regulation or the NIS2 directive.

Moreover, this new EU regulatory framework pays special attention to companies’ IT suppliers since supply chain attacks have shown practically the consequences that this kind of security incident can have on the companies that purchase software and on their customers.

In short, the NIST Secure Software Development Framework is an open methodology designed to be used by software developers, business managers, and companies that procure software.

This framework facilitates communication between all players in the supply chain and the implementation of cybersecurity best practices throughout the software lifecycle.