NIST Recommendations for Defending Against Software Supply Chain Attacks

As a security leader, you feel confident in your organization’s security stance. Your team worked hard to build a culture prioritizing security. Risk management is viewed as serious business, and your organization proudly displays SOC2, ISO 27001, and PCI-DSS while strictly adhering to privacy laws like GDPR. But what about the third parties in your supply chain? 

Specifically, are the software vendors you’re using prioritizing security? Are they doing everything possible to keep their networks and products secure? Unfortunately, too many software vendors today just aren’t providing adequate levels of security in their networks or products–and the results are proving disastrous for organizations using the software and their customers. 

Just how disastrous can a software supply chain attack be? The software can provide the pathway for invaders to circumvent cyber defenses for network access, maintain stealthy persistence, steal data, and spy on unknowing victims. The Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) released the “Defending Against Software Supply Chain Attacks” guidelines on April 26, 2021, which showed that supply chain attacks could have “widespread consequences for government, critical infrastructure, and private sector software customers.”

Software supply chain attacks are undoubtedly a grave security concern for all businesses today–just ask the many organizations impacted by the recent SolarWinds debacle, which we will discuss later. In this article, you will learn about these attacks, the primary software supply chain risks organizations face, and NIST’s recommendations for defending against these potentially devastating events.

What is a software supply chain attack?

According to the “Defending Against Software Supply Chain Attacks” guide, a software supply chain attack occurs when a threat actor infiltrates a vendor network and employs malicious code to compromise the software product before the vendor sends it to their customers. The affected software and data then compromise the customer’s system and data, creating malicious options for the threat actors. Security measures of both the vendor and their customers can be circumvented, allowing unauthorized privileged and persistent access to the target’s networks. 

With this access, threat actors can add malware to facilitate the theft of financial data, spying, or even the disabling of entire systems for ransom. All software users and their networks can be impacted with far-reaching consequences, some even as serious as threatening national security.

Organizations are vulnerable to software supply chain attacks for two main reasons:

1. Privileged access: Many software products require a degree of privileged access to perform at optimum efficiency. Customers accept default levels of access, which can allow a jailbreak of unauthorized invasions. Many software products maintain a presence across the enterprise, so unauthorized access glitches can impact the most critical systems within your organization.
   
2. Frequent communication: It’s helpful to receive software updates, but these exchanges between vendor and customer open the door for hackers to exploit this trusted line of communication. Posing as a vendor, attackers send fake updates loaded with malware or block real security updates from reaching the customer, so the customer remains vulnerable to existing threats.

Keep in mind that software supply chain attacks require higher-level tech skills coupled with a lot of patience, so they can prove challenging for many attackers. Many threat actors prefer simpler third-party assaults like “trusted relationship attacks,” where they infiltrate a less-secure third-party vendor, then exploit their trusted connections with the target organization. 

Overview of software supply chain risks

Supply chains are inherently laden with risk, and as a firm chooses to outsource more processes to software vendors the amount of risk increases exponentially. Each phase of the software development lifecycle–design, production, distribution, acquisition/deployment, maintenance, and disposal–includes its own risks. For instance:

• Foreign parts can arrive containing malware, or malware can be injected during design and production by a compromised build server.
• New software can be infected after leaving the factory during distribution. 
• Many threat actors favor the maintenance phase, when they bombard customers with routine-looking updates loaded with backdoor malware. 

The more software vendors your supply chain includes the more risks you face – from inferior vendor security practices to vulnerability-laden software, or, in a worst-case scenario, malware hiding in wait to compromise your systems and network.

Charles Denyer, the Senior Partner in National Security and Cybersecurity and renowned author and speaker, feels the biggest software supply chain risks today originate in the development stage of the supply chain lifecycle. “The biggest issue I see in the software supply chain is really in the development of the code. Using inadequate developers and writing poor code leads to gaps and openings that hackers can exploit. If the software is developed correctly, with security in mind, you wouldn’t see the issues that SolarWinds had.”

The SolarWinds case provides an excellent example of compromises in both the development and maintenance phases of the supply chain lifecycle. In this 2020 case, an IT management’s build server was infiltrated by a foreign attacker who persisted unnoticed for months before inserting malware into product updates to compromise customer networks. When hijacking updates or devices, threat actors can insert malware (like SolarWinds) or alter the original update to capture system control.

Threat actors employ other tactics designed to gain unauthorized system access or create vulnerabilities in software. One of these, known as undermining code-signing, provides unauthorized system access through self-signing certifications, breaking signing systems, and exploiting misconfigured account access controls. Hackers also compromise open-source code by installing malware with tactics like typosquatting, which mimics popular library titles. In 2018, 12 compromised Python libraries were uploaded to Python Package Index and used this sly wording trick to fool developers.

History proves every phase of the software development lifecycle harbors risk and the opportunity for exploitation. A case from 2016 illustrates this in the design phase when an American cell phone producer installed foreign software on their phones. The compromised software recorded text and call info, forwarding it back to a foreign server every few days. In 2012, a computer manufacturer discovered end-user device malware installed during distribution, long after the product had left the factory. Even after product disposal, sensitive data spillage from uncleaned, discarded devices is a serious software supply chain security risk today.

How to prevent software supply chain attacks

Given the sparsity of rapid mitigation options in the event of a software supply chain attack (because the victim organization doesn’t have the authority to command a timely response from their software vendor), it’s far more beneficial to invest in preventive measures. Here are some top tips from experts on vendor software security:

1. Use a risk management lens when purchasing software 

Employing a risk management lens is critical when considering a new software purchase. The “Defending Against Software Supply Chain Attacks” guide states, “organizations acquiring software should consider its use in the context of a risk management program. A mature risk program enables an organization to understand risks presented by information communications technology (ICT) products and services, including software, in the context of the mission or business processes they support.”

2. Ask prospective vendors for compliance verifications

During this step, your team must verify the existence and proper functioning of all required security processes and controls used by the vendor to protect their equipment, data, and systems. Start by requesting a SOC 2 Type 2 report and ISO 27001 certification from your vendor. Make sure to read all reports or certificates for each product you intend to purchase. How do the vendor’s verification documents correlate to those specific products?

Ask your vendor to walk you through each step in their supply chain, demonstrating how their controls meet regulatory standards and maintain the required level of security throughout your product’s supply chain journey.

To access sample questions you can ask vendors to assess their security posture, check out the article below. 

3. Ask vendors about their software development life cycle (SDLC) practices

How your software vendors develop their product plays a huge role in limiting vulnerabilities and minimizing risk for your organization. Don’t hesitate to question vendors on every angle of their SDLC, verifying the presence of adequate controls and an unwavering commitment to security. Charles Denyer weighs in on this process: “Be sure to ask your vendors how they develop and test their code. How do they move their code from development to staging to production? How important is product security in the development process? What type of training do their developers receive?”

The SDLC questions you ask a vendor upfront can go a long way toward preventing your organization’s unnecessary exposure to risk later on.

4. Use formal risk management and secure software development frameworks 

We recommend using a formal Cyber-Supply Chain Risk Management (C-SCRM) approach teamed with a Secure Software Development Framework (SSDF) to more effectively identify, assess, and mitigate risks. Vendors should consider blending these frameworks into their SDLC process. NIST created a white paper introducing practices organizations can adopt to successfully integrate an SSDF into their software development life cycle.

The white paper further explains how these practices divide into four groups which include preparing the organization (ensuring the people, processes, and technology are ready to perform at the organizational level), protecting the software (protecting all software components from tampering or unauthorized access), produce well-secured software (produce software with minimal vulnerabilities in releases), and respond to vulnerabilities ( identify vulnerabilities in releases and take appropriate action). 

The four groups are organized by practice, tasks, implementation examples, and references. Examples of these practices include defining software security requirements for developers, storing all code in restricted access repositories, training developers with a risk-based model approach, and establishing a response program to identify and address vulnerabilities.

If your organization is ready to embrace a C-SCRM approach to help prevent and mitigate software vulnerabilities and lower overall risk, the eight key practices NIST recommends are:

1. Integrate C-SCRM across your organization
2. Establish a formal C-SCRM program
3. Know and manage critical components and suppliers
4. Understand the organization’s supply chain
5. Closely collaborate with key suppliers
6. Include key suppliers in resilience and improvement activities
7. Assess and monitor the supplier relationship
8. Plan for the full lifecycle

By employing these eight critical practices, your team can take a monumental step forward to prevent most software supply chain security issues. You can’t control the security practices of your software supply chain vendors or prevent all software vulnerabilities–but you can use these practices to help select and monitor the most responsible and secure vendors who produce the safest software to become members of your supply chain family.

How Hyperproof helps you assess supplier risks

Keeping track of all of your software vendors as part of a responsible risk management program can be a daunting task today. You need to develop insightful security questionnaires for vetting vendors, keep track of results, and possibly devise remediation plans. You must receive thorough and accurate security risk questionnaire responses from your vendors to make sound risk management decisions. All of these tasks can take a significant amount of time to complete, and many security and risk professionals don’t have enough time in the day for all this work. 

Hyperproof has your needs covered with its vendor risk management solution. In this module, you can track all vendors including their contact info, and the risks they pose, and assign each vendor a risk criticality rating. You can vet vendors in less time than before, by sending out pre-built or custom questionnaires to assess their risk level, tracking questionnaire responses centrally, and coordinating with others to complete any necessary remediation tasks without switching tools. 

Putting a rigorous third-party risk management program in place is a necessity for modern organizations. Hyperproof’s vendor risk management module can help you assess your software vendors more efficiently and lower your chances of experiencing a software supply chain attack later on.

To learn more about Hyperproof, sign up for a demo.