CISA, FBI, ODNI release recommended practice guide for software customers across supply chain

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) joined the National Security Agency and the Office of the Director of National Intelligence (ODNI) to guide security requirements involved in planning, designing software architecture from a security perspective, adding security features, and maintaining the security of software and the underlying infrastructure. The recommended practice guide comes as a final segment of a three-part series developed by the Enduring Security Framework (ESF), which provides best practices for software customers for procuring and deploying secure software, including guidance for the Software Bill of Materials (SBOM). 

Titled “Securing the Software Supply Chain for Customers,” the document covers unmitigated vulnerabilities in the software supply chain that pose a significant risk to organizations. The series presents actionable recommendations for a software supply chain’s development, production and distribution, and management processes to increase the resiliency of these processes against compromise. All organizations have a responsibility to establish software supply chain security practices to mitigate risks, but the organization’s role in the software supply chain lifecycle determines the shape and scope of this responsibility. 

As the considerations for securing the software supply chain vary based on the role an organization plays in the software supply chain, the series presents recommendations geared toward these important roles, namely, developers, suppliers, and customers (or the organization acquiring a software product). Additionally, the series helps foster communication between these three different roles and among cybersecurity professionals that may facilitate increased resiliency and security in the software supply chain process. The first part of the series covered software developers, while the second part focused on software suppliers. 

Developed through the ESF – a public-private cross-sector working group led by NSA and CISA, the recommended practice guide for software customers provides cybersecurity guidance to address high-priority threats to the nation’s critical infrastructure. To guide customers, ESF examined the events that led up to the SolarWinds attack. The examination made clear that investment was needed to create a set of the industry- and government-evaluated best practices focused on the needs of software customers.

The NSA identified that historically, threat hackers targeted commonly known vulnerabilities that were left unpatched. While this tactic is still used to compromise unpatched customer systems, a new, less conspicuous method threatens software supply chains and undermines trust in systems patching themselves, something that has been critical to guarding against legacy attacks. 

“Rather than waiting for public vulnerability disclosures, threat actors proactively inject malicious code into products that are then legitimately distributed downstream through the global software supply chain,” the NSA said. “Over the last few years, these next-gen software supply chain compromises have significantly increased for both open source and commercial software products.”

Prevention is often seen as the responsibility of the software developer, as they are required to securely develop and deliver code, verify third-party components, and harden the build environment. Infiltration of the supplier’s network with malicious code before the final software product being delivered can also cause the supply chain to be compromised. If a software package injected with malicious code proliferates to multiple consumers, it is much more difficult to confine; it may cause an exponentially greater impact compared to when a single customer is the target of a cyberattack.

This leads to the customer also holding a critical responsibility in ensuring the security and integrity of software; not only do they acquire the software, but they are also responsible for deploying it. “To avoid network exploitation, they should assess threats by conducting supply chain risk management (SCRM) activities and define risk profiles during the security requirements process. Developers and suppliers should also provide customers with guidance on how to verify the integrity of the software components,” the NSA added.

Security is not just for the developers and suppliers, it’s for customers too. Until all stakeholders seek to mitigate concerns specific to their area of responsibility, the software supply chain cycle will be vulnerable and at risk for potential compromise.

In the latest recommended practice guide targeted at software customers, stakeholders must seek to mitigate security concerns specific to their area of responsibility. However, other concerns may require a mitigation approach that dictates a dependency on another stakeholder or a shared responsibility by multiple stakeholders. Dependencies that are inadequately communicated or addressed may lead to vulnerabilities and the potential for compromise.

The document also identifies areas where these types of vulnerabilities may exist. These include undocumented features or high-risk functionality, unknown and/or revisions to contractual, functionality, or security assumptions between evaluation and deployment. It also covers the supplier’s change of ownership and/or geolocation, and poor supplier enterprise or development hygiene.

The recommended practice guide for software customers also covers key processes in the product acquisition, deployment, operations, and maintenance phases of the software lifecycle, beginning with requirements definition and ending with software SCRM operations. The customer must augment these processes based on the organization’s structure, mission, and risk tolerance, as the organization implements specific mitigation activities. 

It also identifies possible scenarios that could be exploited. These include security requirements intended to counter threats that are not domain specific or exclude organizational requirements and gaps in the analysis of security requirements which may lead to a mismatch of the solution or selected security controls. Other security requirement gaps include out-of-date security requirements or assessments and misrepresented or underrepresented risk profiles that are disconnected from acquisitions or mission areas. Insufficient security requirements may also be a problem when stakeholders are missing from signoff or approval, or when solution inventory is incomplete.

Furthermore, the recommended practice guide identifies that general security inadequacies may also prevail when a product isn’t properly protected, when a  customer is associated with suspicious geolocation and metadata, or when a customer is suspected to be associated with foreign interests.

To help organizations counter potential vulnerabilities in the software product evaluation phase, the practice guide proposes verifying the contents of the SBOM against the product under evaluation. The verification should include attributes such as geolocation, supplier ownership or control, Data Universal Numbering System (DUNS) verification, and past performances. It also recommends subjecting third-party suppliers identified in the SBOM to this same evaluation to help mitigate associated risks. 

The recommended practice guide for software customers also suggests forging mitigations and outcome strategies as part of the SCRM determination by correlating prior notifications of vulnerabilities in supplier products with incidents presently under evaluation. It also continuously vets external evaluation labs and verifies their independence, while also requiring that evaluators have proper expertise in the type of software under evaluation and require an assigned function to verify that domain-specific and organizational security requirements are in place. These assigned functions should also verify the functional, environmental, and operational requirements.

Anna Ribeiro

Industrial Cyber News Editor. Anna Ribeiro is a freelance journalist with over 14 years of experience in the areas of security, data storage, virtualization and IoT.