Software Supply Chain Risk Management: Enabling Resilience in National Critical Infrastructure

Growing concerns related to dependencies on software-reliant information communications technology (ICT) and Internet of Things (IoT) devices are pushing changes in governance associated with supply chain risk management (SCRM). The possibility of disruption of critical infrastructure exists because the software that enables these capabilities is vulnerable and exploitable.

Exploit potential is often more about the vulnerability of assets in target organizations than the ingenuity of the attackers. Several breach reports show that the source vectors of attack are in software. Consequently, organizations expanding the use of network-connectable devices need comprehensive software security initiatives to address weaknesses resulting from technological vulnerabilities and a lack of “cyber hygiene” (lack of caution) among those who develop and use software applications and software-reliant IoT devices.

Exploitable weaknesses, known vulnerabilities, and even malware can be embedded in software without malicious intent. Indeed, sloppy manufacturing hygiene is more often the cause of exploitable software. Such poor hygiene can be attributed to the lack of due care exercised by supply organizations with developers, integrators and testers who are often unaware of or untrained on software security, compounded by inadequate testing tools and the failure of suppliers to prioritize addressing the risks associated with the poor security of the software they deliver to the organizations that use it.

How do organizations proactively protect critical infrastructure from being the victim of software provided by others? As a start, they use contracts to set supply chain expectations for their suppliers. Sample software procurement language is available for free to assist organizations in developing their contracts and establishing test criteria as part of software SCRM due diligence. Procurement criteria should contain these specifications, at a minimum:

  • Software composition analysis of all compiled code found in the supplier product to identify all third-party open source components via a software bill of materials and to identify all known vulnerabilities listed in Common Vulnerabilities and Exposures (CVE) in publicly available databases, such as the NIST-hosted National Vulnerability Database (NVD);
  • Static source code analysis of all available source code found in the supplier product to identify weaknesses listed in Common Weakness Enumeration (CWE);
  • Malware analysis of supplier-provided software to determine whether any known malware exists in that software, along with a risk assessment of mitigation controls;
  • Validation of security measures described in the product’s design documentation to ensure they are properly implemented and have been used to mitigate the risks associated with use of the component or device.

To facilitate achievement of these requirements, internationally recognized information-sharing standards associated with software security automation are freely available. For example, ITU-T’s Cybersecurity Information Exchange (CYBEX) X.1500 series provides a set of standardized means for identifying, reporting and exchanging cybersecurity information. The ITU-T X.1500 CYBEX ensemble of techniques is a collection of best-of-breed standards from government agencies and industry, and it is an essential enabler to slow the contagion of cyberattacks that target exploitable software. Key for SCRM, ITU-T offers standards for vulnerability/state exchange and event/incident/heuristics exchange. These include standards for exploitable weaknesses (CWEs, ITU-T X.1524), known vulnerabilities (CVEs, ITU-T X.1520) and malware (MAEC, ITU-T X.1546).

These are the same software security enumerations that have been co-sponsored by the U.S. Department of Homeland Security and used in special publications of the U.S. National Institute for Standards and Technology, and they are the same that are used in the tools that organizations should use to check software in fulfilling contract terms and conditions. CVE and CWE are the baseline measures used in the OWASP Top 10, and CWE is the basis of the CWE/SANS TOP 25 Most Dangerous Software Errors.

At a minimum, enterprises with products on “whitelisted” approved product lists or “assessed and cleared” product lists, should test those products for exploitable weaknesses, known vulnerabilities and malware before those products are listed for enterprise use.

  • If suppliers do not mitigate exploitable weaknesses (CWEs) or flaws in products (which are difficult for users to mitigate), then those weaknesses represent vectors of future of exploitation and zero-day vulnerabilities that put the enterprises that use the products at risk.
  • If suppliers do not mitigate known vulnerabilities (CVEs) prior to delivery and use, then users cannot have any level of confidence that patching and reconfiguring will be sufficient or timely to mitigate exploitation.
  • If suppliers do not check that the software they deliver does not have malware (typically signature-based), then users are at risk of using software with malware pre-installed.

For SCRM due diligence to be sufficient, it requires third-party testing of software and software-controlled products, either by an independent lab or as part of acceptance testing by acquiring enterprises. Many tools and services find weaknesses and vulnerabilities in source code and binaries and also report a software bill of materials enumerating the open source components in both source and binary code files. At a minimum, there should be a requirement for suppliers to provide a bill of materials with test reports that provide evidence of mitigations associated with CWEs, CVEs and malware. Organizations not doing this as part of SCRM due diligence are very much at risk of compromise and exploitation.

Obviously, there is more software SCRM than testing products from third-party suppliers. Software “decays” over time due to new vulnerabilities being reported as a result of new malware exploiting weaknesses in software that were present when the software was procured or put into use. Software SCRM with independent testing better enables an enterprise to address the full scope of the five security controls specified by the Center for Internet Security (CIS) that directly relate to software lifecycle management. Without independently testing software and having a bill of materials for software assets, enterprises will be less likely to fulfill these five security controls.

Because enterprises have learned they cannot trust third-party suppliers to mitigate risks attributable to exploitable software, they have started to implement SCRM due diligence that includes testing requirements that address mitigations for CWEs, CVEs and malware. Without it, those enterprises should not be surprised if they are in the headlines for breach reports.

1 comment on “Software Supply Chain Risk Management: Enabling Resilience in National Critical Infrastructure

  1. briannajones
    November 4, 2018


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.