In early May, NIST (the U.S. government’s National Institute of Standards and Technology) updated its recommendations for managing cybersecurity risk across the supply chain. The new document, SP 800-161r1, is titled “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations.”

NIST defines the supply chain as “the linked set of resources and processes between and among multiple levels of an enterprise… (including) the sourcing of products and services and (extending) through the product and service lifecycle.” Cybersecurity supply chain risks are similarly varied in nature — they include vulnerabilities in open source software, IP theft, supply chain disruptions due to a downstream supplier being compromised, and more.

SP 800-161r1 is an updated version of NIST’s 2015 report on the same topic. The 315-page publication targets a broad range of cybersecurity supply chain risk management stakeholders, including security leaders, engineering teams, project managers, and procurement officials. It includes guidance in areas like:

  • Assessing your current risk posture
  • Making supply chain security an enterprise-wide project
  • Managing supply chain risks throughout the SDLC
  • Vetting open source software components
  • Evaluating software vendors

In this blog, we’ll review several of the publication’s key themes, with a focus on the people, processes, and strategies that can help organizations strengthen security across the supply chain. We’ll also highlight several templates that organizations may find useful in supporting risk management activities.

Note: In addition to refreshing its guidance for the broader challenge of cybersecurity supply chain risk management, NIST also recently published new guidelines specific to software supply chain security. We will review the new software supply chain guidance (which stems from the Biden Administration’s 2021 executive order) in a separate blog post.

1. Staffing and Structuring Risk Management Programs

The best way to staff and structure a cybersecurity supply chain risk management (C-SCRM) program depends on an organization’s size and type — a 100,000-employee enterprise has very different needs and resources than a small startup.

NIST’s guidance on staffing and structuring a C-SCRM program is targeted primarily at larger enterprises, so the specific framework discussed in this section may not be applicable to your organization. However, whether your C-SCRM team consists of two people or 20, the objective should be similar: to develop, implement, and refine processes that continuously monitor and reduce supply chain risk.

(NIST recommends that the risk management team include individuals involved in a variety of important business processes — not just security or engineering. Also, organizations may find it makes sense to fold supply chain risk management teams into existing risk management functions, or, in other cases, to create a separate department.)

With that as a backdrop, NIST SP 800-161r1 proposes a three-tiered approach to staffing and structuring a C-SCRM program. The idea behind this suggested framework is that enterprises should address risks from three different perspectives: strategic, operational, and tactical.

“In multilevel risk management, the C-SCRM process is seamlessly carried out across the three tiers with the overall objective of continuous improvement in the enterprise’s risk-related activities and effective inter- and intra-level communication among stakeholders with a vested interest in C-SCRM.”

Enterprise Level

  • Activities: Creates high-level risk management strategies, policies, and implementation plans.
  • People: C-suite, such as the CISO, CIO, CEO, or CFO.

Appendix D of NIST’s report includes a template (starting on Page 196) that you can use as a starting point to craft your strategy and implementation plan. The template includes sections for purpose (1.1.1), authority and compliance (1.1.2), strategic objectives (1.1.3), implementation plan and progress tracking (1.1.4), roles and responsibilities (1.1.5), definitions (1.1.6), and revision and maintenance (1.1.7).

Appendix D also includes two templates organizations can use to help draft C-SCRM policy documents. One is more geared toward the enterprise level, the second toward the mission and business process level. These templates start on Page 203.

Mission and Business Process Level

  • Activities: Takes enterprise-level guidance and translates it into strategies, policies, and implementation plans for specific mission areas and business lines.
  • People: Business managers, such as program managers, project managers, and “other management related to reliability, safety, security, quality” and similar.

Operational Level

  • Activities: Implements C-SCRM policies and requirements as outlined by higher tiers.
  • People: System managers, such as architects, developers, or engineers.

The publication also includes a template for implementation-specific C-SCRM plans, which begins on Page 208. Sections include system context (name, description, operational status, etc), contingencies and emergencies, security controls, and more.

2. The Continuous Process of Risk Management

The first section of this post covered SP 800-161r1’s theme of integrating multiple perspectives and teams into cybersecurity supply chain risk management. Here, we’ll discuss a second major theme from the report — the value of making C-SCRM a “continuous and iterative” process.

NIST outlines a four-part framework to help organizations understand and respond to threats on an ongoing basis.

Frame Risk

In this context, framing risk essentially means creating a foundation for how risk-based decisions are made. It includes areas like:

  • Risk assumptions: Baseline assumptions about an organization’s current security landscape, such as threat impact and likelihood.
  • Risk constraints: Roadblocks that prevent organizations from properly assessing, quickly responding, and monitoring risk.
  • Risk tolerance: For example, an organization may choose to de-prioritize remediating low-severity CVEs
  • Priorities and trade-offs: Are certain business lines or products more important from a supply chain security perspective than others?

Assess Risk

The assessment should cover not only threats and vulnerabilities, but also the likelihood that your organization will be impacted, and the potential degree of harm suffered.

Respond to Risk

Based on the assessment — and in the context of enterprise-wide strategies and policies — organizations should implement appropriate mitigation controls.

Monitor Risk

Review and track the success of ongoing risk mitigation strategies, as well as fundamental changes to the threat landscape. These may include supply chain disruptions, manufacturing location changes for a certain component, and new information about a severe vulnerability.

For more information about activities in each phase of the C-SCRM process, visit Appendix G (which begins on page 253) of NIST’s report.

3. Scrutinizing Software Vendors

Now, we'll shift from discussing NIST's recommendations around people and processes to more specific strategies designed to improve the vetting of new software.

Although there may be a tendency to assume software vendors — especially larger, more established businesses — have strong cybersecurity measures in place, there is risk any time you acquire a new software component.

Accordingly, NIST provides comprehensive guidance — from procurement through renewal — to help organizations assess vendors’ security policies and processes.

Questions to Ask During Procurement

NIST SP 800-161r1 includes a lengthy checklist (pages 220-227) designed to help organizations evaluate prospective software vendors. Example checklist items include:

  • Is there foreign ownership, control, or influence (FOCI) over the supplier or any business entities involved in the supply chain? If so, is the FOCI from a foreign adversary of the United States or country of concern?
  • Does the manufacturer provide a bill of materials (BOM) for the products, service, or components, including all logic-bearing (e.g., readable, writable, programmable) hardware, firmware, and software?
  • Is the supplier using trusted information assurance controls to safeguard the development environment (e.g., secure network configurations, strict access controls, dynamic/static vulnerability management tools, penetration testing)?
  • Does the supplier validate open source software prior to use?

(Vendors are actually required to make a software bill of materials available with each product when selling into the federal government per the 2021 Biden Administration executive order.)

Additionally, NIST recommends that organizations build cybersecurity risk management into the contract itself. Specifically, this may include certain terms and conditions that cover ”changes that may affect cybersecurity risks in the supply chain should occur throughout the life cycle and may trigger reevaluation of the original assessment or require a mitigation response.”

4. Evaluating Open Source Software Security Risks

Open source software makes up over 90% of the codebase of modern applications. So, while it’s certainly critical to vet proprietary software vendors, it’s equally important to apply standards to the acquisition and ongoing use of open source.

NIST recommends organizations obtain OSS from “vetted and approved libraries.” Specifically, the publication suggests organizations “understand and review the open source community’s typical procedures regarding provenance, configuration management, sources, binaries, reusable frameworks, reusable libraries’ availability for testing and use, and any other information that may impact levels of exposure to cybersecurity risks throughout the supply chain.”

“Other information” may include how the open source project is maintained and supported (to avoid a colors.js situation), along with more explicit indicators of sustainable open source like OpenSSF Best Practices Badge. Some organizations use software composition analysis tools like FOSSA, which identify all the open source you are using and if there are any vulnerabilities in that open source, during the vetting process as well.

In addition to vetting new open source components, it’s important to monitor and mitigate issues on an ongoing basis. This is another area where tooling can help. For example, many organizations integrate FOSSA with their CI/CD pipeline so any time a new change is committed and a build is triggered, a new scan happens. (This is a particularly important safeguard given the realities of modern development workflows — it may be impractical for teams to conduct extensive manual vetting of new open source components.)

Applying NIST SP 800-161r1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations

NIST’s refreshed “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations” isn’t a one-size-fits-all publication, but it does offer a variety of frameworks and templates that a broad range of organizations may find useful.

For more information on managing the specific risks associated with the software supply chain, consider viewing our on-demand webinar Beyond the CVE — Addressing Novel Supply Chain Threats. During the webinar, we highlight emerging signs of risky or compromised open source packages (such as dependency confusion and typosquatting) and offer actionable guidance on addressing them.