One challenge for supply chain security practitioners is choosing which of the multitude of guidance documents and best practice frameworks to use when building a cyber supply chain risk management (C-SCRM) program. There is no touchstone in this arena; instead, we have shades and gradations of goodness and a plurality of approaches.
The U.S. Department of Commerce’s National Institute of Standards and Technology (NIST), SAFECode, The East-West Institute, Critical Infrastructure Coordinating Councils, and many others have published guidance on methods to address cyber supply chain risks. But to date, there is little evidence that C-SCRM practices are effective in stopping or reducing cyberattacks.
This lack of objective evidence of efficacy makes it difficult for a practitioner to choose which guidance or practices or framework to use in our own operations.
When faced with this problem several years ago, at the outset of developing a C-SCRM function for a large enterprise, I created a compilation of different practices from various publications. This article is based on the compilation and provides a short narrative about why certain practices are included.
The compilation is primarily derived from practices described in NIST Special Publication 800-161, Cyber Supply Chain Risk Management Practices for Systems and Organizations, the results of a NIST-GSA-University of Maryland study (Sandor Boyson, Technovation), SAFECode supply chain guidance, the Build Security In Maturity Model (BSIMM), and a variety of other articles, blog posts, and documents in the public domain.
Much like the publications it is derived from, the compilation is intended to be used as a catalog of practices that is tailored by the user based on the particular circumstances of the supply chain that is being managed and which phase of the procurement lifecycle the practices are being used in.
The starting point is to identify which of the various practices in the document are best suited to your supply chain. For example, if you’re purchasing hardware, chain of custody and traceability practices are probably more important than they would be for a software purchase, and for software, secure development life cycle practices are probably more important than traceability practices.
The next steps are to incorporate the selected practices into your supply chain management processes, from onboarding to performance to closeout.
The practices described here can be used in many ways. They can be formulated as a questionnaire, as presented in this article, to be used during market research and requirements definition to provide the user with a greater understanding of which practices are already in use in the supply chain being surveyed. Following market research, they can be formulated as a set of contractual requirements to be evaluated by the buyer during source selection. Those same source selection criteria can provide useful Key Performance Indicators during contract performance. The bottom line is, these practices can be used in multiple ways in a variety of circumstances, the point of the compilation is to provide some raw materials to help practitioners develop their own programs.
This C-SCRM questionnaire addresses the following areas of risk:
- Secure development life cycle
- Composition analysis
- Static analysis
- Dynamic analysis
- Malformed input (fuzz testing)
- Known malware analysis
- Validation of security measures
- Third-party penetration testing
- Software Bill of Materials
- Remote access
- Chain of custody
- OEM purchasing
Product assurance
Purchase software from manufacturers with a demonstrable, documented, mature SSDLC. This is one of the most important things to know about the software you purchase. A robust SSDLC is the foundation of quality software and enables confidence in security measures taken throughout the lifecycle.
- Does the manufacturer use a documented SDLC that incorporates software assurance and is measured for effectiveness and/or maturity? If so, the manufacturer should:
- Identify which SDLC model it uses (if applicable)
- Describe its software development methods, systems/security engineering methods, quality control processes, testing and evaluation, and validation techniques
- Outline the overall process of incorporating both system functionality and security into all the SDLC phases, from requirement to development to disposal
- Describe the activities to minimize the number of vulnerabilities and weaknesses, and incorporate appropriate update mechanisms used when new vulnerabilities emerge
- Does the manufacturer conduct an analysis of all compiled code to identify all third-party and open source components and all known vulnerabilities found in the Common Vulnerabilities and Exposures (CVE)?
- Will the manufacturer provide the results of the analysis to the buyer?
- Does the manufacturer conduct analysis of all available source code in the product to identify weaknesses listed in the Common Weakness Enumeration (CWE)?
- Will the manufacturer provide the results of the analysis to the buyer?
- Does the manufacturer conduct an analysis of how the product behaves during operation and whether such behavior introduces potential security vulnerabilities that could negatively impact confidentiality, integrity, and availability?
- Will the manufacturer provide the results of the analysis to the buyer?
- Does the manufacturer conduct communication protocol fuzz testing to determine the ability to properly handle malformed and invalid messages for all identified communication protocols in the supplier product, as well as data resource exhaustion tests (such as load testing and DoS testing)?
- Will the manufacturer provide the results of the testing to the buyer?
- Does the manufacturer conduct scans of software to determine if any known malware exists in the software and a risk assessment or mitigation controls or value of risk?
- Will the manufacturer provide the results of the analysis to the buyer?
- Does the manufacturer ensure that all security measures described in the product’s design documentation are properly implemented and mitigate the risks associated with the use of the component or device?
- Does the manufacturer conduct penetration testing performed by a third-party penetration tester? If yes, does the testing address the following:
- All ports and interfaces that the product has enabled and disabled for all configurations
- All services that are external to the product for all configurations of the product
- Operational, service, test, and nonfunctional services of the product
- Measures implemented to prevent denial of service attacks on all ports, interfaces and services
- That all ports, interfaces, and services are documented and that there exists no undocumented port, interface, or service
- All ports, interfaces, and services that require authentication meet the requirements of NIST SP 800-63 or other equivalent applicable standard
- Probing for vulnerabilities in the product and providing conceptual exploits to attack the vulnerability
- Software and hardware weaknesses that are identified in the product that are listed as critical or high in the National Vulnerability Database and/or otherwise negatively impact confidentiality, availability, and integrity of the manufacturer’s product
- Will the manufacturer provide the results of the penetration testing to the buyer?
- Will the manufacturer provide, for all deliveries of software, firmware, or any product that contains an executable component, a comprehensive and confidentially supplied list of each third-party, commercial, or open-source executable component used in the software, firmware, or product, including the component’s version number (SBOM)?
The SBOM shall provide a nested inventory for software, a list of ingredients that make up software components. The SBOM should comport with the guidance provided by the United States Department of Commerce’s National Telecommunications and Information Administration, in particular the Software Suppliers Playbook: SBOM Production and Provision, as well as any future SBOM guidance promulgated by the United States Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency, as it “advances the SBOM concept to focus on scaling and operationalization.”
- Will the manufacturer provide technical documentation about the capabilities of all products that have the capability to perform remote system maintenance, software upgrades, troubleshooting, and diagnostics?
- Do the manufacturer’s products with remote access capabilities have the following:
- Strong authentication mechanisms for access to products
- A mechanism to perform any remote software downloads that are
- Validated as an uncompromised supplier deliverable
- Validated as an unaltered supplier deliverable
- Validated that only that action is performed
- Validated that it does not provide access to any other systems except for the purpose of updating the software to a supplier deliverable
- Able to prevent the introduction of any unwanted activity unauthorized by the supplier
- Does the manufacturer use and maintain a secure chain of custody to support the provenance (traceability) of system components for each deliverable?
- Will the manufacturer provide artifacts and evidence of its chain of custody to the buyer?
- Are the manufacturer’s chain of custody practices (including identification and traceability methods) sufficient to support the provenance of system components in the event of a supply chain issue or adverse supply chain event?
- Does the manufacturer use trusted/controlled distribution, delivery, and warehousing options to reduce supply chain risk (e.g., requiring tamper-evident packaging of information system components during shipping and warehousing)? If yes, describe.
- Does the manufacturer uniquely identify delivery mechanisms and communications/delivery paths as well as the components and tools used, establish a chain of custody for assessment of supply chain activities?
- Does the manufacturer:
- Have risk-based processes (taking into consideration the consequences of failure of an electronic part) that enable tracking of electronic parts from the original manufacturer to product acceptance by the buyer, whether the electronic part is supplied as a discrete electronic part or is contained in an assembly?
- If the manufacturer cannot establish this traceability from the original manufacturer for a specific electronic part, willthe manufacturer assume responsibility for inspection, testing, and authentication, in accordance with existing applicable industry standards?
- Maintain documentation of traceability (paragraph i of this subsection) or the inspection, testing, and authentication required when traceability cannot be established (paragraph ii of this subsection)?
- Will the manufacturer make such documentation available to the buyer?
Counterfeit avoidance and mitigation
Does the manufacturer have an appropriate strategy to ensure that products furnished to the buyer under this contract are not counterfeit? If yes, describe.
Supplier management
C-SCRM is like all risk management in that it is fundamentally about information – because you cannot manage what you do not know. Understanding and assessing your suppliers’ C-SCRM practices goes a long way toward better management of your own supply chain risk. This seems obvious on its face, but many sophisticated organizations do not have a robust understanding of their supply chains.
Are the manufacturer’s supply chain risk management processes identified, established, assessed, managed, and agreed to by organizational stakeholders? If yes, describe.
- Does the manufacturer identify, prioritize, and assess suppliers and partners of critical information systems, components and services using a documented supply chain risk assessment process? If yes, describe.
- Are the manufacturer’s suppliers and partners monitored to confirm that they have satisfied their obligations as required?
- Does the manufacturer conduct reviews of audits, summaries of test results, or other equivalent evaluations of suppliers/providers? If yes, describe.
- Does the manufacturer conduct response and recovery planning and testing with critical suppliers/providers? If yes, describe.
- Does the manufacturer have a documented policy to
- First, obtain electronic parts that are in production by the original manufacturer or an authorized aftermarket manufacturer?
- Obtain currently available in stock from the original manufacturers of the parts?
- Obtain currently available in stock from an authorized supplier?
- Obtain such parts exclusively from the original manufacturers of the parts or their authorized suppliers?Note: “Authorized supplier” as used here means a supplier, distributor, or an aftermarket manufacturer with a contractual arrangement with, or the express written authority of, the original manufacturer or current design activity to buy, stock, repackage, sell, or distribute the item.
- Does the manufacturer have established methods to qualify any non-OEM or non-authorized source, and guarantee the security and integrity of the item being purchased? If yes, describe.
- If the manufacturer chooses to use a reseller, distributor, wholesaler, or broker that is not the OEM or in an authorized relationship with the OEM for the item being acquired, will the manufacturer provide a detailed description of the methods used by the manufacturer to qualify the source, and guarantee the security and integrity of the item being purchased?
- Does the manufacturer have consistent, documented, and well-defined processes for validation and testing of end items from non-OEM or nonauthorized sources? If yes, describe.
- Does the manufacturer follow commercial best practices concerning the use of third parties to conduct reviews and approvals of sources? If yes, describe.
- Does the manufacturer have established enforcement mechanisms for delivery of items that do not meet validation and testing requirements in the terms and conditions of its purchases made from non-OEM or nonauthorized sources?
Insider threat management
Insider threat is not just a United States government concern. It is well known that intellectual property theft is rampant in the technology and defense industries and that humans’ actions are most often the enabling factor in cyber incidents.
- Does the manufacturer hold a current facility clearance and have an insider threat program (ITP) that complies with the National Industrial Security Program Operating Manual (NISPOM)?
- Does the manufacturer’s NISPOM ITP cover the business unit that is providing products or services to this program?
If the manufacturer’s ITP is not compliant with the NISPOM or does not cover the business unit that is providing products or services to this program:
- Does the manufacturer have an ITP?
- Does the manufacturer provide insider threat training for ITP personnel and awareness for other employees?
- Does the manufacturer monitor its own network activity?
- Does the manufacturer gather, integrate, and provide for reporting of relevant and credible information indicative of a potential or actual insider threat to deter employees from becoming insider threats?
- Does the manufacturer conduct self-inspections of its ITP?
Supplier cybersecurity (by NIST CSF function)
The NIST Cybersecurity Framework is increasingly the de-facto global C-SCRM standard, and it has been adopted in some form by other governments and a multitude of private sector organizations. The practices in this section are derived from a decade-long research program conducted by the University of Maryland and have been adapted into question format for purposes of developing this document. This research created the first and only empirically supported analysis of the effects on an organization’s cyber risk profile correlated with the extent of its adoption of the NIST CSF. In short, the adoption of these practices has been scientifically demonstrated to reduce the risk of cyber incidents. This section is also formulated as a questionnaire for suppliers but can be reformulated as contractual requirements as described in the introduction.
- Does your information and communications technology (ICT) asset management program identify and classify data, systems, and processes according to risk/criticality?
- Do you know the largest number of confidential records in any segregated database?
- Are all network/application communication flows documented and mapped?
- Does your organization have a map with critical physical supply, distribution, and service hubs/nodes, and interrelated flows to help you visualize the ICT supply chain?
- Do you have a supplier management program that establishes and monitors external supplier cybersecurity standards?
- Does your risk dashboard/registry define key cyber risks?
- Does your organization frequently or extensively use NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations?
- Does your organization frequently or extensively use SAE AS649 Avoidance, Detection, Mitigation, and Disposition of Fraudulent/Counterfeit Electronic Parts?
- Do you employ network access control (NAC) for remote connections?
- Do you physically and logically segregate your sensitive network segments?
- Is the information of different sensitivity levels prohibited from residing on the same system?
- In addition to data being protected at rest and in transit, are the encryption keys securely managed?
- Are the encryption keys stored separately from the data on a key management server?
- Do you employ FIPs-validated or National Security Agency-approved cryptography to implement signatures?
- Do you have documented baseline configuration standards for all devices connected to the corporate network?
- Is the production environment separate from other development and testing environments?
- Is production data only located in the production environment?
- Do you use end-to-end configuration management systems to track changes to software and settings?
- Do you quarantine nonconforming products until they can be verified through inspection/testing?
- Do you quarantine code from outside suppliers in proxy servers to undergo virus scanning and authentication procedures?
- Has an organizational baseline of expected data flows been established?
- Does your SIEM dashboard display event information for units managed by the external service provider?
- Is antivirus software deployed on endpoints to detect malicious code?
- Do you do in-house final inspection and conformity assessments of technology products and components that you manufacture prior to internal use or release to the customer?
- Do you require any counterfeit/gray market products that are detected and do not have forensic or evidentiary value to be destroyed by reputable disposers?
- Do you have a defined incident response team that has high-level participation from all pertinent business functions and has clearly defined roles for response team members?
- Do you have an incident response plan that addresses system details and procedures for reporting and managing a suspected incident?
- Does your forensics capability rely on a third-party security company with an ongoing retainer?
- Do you have an IT system-level data backup/restore process that will allow for the restoration of normal business processing in the event of disaster (including ransomware or DDoS)?
- Do you think your company is positioned to file and settle cyber insurance claims faster than your competitors?
- Do you have cyber risk communications mechanisms in place to communicate recovery status with your employees and/or shareholders?
Use of commercial standards
- Does the manufacturer use commercial, consensus-based standards (for example, ISO/IEC, COBIT) in its production and delivery of the items being purchased by the buyer?
- If yes, list all standards used and identify whether the manufacturer has a current third-party certificate of conformance to each, as applicable.
Appropriately managing cyber supply chain risk is a big job, and like all cybersecurity, it is a job that is never finished. As has been said — security is a journey, not a destination. Modern supply chains are global and dynamic, and while the practices listed in this article can be useful in creating or improving a C-SCRM program, they are not the only things that need to go into such a program. A C-SCRM program is most effective when it combines cybersecurity with logistics supply chain management practices and supplier financial management practices to provide a holistic risk picture.
