In this article, we will provide a breakdown of the NIST guidance for defending against software supply chain attacks.
A software supply chain attack occurs when a cyber threat actor infiltrates a software vendor’s network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer’s data or system. Newly acquired software may be compromised from the outset, or a compromise may occur through other means like a patch or hotfix. In these cases, the compromise still occurs prior to the patch or hotfix entering the customer’s network. These types of attacks affect all users of the compromised software and can have widespread consequences for government, critical infrastructure, and private sector software customers.
ICT Supply Chain Lifecycle
The official document provides an overview of software supply chain risks and recommendations on how software customers and vendors can use the National Institute of Standards and Technology (NIST) Cyber Supply Chain Risk Management (C-SCRM) framework and the Secure Software Development Framework (SSDF) to identify, assess, and mitigate risks.
Software supply chains fit within the greater information and communications technology (ICT) supply chain framework. The ICT supply chain is the network of retailers, distributors, and suppliers that participate in the sale, delivery, and production of hardware, software, and managed services. The ICT Supply Chain Lifecycle has six phases. At each phase of the ICT Supply Chain Lifecycle, software is at risk of malicious or inadvertent introduction of vulnerabilities.
Threat actors employ different techniques to execute software supply chain attacks. Three common techniques are:
- Hijacking updates
- Undermining code signing
- Compromising open-source code
These techniques are not mutually exclusive, and threat actors often leverage them simultaneously.
Most modern software receives routine updates to address bugs and security issues. Software vendors typically distribute updates from centralized servers to customers as a routine part of product maintenance. Threat actors can hijack an update by infiltrating the vendor’s network and either inserting malware into the outgoing update or altering the update to grant the threat actor control over the software’s normal functionality. For example, the NotPetya attack occurred in 2017 when Russian hackers targeting Ukraine spread malware through tax accounting software popular in Ukraine. What would later be called the NotPetya malware spread well beyond Ukraine and caused major global disruptions in crucial industries, including international shipping, financial services, and healthcare?
Codesigning is used to validate the identity of the code’s author and the integrity of the code. Attackers undermine codesigning by self-signing certificates, breaking signing systems, or exploiting misconfigured account access controls. By undermining codesigning, threat actors are able to successfully hijack software updates by impersonating a trusted vendor and inserting malicious code into an update. For example, APT 41, a China-based threat actor, routinely undermines codesigning while conducting sophisticated software supply chain compromises against the United States and other countries.
Compromising Open-Source Code
Open-source code compromises occur when threat actors insert malicious code into publicly accessible code libraries, which unsuspecting developers—looking for free blocks of code to perform specific functions—then add into their own third-party code. For example, in 2018, researchers discovered 12 malicious Python libraries uploaded on the official Python Package Index (PyPI). The attacker used typosquatting tactics by creating libraries titled “diango,” “djago,” “dajngo,” etc., to lure developers seeking the popular “django” Python library.
The malicious libraries contained the same code and functionality of those they impersonated; but they also contained additional functionality, including the ability to obtain boot persistence and open a reverse shell on remote workstations.9 Open-source code compromises can also affect privately owned software because developers of proprietary code routinely leverage blocks of open-source code in their products.
Software Supply Chain Attack Threat Profile
Software supply chain attacks typically require strong technical aptitude and long-term commitment, so they are often difficult to execute. These attacks differ from trusted relationship attacks in which threat actors infiltrate a less secure third-party organization to exploit and access an existing trusted connection that the third party has with the target organization.11 Some criminal threat actors succeed in trusted relationship attacks and some of the less complex types of software supply chain attacks, such as modifying open-source code or app store attacks. In general, advanced persistent threat (APT) actors are more likely to have both the intent and capability to conduct the types of highly technical and prolonged software supply chain attack campaigns that may harm national security.
Uniquely Vulnerable to Software Supply Chain Attacks
Organizations are uniquely vulnerable to software supply chain attacks for two major reasons: first, many third-party software products require privileged access; and second, many third-party software products require frequent communication between a vendor’s network and the vendor’s software product located on customer networks.
Many common, third-party software products require elevated system privileges to operate effectively; this includes products like antivirus, IT management, and remote access software. Even when a product can effectively operate on a network with reduced privileges, products will oftentimes default to asking for greater privileges during installation to ensure the product’s maximum effectiveness across different types of customer networks. Customers often accept third-party software defaults without investigating further, allowing additional accessibility vectors. Additionally, because these types of products are typically present on every system within a network, including authoritative and domain management servers, vulnerabilities or malware inserted into those software products could provide malicious actors with privileged access to the most critical systems within a network.
Consequences of Software Supply Chain Attacks
The consequences of a software supply chain attack can be severe. First, threat actors use the compromised software vendor to gain privileged and persistent access to a victim network. By compromising a software vendor, they bypass perimeter security measures like border routers, firewalls, etc., and gain initial access. If a threat actor loses network access, they may re-enter a network using the compromised software vendor.
While gaining initial persistent access can be relatively indiscriminate, threat actors will often be more selective in choosing which victims they target for follow-on actions. Follow-on actions are highly variable but often start when the threat actor injects additional tailored malware packages into a chosen target. Depending on the threat actor’s intent and capability, this additional malware may allow the threat actor to conduct various malicious activities that may include performing data or financial theft, monitoring organizations or individuals, disabling networks or systems, or even causing physical harm or death.
Recommendations for Customers
Organizations acquiring software should consider its use, as with other ICT products and services, in the context of a risk management program. Such a program should use an operationalized systems security engineering framework12 and a formal C-SCRM approach across organization, mission/business, and system tiers. A mature risk management program enables an organization to understand risks presented by ICT products and services, including software, in the context of the mission or business processes they support. Organizations can manage such risks through a variety of
technical and non-technical activities, including those focused on C-SCRM for software and the associated full software lifecycle.
NIST suggests eight key practices for establishing a C-SCRM approach that can be applied to software.
- Integrate C-SCRM across the organization.
- Establish a formal C-SCRM program.
- Know and manage critical components and suppliers.
- Understand the organization’s supply chain.
- Closely collaborate with key suppliers.
- Include key suppliers in resilience and improvement
- Assess and monitor throughout the supplier relationship.
- Plan for the full lifecycle.
These practices can assist in preventing, mitigating, and responding to software vulnerabilities that may be introduced through the cyber supply chain and exploited by malicious actors.
Book your free Demo
For more information on how your organization can implement these standards in place please feel free to contact us at Riscosity, +1-888-RISCOSI, or book a free demo with us.