NIST SP 800-161 Rev. 1 日本語訳

NIST Special Publication 800 NIST SP 800-161r1-upd1

Jon Boyens Angela Smith Nadya Bartol Kris Winkler Alex Holbrook Matthew Fallon

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-161r1-upd1

NIST Special Publication 800 NIST SP 800-161r1-upd1

Jon Boyens Angela Smith

Computer Security Division Information Technology Laboratory

Nadya Bartol Kris Winkler Alex Holbrook Matthew Fallon Boston Consulting Group

This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-161r1-upd1

May 2022

INCLUDES UPDATES AS OF 11-01-2024; SEE APPENDIX K

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology

Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

Certain equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2024-09-25 Supersedes NIST Special Publication 800-161r1 (May 2022) https://doi.org/10.6028/NIST.SP.800-161r1

Boyens J, Smith A, Bartol N, Winkler K, Holbrook A, Fallon M (2022) Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-161r1-upd1, Includes updates as of November 1, 2024. https://doi.org/10.6028/NIST.SP.800-161r1-upd1

Jon Boyens: 0000-0002-5666-8750

Contact Information scrm-nist@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Additional Information Additional information about this publication is available at https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final, including related content, potential updates, and document history.

All comments are subject to release under the Freedom of Information Act (FOIA).

Organizations are concerned about the risks associated with products and services that may potentially contain malicious functionality, are counterfeit, or are vulnerable due to poor manufacturing and development practices within the supply chain. These risks are associated with an enterprise’s decreased visibility into and understanding of how the technology they acquire is developed, integrated, and deployed or the processes, procedures, standards, and practices used to ensure the security, resilience, reliability, safety, integrity, and quality of the products and services.

This publication provides guidance to organizations on identifying, assessing, and mitigating cybersecurity risks throughout the supply chain at all levels of their organizations. The publication integrates cybersecurity supply chain risk management (C-SCRM) into risk management activities by applying a multilevel, C-SCRM-specific approach, including guidance on the development of C-SCRM strategy implementation plans, C-SCRM policies, C-SCRM plans, and risk assessments for products and services.

acquire; C-SCRM; cybersecurity supply chain; cybersecurity supply chain risk management; information and communication technology; risk management; supplier; supply chain; supply chain risk assessment; supply chain assurance; supply chain risk; supply chain security.

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Patent Disclosure Notice

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

The authors — Jon Boyens of the National Institute of Standards and Technology (NIST), Angela Smith (NIST), Nadya Bartol, Boston Consulting Group (BCG), Kris Winkler (BCG), Alex Holbrook (BCG), and Matthew Fallon (BCG) — would like to acknowledge and thank Alexander Nelson (NIST), Murugiah Souppaya (NIST), Paul Black (NIST), Victoria Pillitteri (NIST), Kevin Stine (NIST), Stephen Quinn (NIST), Nahla Ivy (NIST), Isabel Van Wyk (NIST), Jim Foti (NIST), Matthew Barrett (Cyber ESI), Greg Witte (Huntington Ingalls), R.K. Gardner (New World Technology Partners), David A. Wheeler (Linux Foundation), Karen Scarfone (Scarfone Cybersecurity), Natalie Lehr-Lopez (ODNI/NCSC), Halley Farrell (BCG), and the original authors of NIST SP 800-161, Celia Paulsen (NIST), Rama Moorthy (Hatha Systems), and Stephanie Shankles (U.S. Department of Veterans Affairs) for their contributions. The authors would also like to thank the C-SCRM community, which has provided invaluable insight and diverse perspectives for managing the supply chain, especially the departments and agencies who shared their experience and documentation on NIST SP 800-161 implementation since its release in 2015, as well as the public and private members of the Enduring Security Framework who collaborated to provide input to Appendix F.

Information and communications technology (ICT) and operational technology (OT) rely on a complex, globally distributed, extensive, and interconnected supply chain ecosystem that is comprised of geographically diverse routes and consists of multiple levels of outsourcing. This ecosystem is composed of public and private sector entities (e.g., acquirers, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers)¹ that interact to research, develop, design, manufacture, acquire, deliver, integrate, operate, maintain, dispose of, and otherwise utilize or manage ICT/OT products and services. These interactions are shaped and influenced by a set of technologies, laws, policies, procedures, and practices.

This ecosystem has evolved to provide a set of highly refined, cost-effective, and reusable solutions. Public and private sector entities have rapidly adopted this ecosystem of solutions and increased their reliance on commercially available products, system integrator support for custom-built systems, and external service providers. This, in turn, has increased the complexity, diversity, and scale of these entities, and often their interdependent supply chains.

In this document, the term supply chain refers to the linked set of resources and processes between and among multiple levels of an enterprise, each of which is an acquirer that begins with the sourcing of products and services and extends through the product and service life cycle.

原本PDFの抜粋画像

Given the definition of supply chain, cybersecurity risks throughout the supply chain2,3 refers to the potential for harm or compromise that may arise from suppliers, their supply chains, their products, or their services. Cybersecurity risks throughout the supply chain are the results of threats that exploit vulnerabilities or exposures within products and services that traverse the supply chain or threats that exploit vulnerabilities or exposures within the supply chain itself. Examples of cybersecurity risks throughout the supply chain include:

Note that SCRM and C-SCRM refer to the same concept for the purposes of NIST publications. In general practice, C-SCRM is at the nexus of traditional Supply Chain Risk Management (SCRM) and traditional Information Security. Organizations may employ different terms and definitions for SCRM outside of the scope of this publication. This publication does not address many of the non-cybersecurity aspects of SCRM.

原本PDFの抜粋画像

Technology solutions provided through a supply chain of competing vendors offer significant benefits, including low cost, interoperability, rapid innovation, and product feature variety. Whether proprietary, government-developed, or open source, these solutions can meet the needs of a global base of public and private sector customers. However, the same factors that create such benefits also increase the potential for cybersecurity risks that arise directly or indirectly from the supply chain. Cybersecurity risks throughout the supply chain are often undetected and impact the acquirer and the end-user. For example, deployed software is typically a commercial off-the-shelf (COTS) product, which includes smaller COTS or open source software components developed or sourced at multiple tiers. Updates to software deployed across enterprises often fail to update the smaller COTS components with known vulnerabilities, including cases in which the component vulnerabilities are exploitable in the larger enterprise software. Software users may be unable to detect the smaller known vulnerable components in larger COTS software (e.g., lack of transparency, insufficient vulnerability management). The non-standardized nature of C-SCRM practices adds an additional layer of complexity as this makes the consistent measurement and management of cybersecurity risks throughout the supply chain difficult for both the organization and members of its supply chain (e.g., suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers).

In this document, the practices and controls described for Cybersecurity Supply Chain Risk Management (C-SCRM) apply to both information technology (IT) and operational technology (OT) environments and are inclusive of IoT. Similar to IT environments that rely on ICT products and services, OT environments rely on OT and ICT products and services, with cybersecurity risks arising from ICT/OT products, services, suppliers, and their supply chains. Enterprises should include OT-related suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers within the scope of their C-SCRM activities.

原本PDFの抜粋画像

When engaging with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers, agencies should carefully consider the breadth of the Federal Government’s footprint and the high likelihood that individual agencies may enforce varying and conflicting C-SCRM requirements. Overcoming this complexity requires interagency coordination and partnerships. The passage of the Federal Acquisition Supply Chain Security Act (FASCSA) of 2018 aimed to address this concern by creating a government-wide approach to the problem of supply chain security in federal acquisitions by establishing the Federal Acquisition Security Council (FASC). The FASC serves as a focal point of coordination and information sharing and a harmonized approach to acquisition security that addresses C-SCRM in acquisition processes and procurements across the federal enterprise. In addition, the law incorporated SCRM into FISMA by requiring reports on the progress and effectiveness of the agency’s supply chain risk management, consistent with guidance issued by the Office of Management and Budget (OMB) and the Council.

Note that this publication uses the term “enterprise” to describe Level 1 of the risk management hierarchy. In practice, an organization is defined as an entity of any size, complexity, or positioning within a larger enterprise structure (e.g., a federal agency or company). By this definition, an enterprise is an organization, but it exists at the top level of the hierarchy where individual senior leaders have unique risk management responsibilities [IR8286]. Several organizations may comprise an enterprise. In these cases, an enterprise may have multiple Level 1s with stakeholders and activities defined at both the enterprise and the organization levels. Level 1 activities conducted at the enterprise level should inform those activities completed within the subordinate organizations. Enterprises and organizations tailor the C-SCRM practices described in this publication as applicable and appropriate based on their own unique enterprise structure. There are cases in this publication in which the term “organization” is inherited from a referenced source (e.g., other NIST publication, regulatory language). Refer to NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM), for further guidance on this topic.

Cybersecurity Supply Chain Risk Management (C-SCRM) is a systematic process for managing exposure to cybersecurity risks throughout the supply chain and developing appropriate response strategies, policies, processes, and procedures. The purpose of this publication is to provide guidance to enterprises on how to identify, assess, select, and implement risk management processes and mitigating controls across the enterprise to help manage cybersecurity risks throughout the supply chain. The content in this guidance is the shared responsibility of different disciplines with different SCRM perspectives, authorities, and legal considerations.

The C-SCRM guidance provided in this document is not one-size-fits-all. Instead, the guidance throughout this publication should be adopted and tailored to the unique size, resources, and risk circumstances of each enterprise. Enterprises adopting this guidance may vary in how they implement C-SCRM practices internally. To that end, this publication describes C-SCRM practices observed in enterprises and offers a general prioritization of C-SCRM practices (i.e., Foundational, Sustaining, Enabling)⁴ for enterprises to consider as they implement and mature

C-SCRM. However, this publication does not offer a specific roadmap for enterprises to follow to reach various states of capability and maturity.

The processes and controls identified in this document can be modified or augmented with enterprise-specific requirements from policies, guidelines, response strategies, and other sources. This publication empowers enterprises to develop C-SCRM strategies tailored to their specific mission and business needs, threats, and operational environments.

C-SCRM is an enterprise-wide activity that should be directed as such from a governance perspective, regardless of the specific enterprise structure.

This publication is intended to serve a diverse audience involved in C-SCRM, including:

The external system service providers discussed in this publication include cloud service providers. This publication does not replace the guidance provided with respect to federal agency assessments of cloud service providers’ security. When applying this publication to cloud service providers, federal agencies should first use Federal Risk and Authorization Program (FedRAMP) cloud services security guidelines and then apply this document for those processes and controls that are not addressed by FedRAMP.⁵

Given the wide audience of this publication, several reader profiles have been defined to point readers to the sections of the document that most closely pertain to their use case. Some readers will belong to multiple profiles and should consider reading all applicable sections. Any reader accountable for the implementation of a C-SCRM capability or function within their enterprise, regardless of role, should consider the entire document applicable to their use case.

These readers are those responsible for enterprise risk management and cybersecurity supply chain risk management. These readers may help develop C-SCRM policies and standards, perform assessments of cybersecurity risks throughout the supply chain, and serve as subject matter experts for the rest of the enterprise. The entire document is relevant to and recommended for readers fitting this profile.

These readers are the personnel responsible for the activities that create and/or manage risk within the enterprise. They may also own the risk as part of their duties within the mission or business process. They may have responsibilities for managing cybersecurity risks throughout the supply chain for the enterprise. Readers in this group may seek general knowledge and guidance on Cybersecurity Supply Chain Risk Management. Recommended reading includes:

These readers are those with C-SCRM responsibilities as part of their role in the procurement or acquisition function of an enterprise. Acquisition personnel may execute C-SCRM activities as a part of their general responsibilities in the acquisition and procurement life cycle. These personnel will collaborate closely with the enterprise’s C-SCRM personnel to execute C-SCRM activities with acquisition and procurement. Recommended reading includes:

These readers should pay special attention to requisite controls for supplier contracts and include them in agreements with both primary and sub-tier contractor parties.

These readers are those with operational responsibility for protecting the confidentiality, integrity, and availability of the enterprise’s critical processes and information systems. As part of those responsibilities, these readers may find themselves directly or indirectly involved with conducting Cybersecurity Supply Chain Risk Assessments and/or the selection and implementation of C-SCRM controls. In smaller enterprises, these personnel may bear the responsibility for implementing C-SCRM and should refer to Sec. 1.4.1 for guidance. Recommended reading includes:

These readers are those with responsibilities for executing activities within an information system’s system development life cycle (SDLC). As part of their SDLC responsibilities, these readers will be responsible for the execution of operational-level C-SCRM activities. Specifically, these personnel may be concerned with implementing C-SCRM controls to manage cybersecurity risks that arise from products and services provided through the supply chain within the scope of their information system(s). Recommended reading includes:

C-SCRM encompasses activities that span the entire SDLC, including research and development, design, manufacturing, acquisition, delivery, integration, operations and maintenance, disposal, and the overall management of an enterprise’s products and services. Enterprises should integrate C-SCRM within the SDLC as this is a critical area for addressing cybersecurity risks throughout the supply chain. C-SCRM is the organized and purposeful management of cybersecurity risks throughout the supply chain. C-SCRM requires enterprise recognition and awareness, and it lies at the intersections of security, suitability, safety, reliability, usability, quality, integrity, efficiency, maintainability, scalability, and resilience, as depicted in Fig. 1. These dimensions are layers of consideration for enterprises as they approach C-SCRM and should be positively impacted by C-SCRM.

Fig. 1. Dimensions of C-SCRM

Contemporary enterprises run complex information systems and networks to support their missions. These information systems and networks are composed of ICT/OT¹⁰ products and components made available by suppliers, developers, and system integrators. Enterprises also acquire and deploy an array of products and services, including:

These services may span the entire SDLC for an information system or service and may be:

The responsibility and accountability for the services and associated activities performed by different parties within this ecosystem are usually defined by agreement documents between the enterprise and suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers.

Enterprises depend on the supply chain to provide a variety of products and services to enable the enterprise to achieve its strategic and operational objectives. Identifying cybersecurity risks throughout the supply chain is complicated by the information asymmetry that exists between acquiring enterprises and their suppliers and service providers. Acquirers often lack visibility and understanding of how acquired technology is developed, integrated, and deployed and how the services that they acquire are delivered. Additionally, acquirers with inadequate or absent C-SCRM processes, procedures, and practices may experience increased exposure cybersecurity risks throughout the supply chain. The level of exposure to cybersecurity risks throughout the supply chain depends largely on the relationship between the products and services provided and the criticality of the missions, business processes, and systems that they support. Enterprises have a variety of relationships with their suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Figure 2 depicts how these diverse relationships affect an enterprise’s visibility and control of the supply chain.

Fig. 2. An enterprise’s visibility, understanding, and control of its supply chain

Some supply chain relationships are tightly intermingled, such as a system integrator’s development of a complex information system operating within the federal agency’s authorization boundary or the management of federal agency information systems and resources by an external service provider. These relationships are usually guided by an agreement (e.g., contract) that establishes detailed functional, technical, and security requirements and may provide for the custom development or significant customization of products and services. For these relationships, system integrators and external service providers are likely able to work with the enterprise to implement such processes and controls (listed within this document) that are deemed appropriate based on the results of a criticality and risk assessment and cost/benefit analysis. This may include floating requirements upstream in the supply chain to ensure higher confidence in the satisfaction of necessary assurance objectives. The decision to extend such requirements must be balanced with an appreciation of what is feasible and cost-effective. The degree to which system integrators and external service providers are expected to implement C-SCRM processes and controls should be weighed against the risks to the enterprise posed by not adhering to those additional requirements. Often, working directly with the system integrators and external service providers to proactively identify appropriate mitigation processes and controls will help create a more cost-effective strategy.

Procuring ICT/OT products from suppliers establishes a direct relationship between those suppliers and the acquirers. This relationship is also usually guided by an agreement between the acquirer and the supplier. However, commercial ICT/OT developed by suppliers are typically designed for general purposes for a global market and are not tailored to an individual customer’s specific operational or threat environments. Enterprises should perform due diligence and research regarding their specific C-SCRM requirements to determine if an IT solution is fit for purpose,¹² includes requisite security features and capabilities, will meet quality and resiliency expectations, and requires support by the supplier for the product or product components over its life cycle.

An assessment of the findings of an acquirer’s research about a product, which may include engaging in direct dialogue with suppliers whenever possible, will help acquirers understand the characteristics and capabilities of existing ICT/OT products and services, set expectations and requirements for suppliers, and identify C-SCRM needs not yet satisfied by the market. It can also help identify emerging solutions that may at least partially support the acquirer’s needs. Overall, such research and engagement with a supplier will allow the acquirer to better articulate their requirements to align with and drive market offerings and to make risk-based decisions about product purchases, configurations, and usages within their environment.

Managing Cost and Resources

原本PDFの抜粋画像

Balancing exposure to cybersecurity risks throughout the supply chain with the costs and benefits of implementing C-SCRM practices and controls should be a key component of the acquirer’s overall approach to C-SCRM.

Enterprises should be aware that implementing C-SCRM practices and controls necessitates additional financial and human resources. Requiring a greater level of testing, documentation, or security features from suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers may increase the price of a product or service, which may result in increased cost to the acquirer. This is especially true for those products and services developed for general-purpose applications and not tailored to the specific enterprise security or C-SCRM requirements. When deciding whether to require and implement C-SCRM practices and controls, acquirers should consider both the costs of implementing these controls and the risks of not implementing them.

When possible and appropriate, acquirers should allow suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers the opportunity to reuse applicable existing data and documentation that may provide evidence to support C-SCRM (e.g., certification of a vendor to a relevant standard, such as ISO 27001). Doing this results in cost savings to the acquirer and supplier. However, in some cases, documentation reuse may not be appropriate as additional or different information may be needed, and a reassessment may be required (e.g., previously audited supplier developing a new, not yet produced product). Regardless, acquirers should identify and include security considerations early in the acquisition process.

This publication applies the multilevel risk management approach of [SP80039] by providing C-SCRM guidance at the enterprise, mission, and operational levels. It also introduces a navigational system for [SP80037] allowing users to focus on relevant sections of this publication more easily. Finally, it contains an enhanced overlay of specific C-SCRM controls, building on [SP80053r5].

The guidance/controls contained in this publication are built on existing multidisciplinary practices and are intended to increase the ability of enterprises to manage the associated cybersecurity risks throughout the supply chain over the entire life cycle of systems, products, and services. It should be noted that this publication gives enterprises the flexibility to either develop stand-alone documentation (e.g., policies, assessment and authorization [A&A] plan, and C-SCRM plan) for C-SCRM or to integrate it into existing agency documentation.

For individual systems, this guidance is recommended for use with information systems at all impact categories, according to [FIPS199]. The agencies may choose to prioritize applying this guidance to systems at a higher impact level or to specific system components. Finally, this document describes the development and implementation of C-SCRM Strategies and Implementation Plans for development at the enterprise and mission and business level of an enterprise and a C-SCRM system plan at the operational level of an enterprise. A C-SCRM plan at the operational level is informed by the cybersecurity supply chain risk assessments and should contain C-SCRM controls tailored to specific agency mission and business needs, operational environments, and/or implementing technologies.

Integration into the Risk Management Process

The processes in this publication should be integrated into the enterprise’s existing SDLCs and enterprise environments at all levels of risk management processes and hierarchy (e.g., enterprise, mission, system), as described in [SP80039]. Section 2 provides an overview of the [SP80039] risk management hierarchy and approach and identifies C-SCRM activities in the risk management process. Appendix C builds on Sec. 2 of [SP80039], providing descriptions and explanations of ICT/OT SCRM activities. The structure of Appendix C mirrors [SP80039].

Implementing C-SCRM in the Context of SP 800-37, Revision 2

C-SCRM activities described in this publication are closely related to the Risk Management Framework described in [SP80037]. Specifically, C-SCRM processes conducted at the operational level should closely mirror and/or serve as inputs to those steps completed as part of [SP80037]. C-SCRM activities completed at Levels 1 and 2 should provide inputs (e.g., risk assessment results) to the operational level and RMF-type processes, where possible and applicable. Section 2 and Appendix C describe the linkages between C-SCRM and [SP80037] in further detail.

This publication builds on the concepts promoted within other NIST publications and tailors those concepts for use within Cybersecurity Supply Chain Risk Management. As a result of this relationship, this publication inherits many of its concepts and looks to other NIST publications to continue advancing base frameworks, concepts, and methodologies. Those NIST publications include:

This publication also draws upon concepts and work from other regulations, government reports, standards, guidelines, and best practices. A full list of those resources can be found in Appendix H.

Key Takeaways¹³

原本PDFの抜粋画像

The Supply Chain. ICT/OT relies on a globally distributed, interconnected supply chain ecosystem that consists of public and private sector entities (e.g., acquirers, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers).

Supply Chain Products and Services. Products and services that enterprises rely on the supply chain for include the provision of systems and system components, open source and custom software, operational support services, hosting systems and services, and performing system support roles.

Supply Chain Benefits and Risk. This ecosystem offers benefits such as cost savings, interoperability, rapid innovation, product feature variety, and the ability to choose between competing vendors. However, the same mechanisms that provide those benefits might also introduce a variety of cybersecurity risks throughout the supply chain (e.g., a supplier disruption that causes a reduction in service levels and leads to dissatisfaction from the enterprise’s customer base).

Cybersecurity Supply Chain Risk Management (C-SCRM). C-SCRM, as described in this document, is a systematic process that aims to help enterprises manage cybersecurity risks throughout the supply chain. Enterprises should identify, adopt, and tailor the practices described in this document to best suit their unique strategic, operational, and risk context.

Scope of C-SCRM. C-SCRM encompasses a wide array of stakeholder groups that include information security and privacy, system developers and implementers, acquisition, procurement, legal, and HR. C-SCRM covers activities that span the entire system development life cycle (SDLC), from initiation to disposal. In addition, identified cybersecurity risks throughout the supply chain should be aggregated and contextualized as part of enterprise risk management processes to ensure that the enterprise understands the total risk exposure of its critical operations to different risk types (e.g., financial risk, strategic risk).

C-SCRM should be integrated into the enterprise-wide risk management process described in [SP80039] and depicted in Fig. 3. This process includes the following continuous and iterative steps:

Fig. 3. Risk management process

Managing cybersecurity risks throughout the supply chain is a complex undertaking that requires cultural transformation and a coordinated, multidisciplinary approach across an enterprise. Effective cybersecurity supply chain risk management (C-SCRM) requires engagement from stakeholders inside the enterprise (e.g., departments, processes) and outside of the enterprise (e.g., suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers) to actively collaborate, communicate, and take actions to secure favorable C-SCRM outcomes. Successful C-SCRM requires an enterprise-wide cultural shift to a state of heightened awareness and preparedness as to the potential ramifications of cybersecurity risks throughout the supply chain.

Enterprises should aim to infuse perspectives from multiple disciplines and processes (e.g., information security, procurement, enterprise risk management, engineering, software development, IT, legal, HR) into their approaches to managing cybersecurity risks throughout the supply chain. Enterprises may define explicit roles to bridge and integrate these processes as a part of an enterprise’s broader risk management activities. This orchestrated approach is an integral part of an enterprise’s effort to identify C-SCRM priorities, develop solutions, and incorporate C-SCRM into overall risk management decisions. Enterprises should perform C-SCRM activities as a part of the acquisition, SDLC, and broader enterprise risk management processes. Embedded C-SCRM activities involve determining the criticality of functions and their dependency on the supplied products and services, identifying and assessing applicable risks, determining appropriate mitigating actions, documenting selected risk response actions, and monitoring performance of C-SCRM activities. As exposure to supply chain risk differs across (and sometimes within) enterprises, business and mission-specific strategies, and policies should set the tone and direction for C-SCRM across the enterprise.

Organizations should ensure that tailored C-SCRM plans are designed to:

原本PDFの抜粋画像

Today, every enterprise heavily relies on digital technology to fulfill its business and mission. Digital technology is comprised of ICT/OT products and is delivered through and supported by services. C-SCRM is a critical capability that every enterprise needs to have to address cybersecurity risks throughout the supply chain that arise from the use of digital technology. The depth, extent, and maturity of a C-SCRM capability for each enterprise should be based on the uniqueness of its business or mission, enterprise-specific compliance requirements, operational environment, risk appetite, and risk tolerance.

Establishing and sustaining a C-SCRM capability creates a number of significant benefits:

C-SCRM is fundamental to any effort to manage risk exposure arising from enterprise operations. Implementing C-SCRM processes and controls requires human, tooling, and infrastructure investments by acquirers and their developers, system integrators, external system service providers, and other ICT/OT-related service providers. However, enterprises have finite resources to commit to establishing and deploying C-SCRM processes and controls. As such, enterprises should carefully weigh the potential costs and benefits when making C-SCRM resource commitment decisions and make decisions based on a clear understanding of any risk exposure implications that could arise from a failure to commit the necessary resources to C-SCRM.

While there are cost-benefit trade-offs that must be acknowledged, the need to better secure supply chains is an imperative for both government and the private sector. The passage of the 2018 SECURE Technology Act,¹⁶ the formation of the FASC, and the observations from the 2015 and 2019 Case Studies in Cyber Supply Chain Risk Management captured in NIST Interagency or Internal Report (NIST IR) 8276, Key Practices in Cyber Supply Chain Risk Management, point to a broad public and private sector consensus: C-SCRM capabilities are a critical and foundational component of any enterprise’s risk posture.

Cybersecurity risks throughout the supply chain refers to the potential for harm or compromise that arises from the cybersecurity risks posed by suppliers, their supply chains, and their products or services. Examples of these risks include:

Risks such as these are realized when threats in the cybersecurity supply chain exploit existing vulnerabilities. Figure 4 depicts supply chain cybersecurity risks resulting from the likelihood that relevant threats may exploit applicable vulnerabilities and the consequential potential impacts.

Fig. 4. Cybersecurity risks throughout the supply chain

Supply chain cybersecurity vulnerabilities may lead to persistent negative impacts on an enterprise’s missions, ranging from a reduction in service levels leading to customer dissatisfaction to the theft of intellectual property or the degradation of critical mission and business processes. It may, however, take years for such vulnerabilities to be exploited or discovered. It may also be difficult to determine whether an event was the direct result of a supply chain vulnerability. Vulnerabilities in the supply chain are often interconnected and may expose enterprises to cascading cybersecurity risks. For example, a large-scale service outage at a major cloud services provider may cause service or production disruptions for multiple entities within an enterprise’s supply chain and lead to negative effects within multiple mission and business processes.

To integrate risk management throughout an enterprise, [SP80039] describes three levels, depicted in Fig. 5, that address risk from different perspectives: 1) the enterprise level, 2) the mission and business process level, and 3) the operational level. C-SCRM requires the involvement of all three levels.

Fig. 5. Multilevel enterprise-wide risk management¹⁹

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.

C-SCRM activities can be performed by a variety of individuals or groups within an enterprise, ranging from a single individual to committees, divisions, centralized program offices, or any other enterprise structure. C-SCRM activities are distinct for different enterprises depending on their structure, culture, mission, and many other factors. C-SCRM activities at each of the three levels include the production of different high-level C-SCRM deliverables.

Figure 6 provides an overview of the multilevel risk management structure and the associated strategies, policies, and plans developed at each level. Refer to Sec. 2.3.1 through 2.3.5 for a more in-depth discussion of the specific activities at each level.

Fig. 6. C-SCRM documents in multilevel enterprise-wide risk management

Implementing C-SCRM requires enterprises to establish a coordinated team-based approach and a shared responsibility model to effectively manage cybersecurity risks throughout the supply chain. Enterprises should establish and adhere to C-SCRM-related policies, develop and follow processes (often cross-enterprise in nature), and employ programmatic and technical mitigation techniques. The coordinated team approach, either ad hoc or formal, enables enterprises to effectively conduct a comprehensive, multi-perspective analysis of their supply chain and to respond to risks, communicate with external partners/stakeholders, and gain broad consensus regarding appropriate resources for C-SCRM. The C-SCRM team should work together to make decisions and take actions deriving from the input and involvement of multiple perspectives and expertise. The team leverages but does not replace those C-SCRM responsibilities and processes that should be specifically assigned to an individual enterprise or disciplinary area. Effective implementations of C-SCRM often include the adoption of a shared responsibility model, which distributes responsibilities and accountabilities for C-SCRM-related activities and risk across a diverse group of stakeholders. Examples of C-SCRM activities in which enterprises benefit from a multidisciplinary approach include developing a strategic sourcing strategy, incorporating C-SCRM requirements into a solicitation, and determining options for how best to mitigate an identified supply chain risk, especially one assessed to be significant.

Members of the C-SCRM team should be a diverse group of people involved in the various aspects of the enterprise’s critical processes, such as information security, procurement, enterprise risk management, engineering, software development, IT, legal, and HR. To aid in C-SCRM, these individuals should provide expertise in enterprise processes and practices specific to their discipline area and an understanding of the technical aspects and inter-dependencies of systems or information flowing through systems. The C-SCRM team may be an extension of an enterprise’s existing enterprise risk management function, grown as part of an enterprise’s cybersecurity risk management function, or operate out of a different department.

The key to forming multidisciplinary C-SCRM teams is breaking down barriers between otherwise disparate functions within the enterprise. Many enterprises begin this process from the top by establishing a working group or council of senior leaders with representation from the necessary and appropriate functional areas. A charter should be established outlining the goals, objectives, authorities, meeting cadences, and responsibilities of the working group. Once this council is formed, decisions can be made on how to operationalize the interdisciplinary approach at mission and business process and operational levels. This often takes the form of working groups that consist of mission and business process representatives who can meet at more regular cadences and address more operational and tactically focused C-SCRM challenges.

Table 1 shows a summary of C-SCRM stakeholders for each level with the specific C-SCRM activities performed within the corresponding level. These activities are either direct C-SCRM activities or have an impact on C-SCRM.

Table 1. Cybersecurity supply chain risk management stakeholders²⁰

The C-SCRM process should be carried out across the three risk management levels with the overall objective of continuous improvement of the enterprise’s risk-related activities and effective inter- and intra-level communication, thus integrating both strategic and tactical activities among all stakeholders with a shared interest in the mission and business success of the enterprise. Whether addressing a component, system, process, mission process, or policy, it is important to engage the relevant C-SCRM stakeholders at each level to ensure that risk management activities are as informed as possible. Figure 7 illustrates the relationship between key C-SCRM documents across the three levels.

Fig. 7. Relationship between C-SCRM documents

The next few sections provide example roles and activities at each level. Because every enterprise is different, however, activities may be performed at different levels than listed and as individual enterprise context requires.

Appendix A provides a number of mission and business C-SCRM controls that organizations can utilize in a tailored capacity to help guide Level 1, Level 2, and Level 3 C-SCRM activities. Note that the tailoring should be scoped to the organization’s risk management needs, and organizations should analyze the cost of not implementing C-SCRM policies, capabilities, and controls when evaluating alternative risk response courses of action. These costs may include poor quality or counterfeit products, supplier misuse of intellectual property, supplier tampering with or compromise of mission-critical information, and exposure to cyber attacks through vulnerable supplier information systems.

原本PDFの抜粋画像

Effective C-SCRM requires commitment, direct involvement, and ongoing support from senior leaders and executives. Enterprises should designate the responsibility for leading agency-wide SCRM activities to an executive-level individual, office (supported by an expert staff), or group (e.g., a risk board, executive steering committee, or executive leadership council) regardless of an agency’s specific organizational structure. Because cybersecurity risks throughout the supply chain can be present across every major business line, enterprises should ensure that C-SCRM roles and responsibilities are defined for senior leaders who participate in supply chain activities (e.g., acquisition and procurement, information security, information technology, legal, program management, and supply chain and logistics). Without establishing executive oversight of C-SCRM activities, enterprises are limited in their ability to make risk decisions across the organization about how to effectively secure their product and services.

Level 1 (Enterprise) sets the tone and direction for enterprise-wide C-SCRM activities by providing an overarching C-SCRM strategy, a C-SCRM policy, and a High-level Implementation Plan that shapes how C-SCRM is implemented across the enterprise. Within Level-1, governance structures are formed to enable senior leaders and executives to collaborate on C-SCRM with the risk executive (function), make C-SCRM decisions, delegate decisions to Level 2 and Level 3, and prioritize enterprise-wide resource allocation for C-SCRM. Level 1 activities help to ensure that C-SCRM mitigation strategies are consistent with the strategic goals and objectives of the enterprise. Level 1 activities culminate in the C-SCRM Strategy, Policy, and High-Level Implementation Plan that shape and constrain how C-SCRM is carried out at Level 2 and Level 3.

Ownership and accountability for cybersecurity risks in the supply chain ultimately lie with the head of the organization.

原本PDFの抜粋画像

C-SCRM requires accountability, commitment, oversight, direct involvement, and ongoing support from senior leaders and executives. Enterprises should ensure that C-SCRM roles and responsibilities are defined for senior leaders who participate in supply chain activities (e.g., acquisition and procurement, information security, information technology, legal, program management, and supply chain and logistics). At Level 1, an executive board is typically responsible for evaluating and mitigating all risks across the enterprise. This is generally achieved through an Enterprise Risk Management (ERM) council. Effective C-SCRM gathers perspectives from leaders, all generally within the ERM council – such as the chief executive officer (CEO), chief risk officer (CRO), chief information officer (CIO), chief legal officer (CLO)/general counsel, chief information security officer (CISO), and chief acquisition officer (CAO) – and informs advice and recommendations from the CIO and CISO to the executive board.

CIOs and/or CISOs may form a C-SCRM oriented-body to provide in-depth analysis to inform the executive board’s ERM council. The C-SCRM council serves as a forum for setting priorities and managing cybersecurity risk in the supply chain for the enterprise. The C-SCRM council or other C-SCRM-oriented body is responsible for developing the C-SCRM enterprise-wide strategy. The C-SCRM strategy makes explicit the enterprise’s assumptions, constraints, risk tolerances, and priorities/trade-offs as established by the ERM council. C-SCRM is integrated into the organization’s overall enterprise risk management through the CIO and/or CISO membership within the executive board’s ERM council.

These leaders are also responsible and accountable for developing and promulgating a holistic set of policies that span the enterprise’s mission and business processes, guiding the establishment and maturation of a C-SCRM capability and the implementation of a cohesive set of C-SCRM activities. Leaders should establish a C-SCRM PMO or other dedicated C-SCRM-related function to drive C-SCRM activities and serve as a fulcrum for coordinated, C-SCRM-oriented services and guidance to the enterprise. Leaders should also clearly articulate the lead roles at the mission and business process level that are responsible and accountable for detailing action plans and executing C-SCRM activities. Enterprises should consider that without establishing executive oversight of C-SCRM activities, enterprises are limited in their ability to make risk decisions across the organization about how to effectively secure their product and services.

The C-SCRM governance structures and operational model dictate the authority, responsibility, and decision-making power for C-SCRM and define how C-SCRM processes are accomplished within the enterprise. The best C-SCRM governance and operating model is one that meets the business and functional requirements of the enterprise. For example, an enterprise facing strict budgetary constraints or stiff C-SCRM requirements may consider governance and operational models that centralize the decision-making authority and rely on a C-SCRM PMO to consolidate responsibilities for resource-intensive tasks, such as vendor risk assessments. In contrast, enterprises that have mission and business processes governed with a high degree of autonomy or that possess highly differentiated C-SCRM requirements may opt for decentralized authority, responsibilities, and decision-making power.

In addition to defining C-SCRM governance structures and operating models, Level 1 carries out the activities necessary to frame C-SCRM for the enterprise. C-SCRM framing is the process by which the enterprise makes explicit the assumptions about cybersecurity risks throughout the supply chain (e.g., threats, vulnerabilities, risk impact,²¹ risk likelihood), constraints (e.g., enterprise policies, regulations, resource limitation), appetite and tolerance, and priorities and trade-offs that guide C-SCRM decisions across the enterprise. The risk framing process provides the inputs necessary to establish the C-SCRM strategy that dictates how the enterprise plans to assess, respond to, and monitor cybersecurity risks throughout the supply chain. A high-level implementation plan should also be developed to guide the execution of the enterprise’s C-SCRM strategy. The risk framing process is discussed in further detail in Appendix C.

Informed by the risk framing process and the C-SCRM strategy, Level 1 provides the enterprise’s C-SCRM policy. The C-SCRM policy establishes the C-SCRM program’s purpose, outlines the enterprise’s C-SCRM responsibilities, defines and grants authority to C-SCRM roles across the enterprise, and outlines applicable C-SCRM compliance and enforcement expectations and processes. Appendix C provides example templates for the C-SCRM Strategy and C-SCRM Policy.

Risk assessment activities performed at Level 1 focus on assessing, responding to, and monitoring cybersecurity risks throughout the supply chain. Level 1 risk assessments may be based on the enterprise’s Level 1 Frame step (i.e., assumptions, constraints, appetite, tolerances, priorities, and trade-offs) or may be aggregated enterprise-level assumptions based on risk assessments that are completed across multiple mission and business processes. For example, a Level 1 risk assessment may assess the exposure to threats to enterprise objectives that arise through supply chain products or services. Level 1 risk assessments may also aim to aggregate and recontextualize risk assessments completed at Level 2 to describe risk scenarios against the enterprise’s primary objectives.

Reporting plays an important role in equipping Level 1 decision-makers with the context necessary to make informed decisions on how to manage cybersecurity risks throughout the supply chain. Reporting should focus on enterprise-wide trends and include coverage of the extent to which C-SCRM has been implemented across the enterprise, the effectiveness of C-SCRM, and the conditions related to cybersecurity risks throughout the supply chain. C-SCRM reports should highlight any conditions that require urgent leadership attention and/or action and may benefit from highlighted C-SCRM risk and performance trends over a period of time. Those responsible and accountable for C-SCRM within the enterprise should work with leaders to identify reporting requirements, such as frequency, scope, and format. Reporting should include metrics discussed further in Sec. 3.5.1.

Level 1 activities ultimately provide the overarching context and boundaries within which the enterprise’s mission and business processes manage cybersecurity risks throughout the supply chain. Outputs from Level 1 (e.g., C-SCRM Strategy, C-SCRM Policy, Governance, and Operating Model) are further tailored and refined within Level 2 to fit the context of each mission and business process. Level 1 outputs should also be iteratively informed by and updated as a result of C-SCRM outputs at lower levels.

Note that, in complex enterprises, Level 1 activities may be completed at an enterprise level and at an individual organization level. Enterprise Level 1 activities should shape and guide Organization Level 1 activities.

Additional information can be found in Appendix A of this document and SR-1, SR-3, PM-2, PM-6, PM-7, PM-9, PM-28, PM-29, PM-30, and PM-31 of NIST SP 800-53, Rev. 5.

Level 2 addresses how the enterprise mission and business processes assess, respond to, and monitor cybersecurity risks throughout the supply chain. Level 2 activities are performed in accordance with the C-SCRM strategy and policies provided by Level 1.22 In this level, process-specific C-SCRM strategies, policies, and implementation plans dictate how the enterprise’s C-SCRM goals and requirements are met within each mission and business process. Here, specific C-SCRM program requirements are defined and managed and include cost, schedule, performance, security, and a variety of critical non-functional requirements. These non-functional requirements include concepts such as reliability, dependability, safety, security, and quality.

Level 2 roles include representatives of each mission and business process, such as program managers, research and development, and acquisitions/procurement. Level 2 C-SCRM activities address C-SCRM within the context of the enterprise’s mission and business process. Specific strategies, policies, and procedures should be developed to tailor the C-SCRM implementation to fit the specific requirements of each mission and business process. In order to further develop the high-level Enterprise Strategy and Implementation Plan, different mission areas or business lines within the enterprise may need to generate their own tailored mission and business-level strategy and implementation plan, and they should ensure that C-SCRM execution occurs within the constraints defined by higher-level C-SCRM strategies and in conformance C-SCRM policies. To facilitate the development and execution of Level 2 Strategy and Implementation plans, enterprises may benefit from forming a committee with representation from each mission and business process. Coordination and collaboration between the mission and business processes can help drive risk awareness, identify cybersecurity risks throughout the supply chain, and support the development of an enterprise and C-SCRM architecture. A C-SCRM PMO may also assist in the implementation of C-SCRM at Level 2 through the provision of services (e.g., policy templates, C-SCRM subject matter expert [SME] support).

Many threats to and through the supply chain are addressed at Level 2 in the management of third-party relationships with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Because C-SCRM can both directly and indirectly impact mission processes, understanding, integrating, and coordinating C-SCRM activities at this level are critical. Level 2 activities focus on tailoring and applying the enterprise’s C-SCRM frame to fit the specific mission and business process threats, vulnerabilities, impacts,²³ and likelihoods. Informed by outputs from Level 1 (e.g., C-SCRM strategy), mission and business processes will adopt a C-SCRM strategy that tailors the enterprise’s overall strategy to a specific mission and business process. At Level 2, the enterprise may also issue mission and business process-specific policies that contextualize the enterprise’s policy for the process.

In accordance with the C-SCRM strategy, enterprise leaders for specific mission and business processes should develop and execute a C-SCRM implementation plan. The C-SCRM implementation plan provides a more detailed roadmap for operationalizing the C-SCRM strategy within the mission and business process. Within the C-SCRM implementation plans, the mission and business process will specify C-SCRM roles, responsibilities, implementation milestones, dates, and processes for monitoring and reporting. Appendix D of this document provides example templates for the C-SCRM Strategy, Implementation Plan, and the C-SCRM Policy.

C-SCRM activities performed at Level 2 focus on assessing, responding to, and monitoring risk exposure arising from the mission and business process dependencies on suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Risk exposures to the supply chain may occur as a result of primary dependencies on the supply chain or secondary dependencies on individual information systems or other mission and business processes. For example, risk exposure may arise due to a supplier providing critical system components or services to multiple information systems on which critical processes depend. Risk may also arise from vendor-sourced products and services unrelated to information systems, as well as the roles that these products and services play in the overall mission and business process objectives. Enterprises should consider non-traditional sources of cybersecurity risks throughout the supply chain. These risks may circumvent or escape C-SCRM processes, such as those arising from the use of open source software. Enterprises should establish policies and controls to manage non-traditional cybersecurity risks throughout the supply chain.

Reporting at Level 2 plays an important role in equipping mission and business process leaders with the context necessary to manage C-SCRM within the scope of their mission and business processes. Topics covered at Level 2 will reflect those covered at Level 1 but should be reshaped to focus on the specific mission and business process that they correspond to. Level 2 reporting should include metrics that demonstrate the mission and business process performance in contrast to the enterprise-defined risk appetite and risk tolerance statements defined at Level 1 and Level 2. Reporting requirements should be defined to fit the needs of leaders in mission and business processes and at Level 1.

Outputs from Level 2 activities will significantly impact how C-SCRM activities are carried out at Level 3. For example, risk tolerance and common control baseline decisions may be defined at Level 2 then tailored and applied within the context of individual information systems at Level 3. Level 2 outputs should also be used to iteratively influence and further refine Level 1 outputs.

Additional information can be found in Appendix A of this document and SR-1, SR-3, SR-6, PM-2, PM-6, PM-7, PM-30, PM-31, and PM-32 of NIST SP 800-53, Rev. 5.

Level 3 is comprised of personnel responsible and accountable for operational activities, including conducting procurements and executing system-related C-SCRM activities as part of the enterprise’s SDLC, which includes research and development, design, manufacturing, delivery, integration, operations and maintenance, and the disposal/retirement of systems. These personnel include system owners, contracting officers, contracting officer representatives, architects, system engineers, information security specialists, system integrators, and developers. These personnel are responsible for developing C-SCRM plans that address the management, implementation assurance, and monitoring of C-SCRM controls (to include those applicable to external parties, such as contractors) and the acquisition, development, and sustainment of systems and components across the SDLC to support mission and business processes. In enterprises where a C-SCRM PMO has been established, activities such as product risk assessments may be provided as a centralized, shared service.

Within Level 3, outputs provided by C-SCRM activities completed at Level 1 and Level 2 prepare the enterprise to execute C-SCRM at the operational level in accordance with the RMF [SP80037]. C-SCRM is applied to information systems through the development and implementation of C-SCRM plans. These plans are heavily influenced by assumptions, constraints, risk appetite and tolerance, priorities, and trade-offs defined by Level 1 and Level 2. C-SCRM plans dictate how C-SCRM activities are integrated into all systems in the SDLC: acquisition (both custom and off-the-shelf), requirements, architectural design, development, delivery, installation, integration, maintenance, and disposal/retirement. In general, C-SCRM plans are implementation-specific and provide policy implementation, requirements, constraints, and implications for systems that support mission and business processes.

Level 3 activities focus on managing operational-level risk exposure resulting from any ICT/OT-related products and services provided through the supply chain that are in use by the enterprise or fall within the scope of the systems authorization boundary. Level 3 C-SCRM activities begin with an analysis of the likelihood and impact of potential supply chain cybersecurity threats exploiting an operational-level vulnerability (e.g., in a system or system component). Where applicable, these risk assessments should be informed by risk assessments completed in Level 1 and Level 2. In response to determining risk, enterprises should evaluate alternative courses of action for reducing risk exposure (e.g., accept, avoid, mitigate, share, and/or transfer). Risk response is achieved by selecting, tailoring, implementing, and monitoring C-SCRM controls throughout the SLDC in accordance with the RMF [SP80037]. Selected C-SCRM controls often consist of a combination of inherited common controls from the Level 1 and Level 2 and information system-specific controls at Level 3.

Reporting at Level 3 should focus on the C-SCRM’s implementation, efficiency, effectiveness, and the overall level of exposure to cybersecurity risks in the supply chain for the particular system. System-level reporting should provide system owners with tactical-level insights that enable them to make rapid adjustments and respond to risk conditions. Level 3 reporting should include metrics that demonstrate performance against the enterprise risk appetite statements and risk tolerance statements defined at Levels 1, 2, and 3.

A critical Level 3 activity is the development of the C-SCRM plan. Along with applicable security control information, the C-SCRM plan includes information on the system, its categorization, operational status, related agreements, architecture, critical system personnel, related laws, regulations, policies, and contingency plan. In C-SCRM, continuous hygiene is critical, and the C-SCRM plan is a living document that should be maintained and used as the reference for the continuous monitoring of implemented C-SCRM controls. C-SCRM plans are intended to be referenced regularly and should be reviewed and refreshed periodically. These are not intended to be documents developed to satisfy a compliance requirement. Rather, enterprises should be able to demonstrate how they have historically and continue to effectively employ their plans to shape, align, inform, and take C-SCRM actions and decisions across all three levels.

Information gathered as part of Level 3 C-SCRM activities should iteratively inform C-SCRM activities completed within Level 1 and Level 2 to further refine C-SCRM strategies and implementation plans.

Additional information can be found in Appendix A of this document and SR-1, SR-2, SR-6, PL-2, PM-31, and PM-32 of NIST SP 800-53, Rev. 5.

A variety of operating models (e.g., centralized, decentralized, hybrid) facilitate C-SCRM activities across the enterprise and its mission and business processes. One such model involves concentrating and assigning responsibilities for certain C-SCRM activities to a central PMO. In this model, the C-SCRM PMO acts as a service provider to other mission and business processes. Mission and business processes are then responsible for selecting and requesting services from the C-SCRM PMO as part of their responsibilities to meet the enterprise’s C-SCRM goals and objectives. There are a variety of beneficial services that a PMO may provide:

A C-SCRM PMO typically consists of C-SCRM SMEs who help drive the C-SCRM strategy and implementation across the enterprise and its mission and business processes. A C-SCRM PMO may include or report to a dedicated executive-level official responsible and accountable for overseeing C-SCRM activities across the enterprise. A C-SCRM PMO should consist of dedicated personnel or include matrixed representatives with responsibilities for C-SCRM from several of the enterprise’s processes, including information security, procurement, risk management, engineering, software development, IT, legal, and HR. Regardless of whether a C-SCRM PMO sits at Level 1 or Level 2, it is critical that the C-SCRM PMO include cross-disciplinary representation.

The C-SCRM PMO responsibilities may include providing services to the enterprise’s leaders that help set the tone for how C-SCRM is applied throughout the enterprise. The C-SCRM PMO may provide SME support to guide Level 1 stakeholders through the risk framing process, which includes establishing the enterprise appetite and tolerance for cybersecurity risks throughout the supply chain. In addition, accountable risk executives may delegate the responsibility of drafting the enterprise’s C-SCRM strategy and policy to the PMO. C-SCRM PMOs may also coordinate C-SCRM information-sharing internally or with external entities. Finally, the PMO may conduct C-SCRM-focused executive-level briefings (e.g., to the risk executive function, board of directors) to help Level 1 stakeholders develop an aggregated view of cybersecurity risks throughout the supply chain.

At Level 2, the C-SCRM PMO may develop C-SCRM starter kits that contain a base strategy and a set of policies, procedures, and guidelines that can be further customized within specific mission and business processes. This PMO may also provide SME consulting support to stakeholders within mission and business processes as they create process-specific C-SCRM strategies and develop C-SCRM implementation plans. As part of this responsibility, the C-SCRM PMO may advise on or develop C-SCRM common control baselines within the enterprise mission and business processes. The C-SCRM PMO may also perform C-SCRM risk assessments focused on suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers of both technology- and non-technology-related products and services.

The responsibility of a C-SCRM PMO at Level 1 and Level 2 would ultimately influence C-SCRM activities at the Level 3 operational level. A C-SCRM PMO may advise teams throughout the SDLC on C-SCRM control selection, tailoring, and monitoring. Ultimately a C-SCRM PMO may be responsible for activities that produce C-SCRM outputs across the risk management levels. Centralizing C-SCRM services offers enterprises an opportunity to capitalize on specialized skill sets within a consolidated team that offers high-quality C-SCRM services to the rest of the enterprise. By centralizing risk assessment services, enterprises may achieve a level of standardization not otherwise possible (e.g., in a decentralized model). Enterprises may also realize cost efficiencies in cases where PMO resources are dedicated to C-SCRM activities versus resources in decentralized models that may perform multiple roles in addition to C-SCRM responsibilities.

A C-SCRM PMO model will typically favor larger, more complex enterprises that require the standardization of C-SCRM practices across a disparate set of mission and business processes. Ultimately, enterprises should select a C-SCRM operating model that is applicable and appropriate relative to their available resources and context.

Key Takeaways²⁴

原本PDFの抜粋画像

Business Case for C-SCRM. C-SCRM provides enterprises with a number of benefits, such as an understanding of critical systems, the reduced likelihood of supply chain compromise, operational and enterprise efficiencies, fewer product quality and security issues, and more reliable and trustworthy supplied services.

Cybersecurity Risk in Supply Chains. The potential for harm or compromise arising from a relationship with suppliers, their supply chains, and their supplied products or services materialize when a human or non-human threat successfully exploits a vulnerability tied to a system, product, service, or the supply chain ecosystem.

Multilevel, Multidisciplinary C-SCRM. As described in [SP80039], multilevel risk management is the purposeful execution and continuous improvement of cybersecurity supply chain risk management activities at the enterprise (e.g., CEO, COO), mission and business process (e.g., business management, R&D), and operational (e.g., systems management) levels. Each level contains stakeholders from multiple disciplines (e.g., information security, procurement, enterprise risk management, engineering, software development, IT, legal, HR) that collectively execute and continuously improve C-SCRM.

C-SCRM PMO. A dedicated office known as a C-SCRM PMO may support the enterprise’s C-SCRM activities by providing support products (e.g., policy templates) and services (e.g., vendor risk assessments) to the rest of the enterprise. A C-SCRM PMO may provide support across the three levels and sit at Level 1 or Level 2, depending on the enterprise.

C-SCRM is a Life Cycle Process. C-SCRM activities should be integrated and executed throughout the applicable enterprise life cycle processes (e.g., SDLC). For example, cybersecurity supply chain risks in systems can and do materialize during operations and maintenance phases. Organizations should ensure that appropriate C-SCRM activities are in place to assess, respond to, and monitor cybersecurity supply chain risks on a continuous basis.

To successfully address evolving cybersecurity risks throughout the supply chain, enterprises need to engage multiple internal processes and capabilities, communicate and collaborate across enterprise levels and mission areas, and ensure that all individuals within the enterprise understand their role in managing cybersecurity risks throughout the supply chain. Enterprises need strategies for communicating, determining how best to implement, and monitoring the effectiveness of their supply chain cybersecurity controls and practices. In addition to internally communicating cybersecurity supply chain risk management controls, enterprises should engage with peers to exchange C-SCRM insights. These insights will aid enterprises in continuously evaluating how well they are doing and identify where they need to improve and how to take steps to mature their C-SCRM program. This section addresses the requisite enterprise processes and capabilities in making C-SCRM successful. While this publication has chosen to highlight these critical success factors, this represents a non-exhaustive set of factors that contribute to an enterprise’s successful execution of C-SCRM. Critical success factors are fluid and will evolve over time as the environment and the enterprise’s own capability advances.

Integrating C-SCRM considerations into acquisition activities within every step of the procurement and contract management life cycle process is essential to improving management of cybersecurity risks throughout the supply chain. This life cycle begins with a purchaser identifying a need and includes the processes to plan for and articulate requirements, conduct research to identify and assess viable sources of supply, solicit bids, evaluate offers to ensure conformance with C-SCRM requirements, and assess C-SCRM risks associated with the bidder and the proposed product and/or service. After contract award, ensure that the supplier satisfies the terms and conditions articulated in the contractual agreement and that the products and services conform as expected and required. Monitoring for 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.

Enterprises rely heavily on commercial products and outsourced services to perform operations and fulfill their mission and business objectives. However, it is important to highlight that products and services can also be obtained outside of the procurement process, as is the case with open source software, relying on an in-house provider for shared services, or by repurposing an existing product to satisfy a new need. C-SCRM must also be addressed for these other “acquiring” processes.

In addition to addressing cybersecurity risks throughout the supply chain and performing C-SCRM activities during each phase of the acquisition process, enterprises should develop and execute an acquisition strategy that drives reductions in their overall risk exposure. By applying such strategies, enterprises can reduce cybersecurity risks throughout the supply chain, within specific procurement processes, and for the overall enterprise. Enterprises will aid, direct, and inform efforts to realize targeted risk-reducing outcomes by adopting acquisition policies and processes that integrate C-SCRM into acquisition activities.

Additionally, by adopting C-SCRM controls aligned to an industry-recognized set of standards and guidelines (e.g., NIST 800-53, Rev.5; NIST CSF), the enterprise can ensure holistic coverage of cybersecurity risks throughout the supply chain and corresponding C-SCRM practices. C-SCRM controls may apply to different participants of the supply chain to include the enterprise itself, prime contractors, and subcontractors. Because enterprises heavily rely on prime contractors and their subcontractors to develop, implement, operate and maintain ICT/OT products and services, those controls implemented within the SDLC are likely to flow down to subcontractors. Establishing C-SCRM controls applicable throughout the supply chain and the SDLC will aid the enterprise in establishing a common lexicon and set of expectations with suppliers and sub-suppliers to aid all participants in managing cybersecurity risks throughout the supply chain.

An enterprise’s C-SCRM Strategy and Implementation Plan guides the enterprise toward the achievement of long-term, sustainable reductions in exposure to cybersecurity risks throughout the supply chain. As a core part of the C-SCRM Strategy and Implementation Plan, enterprises should address how this risk is managed throughout the acquisition process.

Cybersecurity risks in the supply chain include those arising from the supplier’s enterprise, products, services, and the supplier’s own suppliers and supply chains. The C-SCRM PMO may be helpful in developing specific strategies and implementation plans for integrating C-SCRM considerations into acquisitions. Acquisition activities relevant to C-SCRM include:

The C-SCRM Strategy and Implementation Plan should address the acquisition security-relevant foundational elements necessary to implement a C-SCRM program. To support the strategy, enterprise leaders should promote the value and importance of C-SCRM within acquisitions and ensure that sufficient, dedicated funding is in place for necessary activities. Doing so will help enterprises ensure responsibility for program or business processes and accountability for progress toward the attainment of results. Enterprises should build sufficient time into acquisition and project activities to ensure that C-SCRM activities can be completed. Enterprises should also assign roles and responsibilities, some of which will be cross-enterprise in nature and team-based, while others will be specific to acquisition processes. Finally, relevant training should be provided to members of the acquisition workforce to ensure that roles and responsibilities are understood and executed in alignment with leader expectations.

The enterprise’s capabilities, resources, operational constraints, and existing portfolio of supplier relationships, contracts, acquired services, and products provide the baseline context necessary to lay out a strategic path that is both realistic and achievable. This baseline starting point also serves as a marker by which performance progress and outcomes can be tracked and assessed.

A critical first step is to ensure that there is a current and accurate inventory of the enterprise’s supplier relationships, contracts, and any products or services those suppliers provide. This information allows for a mapping of these suppliers into strategically relevant groupings as determined by the organization. For example, an assessment of these suppliers might result in groupings of multiple categories (e.g., “strategic/innovative,” “mission-critical,” “sustaining,” or “standard/non-essential”). This segmentation facilitates further analysis and understanding of the exposure to cybersecurity risks throughout the supply chain and helps to focus attention and assign priority to those critical suppliers of the most strategic or operational importance to the enterprise and its mission and business processes. It is useful to identify which products and services require a higher level of confidence in risk mitigation and areas of risk, such as overreliance on a single source of supply. This inventory and mapping also facilitates the selection and tailoring of C-SCRM contract language and evaluation criteria.

Additional information can be found in Appendix A of this document, [NISTIR 8179], and SA-1, SA-2, SA-4, SR-5, SR-13 of NIST SP 800-53, Rev. 5.

When conducting a procurement, enterprises should designate experts from different subject matter areas to participate in the acquisition process as members of the Acquisition Team and/or Integrated Project Team.²⁶ This includes program officials, personnel with technical and security expertise, and representatives from supply and procurement communities. While procurement requirements address and are tailored to a specific purpose and ensuring that compliance mandates are met, contextual factors such as mission criticality, the sensitivity of data, and the operational environment must also be considered to effectively address cybersecurity risk in supply chains.

This contextual basis sets the stage for the Acquisition Team to effectively gauge their tolerance for risk as it pertains to a specific procurement requirement and determine which of the C-SCRM controls described in this document and [SP80053r5] controls are relevant and necessary to consider for specific acquisitions. The program office or requiring official should consult with information security personnel to complete this control selection process and work with their procurement official to incorporate these controls into requirements documents and contracts. Security is a critical factor in procurement decisions. For this reason, when purchasing ICT/OT-related products or services, enterprises should avoid using a “lowest price, technically acceptable” (LPTA) source selection process.

Acquisition policies and processes need to incorporate C-SCRM considerations into each step of the procurement and contract management life cycle management process (i.e., plan procurement, define and develop requirements, perform market analysis, complete procurement, ensure compliance, and monitor performance for changes that affect C-SCRM risk status) as described in [IR7622]. This includes ensuring that cybersecurity risks throughout the supply chain are addressed when making ICT/OT-related charge card purchases.

During the ‘plan procurement’ step, the need for and the criticality of the good or service to be procured needs to be identified, along with a description of the factors driving the determination of the need and level of criticality as this informs how much risk may be tolerated, who should be involved in the planning, and the development of the specific requirements that will need to be satisfied. This activity is typically led by the acquirer mission and business process owner or a designee in collaboration with the procurement official or contracting officer representative.

During the planning phase, the enterprise should develop and define requirements to address cybersecurity risks throughout the supply chain in addition to specifying performance, schedule, and cost objectives. This process is typically initiated by the acquirer mission and business process owner or a designee in collaboration with the procurement official and other members of the C-SCRM team.

With requirements defined, enterprises will typically complete a market analysis for potential suppliers. Market research and analysis activities explore the availability of potential or pre-qualified sources of supply. This step is typically initiated by the acquirer mission and business process owner or a designated representative. Enterprises should use this phase to conduct more robust due diligence research on potential suppliers and/or products in order to generate a supplier risk profile. As part of due diligence, the enterprise may consider the market concentration for the sought-after product or service as a means of identifying interdependencies within the supply chain. The enterprise may also use a request for information (RFIs), sources sought notice (SSNs), and/or due diligence questionnaires for the initial screening and collection of evidence from potential suppliers. Enterprises should not treat the initial C-SCRM due diligence risk assessment as exhaustive. Results of this research can also be helpful in shaping the sourcing approach and refining requirements.

Finally, the enterprise will complete the procurement step by releasing a statement of work (SOW), performance work statement (PWS), or statement of objective (SOO) for the release of a request for proposal (RFP) or request for quotes (RFQ). Any bidders responding to the RFP or RFQ should be evaluated against relevant, critical C-SCRM criteria. The RFP review process should also include any procurement-specific supplier risk assessment. The assessment criteria will be heavily informed by the defined C-SCRM requirements and include coverage over but not limited to information about the enterprise, its security processes, and its security track record. The response review process involves multiple C-SCRM stakeholders, including procurement, the mission and business process owner, appropriate information system owners, and technical experts. Prior to purchase, enterprises should identify and assess the quality of the product or system components, vulnerability(s) authenticity, and other relevant cybersecurity-supply chain risk factors and complete this risk assessment prior to deployment.

Once the contract is executed, the enterprise should monitor for changes that alter its exposure to cybersecurity risks throughout the supply chain. Such changes may include internal enterprise or system changes, supplier operational or structural changes, product updates, and geopolitical or environmental changes. Contracts should include provisions that provide grounds for termination in cases where there are changes to cybersecurity supply chain risk that cannot be adequately mitigated to within acceptable levels. Finally, enterprises should continuously apply lessons learned and collected during the acquisition process to enhance their ability to assess, respond to, and monitor cybersecurity risks throughout the supply chain.

In addition to process activities, there are many useful acquisition security-enhancing tools and techniques available, including obscuring the system end use or system component, using blind or filtered buys, requiring tamper-evident packaging, or using trusted or controlled distribution. The results of a supply chain cybersecurity risk assessment can guide and inform the strategies, tools, and methods that are most applicable to the situation. Tools, techniques, and practices may provide protections against unauthorized production, theft, tampering, insertion of counterfeits, insertion of malicious software or backdoors, and poor development practices throughout the system development life cycle.

To ensure the effective and continued management of cybersecurity risks across the supply chain and throughout the acquisition life cycle, contractual agreements and contract management should include:

There are a variety of acceptable validation and revalidation methods, such as requisite certifications, site visits, third-party assessments, or self-attestation. The type and rigor of the required methods should be commensurate with the criticality of the service or product being acquired and the corresponding assurance requirements.

Additional guidance for integrating C-SCRM into the acquisition process is provided in Appendix C, which demonstrates the enhanced overlay of C-SCRM into the [SP80039] Risk Management Process. In addition, enterprises should refer to and follow the acquisition and procurement policies, regulations, and best practices that are specific to their domain (e.g., critical infrastructure sector, state government).

Additional information can be found in Appendix A of this document and SA-1, SA-2, SA-3, SA-4, SA-9, SA-19, SA-20, SA-22, SR-5, SR-6, SR-10, and SR-11 of NIST SP 800-53, Rev. 5.

Enterprises are continuously exposed to risk originating from their supply chains. An effective information-sharing process helps to ensure that enterprises can gain access to information that is critical to understanding and mitigating cybersecurity risks throughout the supply chain and also share relevant information with others that may benefit from or require awareness of these risks.

To aid in identifying, assessing, monitoring, and responding to cybersecurity risks throughout the supply chain, enterprises should build information-sharing processes and activities into their C-SCRM programs. This may include establishing information-sharing agreements with peer enterprises, business partners, and suppliers. By exchanging Supply Chain Risk Information (SCRI) within a sharing community, enterprises can leverage the collective knowledge, experience, and capabilities of that sharing community to gain a more complete understanding of the threats that the enterprise may face. Additionally, the sharing of SCRI allows enterprises to better detect campaigns that target specific industry sectors and institutions. However, the enterprise should be sure that information sharing occurs through formal sharing structures, such as Information Sharing and Analysis Centers (ISACs). Informal or unmanaged information sharing can expose enterprises to potential legal risks.

Federal enterprises should establish processes to effectively engage with the FASC’s information-sharing agency, which is responsible for facilitating information sharing among government agencies and acting as a central, government-wide facilitator for C-SCRM information-sharing activities.

NIST SP 800-150 describes key practices for establishing and participating in SCRI-sharing relationships, including:

As shown in Table 2, below, SCRI describes or identifies the cybersecurity supply chain relevant characteristics and risk factors associated with a product, service, or source of supply. It may exist in various forms (e.g., raw data, a supply chain network map, risk assessment report) and should be accompanied by the metadata that will facilitate an assessment of a level of confidence in and credibility of the information. Enterprises should follow established processes and procedures that describe whether and when the sharing or reporting of certain information is mandated or voluntary and if there are any necessary requirements to adhere to regarding information handling, protection, and classification.

Table 2. Supply chain characteristics and cybersecurity risk factors associated with a product, service, or source of supply²⁸

Numerous individuals within the enterprise contribute to the success of C-SCRM. These may include information security, procurement, risk management, engineering, software development, IT, legal, HR, and program managers. Examples of these groups’ contributions include:

Everyone within an enterprise, including the end users of information systems, has a role and shared responsibility in managing cybersecurity risks throughout the supply chain. The enterprise should foster an overall culture of security that includes C-SCRM as an integral part. The enterprise can use a variety of communication methods to foster the culture, of which traditional awareness and role-based training are only one component.

Every individual within an enterprise should receive appropriate training to enable them to understand the importance of C-SCRM to their enterprise, their specific roles and responsibilities, and as it relates to processes and procedures for reporting incidents. This training can be integrated into the overall cybersecurity awareness training. Enterprises should define baseline training requirements at a broad scope within Level 1, and those requirements should be tailored and refined based on the specific context within Level 2 and Level 3.

Those individuals who have more significant roles in managing cybersecurity risks throughout the supply chain should receive tailored C-SCRM training that helps them understand the scope of their responsibilities, the specific processes and procedure implementations for which they are responsible, and the actions to take in the event of an incident, disruption, or another C-SCRM-related event. The enterprises should establish specific role-based training criteria and develop role-specific C-SCRM training to address C-SCRM roles and responsibilities. The enterprise may also consider adding C-SCRM content into preexisting role-based training for some specific roles. Refer to the Awareness and Training controls in Appendix A for more detail.

Enterprises are encouraged to utilize the NIST National Initiative for Cybersecurity Education (NICE) Framework³⁰ as a means of forming a common lexicon for C-SCRM workforce topics. This will aid enterprises in developing training linked to role-specific C-SCRM responsibilities and communicating cybersecurity workforce-related topics. The NICE Framework outlines Categories; Specialty Areas; Work Roles; Knowledge, Skills, and Abilities (KSAs); and Tasks that describe cybersecurity work.

Cybersecurity supply chain risk management builds on existing standardized practices in multiple disciplines and an ever-evolving set of C-SCRM capabilities. C-SCRM Key Practices are meant to specifically emphasize and draw attention to a subset of the C-SCRM practices described throughout this publication. Enterprises should prioritize achieving a base-level of maturity in these key practices prior to advancing on to additional C-SCRM capabilities. Enterprises should tailor their implementation of these practices to what is applicable and appropriate given their unique context (e.g., based on available resources and risk profile). C-SCRM Key Practices are described in NIST standards and guidelines, such as [IR8276], and other applicable national and international standards. C-SCRM Practices include integrating C-SCRM across the enterprise; establishing a formal program; knowing and managing critical products, services, and suppliers; understanding an enterprise’s supply chain; closely collaborating with critical suppliers; including critical suppliers in resilience and improvement activities; assessing and monitoring throughout the supplier relationship; and planning for the full life cycle.

Having foundational practices in place is critical to having an enduring capability to effectively manage cybersecurity supply chain risks. The following are specific examples of the recommended multidisciplinary foundational practices that can be incrementally implemented to improve an enterprise’s ability to develop and execute more advanced C-SCRM practices:

applicable to federal agencies) and purchase card processes. Supervisors and managers should also ensure that their staff aims to build C-SCRM competencies.

Sustaining practices should be used to enhance the efficacy of cybersecurity supply chain risk management. These practices are inclusive of and build upon foundational practices. Enterprises that have broadly standardized and implemented the foundational practices should consider these as the next steps in advancing their cybersecurity supply chain risk management capabilities:

Enhancing practices should be applied by the enterprise with the goal of advancing toward adaptive and predictive C-SCRM capabilities. Enterprises should pursue these practices once sustaining practices have been broadly implemented and standardized across the enterprise:

The guidance and controls contained in this publication are built on existing multidisciplinary practices and are intended to increase the ability of enterprises to strategically manage cybersecurity risks throughout the supply chain over the entire life cycle of systems, products, and services. Refer to Table 3 for a summary of C-SCRM key practices.

Enterprises should actively manage the efficiency and effectiveness of their C-SCRM programs through ongoing measurement of the programs themselves. Enterprises can use several methods to measure and manage the effectiveness of their C-SCRM program:

All methods rely on a variety of data collection, analysis, contextualization, and reporting activities. Collectively, these methods should be used to track and report progress and results that ultimately indicate reductions in risk exposure and improvements in the enterprise’s security outcomes.

C-SCRM performance management provides multiple enterprise and financial benefits. Major benefits include increasing stakeholder accountability for C-SCRM performance; improving the effectiveness of C-SCRM activities; demonstrating compliance with laws, rules, and regulations; providing quantifiable inputs for resource allocation decisions; and cost-avoidance associated with reduced impact from or the likelihood of experiencing a cyber supply chain incident.

Enterprises can use a framework to baseline their C-SCRM capabilities, such as NIST CSF Implementation Tiers, which provide a useful context for an enterprise to track and gauge the increasing rigor and sophistication of their C-SCRM practices. Progression against framework topics is measured using ordinal (i.e., 1-5) scales that illustrate the progression of capabilities across tiers. The following are examples of how C-SCRM capabilities could be gauged by applying NIST CSF Tiers:

Building capabilities begins by establishing a solid programmatic foundation that includes enabling strategies and plans, establishing policies and guidance, investment in training, and dedicating program resources. Once this foundational capability is in place, enterprises can use these progression charts to orient the strategic direction of their programs to target states of C-SCRM capabilities in different areas of the program. Table 3 provides an example C-SCRM implementation model.

Table 3. Example C-SCRM practice implementation model³³

Fig. 8. C-SCRM metrics development process

Enterprises typically rely on information security measures to facilitate decision-making and improve performance and accountability in their information security programs. Enterprises can achieve similar benefits within their C-SCRM programs. Additionally, enterprises should report C-SCRM metrics to the board through the ERM process. Figure 8 illustrates the process for developing metrics, as outlined in [SP80055r1], and includes:

Similar to information security measures, C-SCRM-focused measures can be attained at different levels of an enterprise. Table 4 provides example measurement topics across the three Risk Management levels.

Table 4. Example measurement topics across the risk management levels

Enterprises should validate identified C-SCRM goals and objectives with their targeted stakeholder groups prior to beginning an effort to develop specific measures. When developing C-SCRM measures, enterprises should focus on the stakeholder’s highest priorities and target measures based on data that can be realistically sourced and gathered. Each established measure should have a specified performance target used to gauge whether goals and objectives in relation to that measure are being met. Enterprises should consider the use of measures templates to formalize each measure and serve as a source of reference for all information pertaining to that measure. Finally, enterprises should develop a formal feedback loop with stakeholders to ensure that measures are continually providing the desired insights and remain aligned with the enterprise’s overall strategic objectives for C-SCRM.

To appropriately manage cybersecurity risks throughout the supply chain, enterprises should dedicate funds toward this effort. Identifying resource needs and taking steps to secure adequate, recurring, and dedicated funding are essential and important activities that need to be built into the C-SCRM strategy and implementation planning effort and incorporated into an enterprise’s budgeting, investment review, and funds management processes. Access to adequate resources is a critical, key enabler for the establishment and sustainment of a C-SCRM program capability. Where feasible, enterprises should be encouraged to leverage existing fund sources to improve their C-SCRM posture. The continued availability of dedicated funds will allow enterprises to sustain, expand, and mature their capabilities over time.

Securing and assigning C-SCRM funding is representative of leadership’s commitment to the importance of C-SCRM, its relevance to national and economic security, and ensuring the protection, continuity, and resilience of mission and business processes and assets.

Funding facilitates goal and action-oriented planning. Examining resource needs and allocating funding prompts a budgeting and strategic-planning process. Effective enterprises begin by defining a set of goals and objectives upon which to build a strategic roadmap, laying out the path to achieving them through the assignment and allocation of finite resources. The establishment of dedicated funding tied to C-SCRM objectives sets conditions for accountability of performance and compels responsible staff to be efficient, effective, and adopt a mindset of continuously seeking to improve C-SCRM capabilities and achieve security enhancing outcomes.

Obtaining new or increased funding can be a challenge as resources are often scarce and necessary for many competing purposes. The limited nature of funds forces prioritization. C-SCRM leaders need to first examine what can be accomplished within the constraints of existing resources and be able to articulate, prioritize, and defend their requests for additional resources. For new investment proposals, this requires a reconciliation of planned initiatives against the enterprise’s mission and business objectives. When well-executed, a systematic planning process can tighten the alignment of C-SCRM processes to these objectives.

Many C-SCRM processes can and should be built into existing program and operational activities and may be adequately performed using available funds. However, there may be a need for an influx of one-time resources to establish an initial C-SCRM program capability. For example, this might include the need to hire new personnel with expertise in C-SCRM, acquire contractor support to aid in developing C-SCRM program guidance, or develop content for role-based C-SCRM training. There may also be insufficient resources in place to satisfy all recurring C-SCRM program needs. Existing funds may need to be reallocated toward C-SCRM efforts or new or additional funds requested. Enterprises should also seek out opportunities to leverage shared services whenever practical.

The use of shared services can optimize the use of scarce resources and concentrate capability into centers of excellence that provide cost-efficient access to services, systems, or tools. Enterprises can adopt cost-sharing mechanisms across their lower-level entities that allow cost-efficient access to C-SCRM resources and capabilities. Enterprises that pursue shared-services models for C-SCRM should also be aware of the challenges of such models. Shared services (e.g., C-SCRM PMO) are most effective when the enterprise at large relies on a fairly homogenous set of C-SCRM strategies, policies, and processes. In many instances, the centralized delivery of C-SCRM services requires a robust technology infrastructure. The enterprise’s systems should be able to support process automation and centralized delivery in order to fully realize the benefits of a shared-services model.

Consultation with budget/finance officials is critical to understanding what options may be available and viable in the near term and out-years. These officials can also advise on how best to justify needs, as well as the timeframes and processes for requesting new funds. There are likely different processes to follow for securing recurring funds versus requesting one-time funding. For example, funding for a new information system to support a C-SCRM capability may involve the development of a formal business case presented to an enterprise’s investment review board for approval. Organizations may find it helpful to break out resource needs into ongoing and one-time costs or into cost categories that align with budget formulation, resource decision-making, and the allocation and management of available funds.

It is recommended that the C-SCRM PMO have the lead responsibility of coordinating with mission and business process and budget officials to build out and maintain a multi-year C-SCRM program budget that captures both recurring and non-recurring resource requirements and maps those requirements to available funding and fund sources. To understand the amount of funding required, when, and for what purpose, enterprises should identify and assess which type and level of resources (people or things) are required to implement a C-SCRM program capability and perform required C-SCRM processes on an ongoing basis. The cost associated with each of these identified resource needs would then be captured, accumulated, and reflected in a budget that includes line items for relevant cost categories, such as personnel costs, contracts, training, travel, tools, or systems. This will provide the enterprise with a baseline understanding of what can be accomplished within existing resource levels and where there are gaps in need of being filled. The actual allocation of funds may be centralized in a single C-SCRM budget or dispersed across the enterprise and reflected in individual office or mission and business process-area budgets. Regardless of how funds are actually assigned, a centralized picture of the C-SCRM budget and funds status will provide a valuable source of information that justifies new requests, informs prioritization decisions, and adjusts expectations about certain activities and the duration in which they can be accomplished.

Ensuring that C-SCRM program funding is distinctly articulated within the enterprise’s budget – with performance measures linked to the funding – will drive accountability for results. The visible dedication of funds in budget requests, performance plans, and reports compels leadership attention on C-SCRM processes and the accomplishment of objectives. Budgets must be requested and justified on a periodic basis. This process allows leadership and oversight officials to trace and measure the effectiveness and efficiency of allocated resources. This, in turn, serves as a driving function for program and operational C-SCRM personnel to track and manage their performance.

Key Takeaways³⁴

原本PDFの抜粋画像

C-SCRM in Acquisition. The integration of C-SCRM into acquisition activities is critical to the success of any C-SCRM program. C-SCRM requirements should be embedded throughout the acquisition life cycle. The C-SCRM activities include performing risk assessments of services, suppliers, and products; identifying relevant C-SCRM controls; conducting due diligence; and continuously monitoring suppliers.

Supply Chain Information Sharing. Enterprises will gain access to information critical to understanding and mitigating cybersecurity risks throughout the supply chain by building information-sharing processes and activities into C-SCRM programs. Enterprises should engage with peers, business partners, suppliers, and information-sharing communities (e.g., ISACs) to gain insight into cybersecurity risks throughout the supply chain and learn from the experiences of the community at large.

原本PDFの抜粋画像

C-SCRM Awareness and Training. Enterprises should adopt enterprise-wide and role-based training programs to educate users on the potential impact that cybersecurity risks throughout the supply chain can have on the business and how to adopt best practices for risk mitigation. Robust C-SCRM training is a key enabler for enterprises as they shift toward a C-SCRM-aware culture.

C-SCRM Key Practices. This publication outlines several Foundational, Sustaining, and Enabling C-SCRM practices that enterprises should adopt and tailor to their unique contexts. Enterprises should prioritize reaching a base level of maturity in key practices before focusing on advanced C-SCRM capabilities.

Capability Implementation Measurement and C-SCRM Measures. Enterprises should actively manage the efficiency and effectiveness of their C-SCRM programs. First, enterprises should adopt a C-SCRM framework as the basis for measuring their progress toward C-SCRM objectives. Next, enterprises should create and implement quantitative performance measures and target tolerance that provide a periodic glimpse into the enterprise’s progress through the lens of specific operational objectives.

Dedicated Resources. Where possible and applicable, enterprises should commit dedicated funds to C-SCRM. The benefits of doing so include facilitating strategic and goal-oriented planning, driving accountability of internal stakeholders to execute and mature the C-SCRM practices of the enterprise, and the continuous monitoring of progress by enterprise leadership.

References

[CISAWG3] Cybersecurity and Infrastructure Agency – Working Group 3 (2021) Mitigating ICT Supply Chain Risks with Qualified Bidder and Manufacturer Lists (Arlington, Virginia). Available at https://www.cisa.gov/sites/default/files/publications/ICTSCRMTF_Qualified-Bidders-Lists_508.pdf

[CNSSI4009] Committee on National Security Systems (2015) Committee on National Security Systems (CNSS) Glossary (CNSS, Ft. Meade, Md.), CNSSI 4009-2015. Available at https://www.cnss.gov/CNSS/issuances/Instructions.cfm

[COSO2011] Rittenberg L, Martens F (2012) Enterprise Risk Management: Understanding and Communicating Risk Appetite. (Committee of Sponsoring Organizations of the Treadway Commission), Thought Leadership in ERM. Available at https://www.coso.org/Documents/ERM-Understanding-and-Communicating-Risk-Appetite.pdf

[COSO2020] Martens F, Rittenberg L (2020) Risk Appetite – Critical to Success: Using Risk Appetite To Thrive in a Changing World. (Committee of Sponsoring Organization of the Treadway Commission), Thought Leadership in ERM. Available at https://www.coso.org/Documents/COSO-Guidance-Risk-Appetite-Critical-to-Success.pdf

[DIBA_CE] Bureau of Industry and Security, Office of Technology Evaluation (2010) Defense Industrial Base Assessment: Counterfeit Electronics. (U.S. Department of Commerce, Washington, D.C.). Available at https://www.bis.doc.gov/index.php/documents/technology-evaluation/37-defense-industrial-base-assessment-of-counterfeit-electronics-2010/file

[EO14028] Executive Order 14028 (2021) Improving the Nation’s Cybersecurity. (The White House, Washington, DC), DCPD-202100401, May 12, 2021. https://www.govinfo.gov/app/details/DCPD-202100401

[FASCSA] Federal Acquisition Supply Chain Security Act of 2018 (FASCSA), Title II of the Strengthening and Enhancing Cyber-capabilities by Utilizing Risk Exposure Technology Act (SECURE) Technology Act of 2018, Pub. L. 115-390, 132 Stat. 5173. Available at https://www.congress.gov/115/plaws/publ390/PLAW-115publ390.pdf

Strengthening and Enhancing Cyber-capabilities by Utilizing Risk Exposure Technology Act (SECURE) Technology Act of 2018, Pub. L. 115-390, 132 Stat.

[FedRAMP] General Services Administration (2022) FedRAMP. Available at http://www.fedramp.gov/

[FIPS199] National Institute of Standards and Technology (2004) Standards for Security Categorization of Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

[FIPS200] National Institute of Standards and Technology (2006) Minimum Security Requirements for Federal Information and Information Systems. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 200. https://doi.org/10.6028/NIST.FIPS.200

[FSP] Cyber Risk Institute (2020) Financial Services Cybersecurity Framework Profile Version 1.0. Available at https://cyberriskinstitute.org/the-profile/

[GAO] Government Accountability Office (2020) Information Technology: Federal Agencies Need to Take Urgent Action to Manage Supply Chain Risks. (U.S. Government Accountability Office, Washington D.C.), Report to Congressional Requesters GAO-21-171. Available at https://www.gao.gov/assets/gao-21-171.pdf

[IEC62443_41] International Electrotechnical Commission (2018) IEC 62443-4-1:2018 – Security for industrial automation and control systems – Part4-1: Secure product development lifecycle requirements (IEC, Geneva). Available at https://webstore.iec.ch/publication/33615

[IEEE15288] International Organization for Standardization/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (2015) ISO/IEC/IEEE 15288:2015 — Systems and software engineering — System life cycle processes (ISO, Geneva). Available at https://www.iso.org/standard/63711.html

[IR7622] Boyens JM, Paulsen C, Bartol N, Shankles S, Moorthy R (2012) Notional Supply Chain Risk Management Practices for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 7622. https://doi.org/10.6028/NIST.IR.7622

[IR8179] Paulsen C, Boyens JM, Bartol N, Winkler K (2018) Criticality Analysis Process Model: Prioritizing Systems and Components. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8179. https://doi.org/10.6028/NIST.IR.8179

[IR8276] Boyens J, Paulsen C, Bartol N, Winkler K, Gimbi J (2021) Key Practices in Cyber Supply Chain Risk Management: Observations from Industry. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8276. https://doi.org/10.6028/NIST.IR.8276

[IR8286] Stine KM, Quinn SD, Witte GA, Gardner RK (2020) Integrating Cybersecurity and Enterprise Risk Management (ERM). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal Report (IR) 8286. https://doi.org/10.6028/NIST.IR.8286

[ISO9000] International Organization for Standardization (2015) ISO 9000:2015 — Quality management — Fundamentals and vocabulary (ISO, Geneva). Available at https://www.iso.org/standard/45481.html

[ISO28001] International Organization for Standardization (2007) ISO 28001:2007 — Security management systems for the supply chain — Best practices for implementing supply chain security, assessments and plans — Requirements and guidance (ISO, Geneva). Available at https://www.iso.org/standard/45654.html

[ISOGuide73] International Organization for Standardization (2009) ISO Guide 73:2009 — Risk management — Vocabulary (ISO, Geneva). Available at https://www.iso.org/standard/44651.html

[ISOIEC2382] International Organization for Standardization/International Electrotechnical Commission (2015) ISO/IEC 2382:2015 — Information technology — Vocabulary (ISO, Geneva). Available at https://www.iso.org/standard/63598.html

[ISOIEC20243] International Organization for Standardization/International Electrotechnical Commission (2018) ISO/IEC 20243-1:2018 – Information technology — Open Trusted Technology Provider^TM Standard (O-TTPS) — Mitigating maliciously tainted and counterfeit products Part 1: Requirements and recommendations (ISO, Geneva). Available at https://www.iso.org/standard/74399.html

[ISOIEC27000] International Organization for Standardization/International Electrotechnical Commission (2018) ISO/IEC 27000:2018 – Information technology – Security techniques – Information security management systems – Overview and vocabulary (ISO, Geneva). Available at https://www.iso.org/standard/73906.html

[ISOIEC27002] International Organization for Standardization/International Electrotechnical Commission (2022) ISO/IEC 27002:2022 – Information security, cybersecurity and privacy protection – Information security controls (ISO, Geneva). Available at https://www.iso.org/standard/75652.html

[ISOIEC27036] International Organization for Standardization/International Electrotechnical Commission (2014) ISO/IEC 27036-2:2014 – Information technology – Security techniques – Information security for supplier relationships – Part 2: Requirements (ISO, Geneva). Available at https://www.iso.org/standard/59680.html

[ISOIEC29147] International Organization for Standardization/International Electrotechnical Commission (2018) ISO/IEC 29147:2018 – Information technology – Security techniques – Vulnerability disclosure (ISO, Geneva). Available at https://www.iso.org/standard/72311.html

[ITILSS] Cannon D (2011) ITIL Service Strategy (The Stationary Office, London), 2nd Ed.

[NDIA] National Defense Industrial Association System Assurance Committee (2008) Engineering for System Assurance. (NDIA, Arlington, VA). Available at https://www.ndia.org/-/media/sites/ndia/meetings-and-events/divisions/systems-engineering/sse-committee/systems-assurance-guidebook.ashx

[NISTCSF] National Institute of Standards and Technology (2024) The NIST Cybersecurity Framework (CSF) 2.0. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Cybersecurity White Paper (CSWP) NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29

[NISTSCRM2012] National Institute of Standards and Technology (2012) Summary of the Workshop on Information and Communication Technologies Supply Chain Risk Management. Available at https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=913338

[NISTSSDF] National Institute of Standards and Technology (2022) NIST Secure Software Development Framework. Available at https://csrc.nist.gov/projects/ssdf

[NTIASBOM] National Telecommunications and Information Administration, Department of Commerce (2021) The Minimum Elements for a Software Bill of Materials (SBOM). Available at https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf

[OMBA123] Office of Management and Budget (2004) Management’s Responsibility for Internal Control. (The White House, Washington, DC), OMB Circular A-123, December 21, 2004. Available at https://georgewbush-whitehouse.archives.gov/omb/circulars/a123/a123_rev.html

[OMBA130] Office of Management and Budget (2016) Managing Information as a Strategic Resource. (The White House, Washington, DC), OMB Circular A-130, July 28, 2016. Available at https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf

[SAFECode1] Software Assurance Forum for Excellence in Code (2010) Software Integrity Controls: An Assurance-Based Approach to Minimizing Risks in the Software Supply Chain. Available at http://www.safecode.org/publications/SAFECode_Software_Integrity_Controls0610.pdf

[SAFECode2] Software Assurance Forum for Excellence in Code (2009) The Software Supply Chain Integrity Framework: Defining Risks and Responsibilities for Securing Software in the Global Supply Chain. Available at http://www.safecode.org/publication/SAFECode_Supply_Chain0709.pdf

[SP80016] deZafra DE, Pitcher SI, Tressler JD, Ippolito JB (1998) Information Technology Security Training Requirements: a Role- and Performance-Based Model. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-16. https://doi.org/10.6028/NIST.SP.800-16

[SP80030r1] Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk Assessments. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-30, Rev. 1. https://doi.org/10.6028/NIST.SP.800-30r1

[SP80032] Kuhn DR, Hu VC, Polk WT, Chang S-jH (2001) Introduction to Public Key Technology and the Federal PKI Infrastructure. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-32. https://doi.org/10.6028/NIST.SP.800-32

[SP80034r1] Swanson MA, Bowen P, Phillips AW, Gallup D, Lynes D (2010) Contingency Planning Guide for Federal Information Systems. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-34, Rev. 1, Includes updates as of November 11, 2010. https://doi.org/10.6028/NIST.SP.800-34r1

[SP80037] Joint Task Force (2018) Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2. https://doi.org/10.6028/NIST.SP.800-37r2

[SP80039] Joint Task Force Transformation Initiative (2011) Managing Information Security Risk: Organization, Mission, and Information System View. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-39. https://doi.org/10.6028/NIST.SP.800-39

[SP80053r5] Joint Task Force (2020) Security and Privacy Controls for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5

[SP80053Ar5] Joint Task Force (2022) Assessing Security and Privacy Controls in Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A, Rev. 5. https://doi.org/10.6028/NIST.SP.800-53Ar5

[SP80053B] Joint Task Force (2020) Control Baselines for Information Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-53B, Includes updates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53B

[SP80055r1] Chew E, Swanson MA, Stine KM, Bartol N, Brown A, Robinson W (2008) Performance Measurement Guide for Information Security. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-55, Rev. 1. https://doi.org/10.6028/NIST.SP.800-55r1

[SP80060v2] Stine K, Kissel R, Barker W, Lee A, Fahlsing J (2008) Guide for Mapping Types of Information and Information Systems to Security Categories: Appendix. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-60v2r1. https://doi.org/10.6028/NIST.SP.800-60v2r1

[SP80064] Kissel R, Stine KM, Scholl MA, Rossman H, Fahlsing J, Gulick, J (2008) Security Considerations in the System Development Life Cycle. (National Institute of Standards and Technology, Gaithersburg, MD), (Withdrawn) NIST Special Publication (SP) 800-64 Rev. 2. https://doi.org/10.6028/NIST.SP.800-64r2

[SP800100] Bowen P, Hash J, Wilson M (2006) Information Security Handbook: A Guide for Managers. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-100, Includes updates as of March 7, 2007. https://doi.org/10.6028/NIST.SP.800-100

[SP800115] Scarfone KA, Souppaya MP, Cody A, Orebaugh AD (2008) Technical Guide to Information Security Testing and Assessment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-115. https://doi.org/10.6028/NIST.SP.800-115

[SP800160v1r1] Ross RS, McEvilley M, Winstead M (2022) Systems Security Engineering:

Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. (National Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP) 800-160, Vol. 1, Rev. 1. https://doi.org/10.6028/NIST.SP.800-160v1r1

[SP800160v2r1] Ross RS, Pillitteri VY, Graubart R, Bodeau D, McQuaid R (2021) Developing Cyber Resilient Systems: A Systems Security Engineering Approach. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-160, Vol. 2, Rev. 1. https://doi.org/10.6028/NIST.SP.800-160v2r1

[SP800171r3] Ross RS, Pillitteri VY (2024) Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-171, Rev. 3. https://doi.org/10.6028/NIST.SP.800-171r3

[SP800172] Ross RS, Pillitteri VY, Guissanie G, Wagner R, Graubart R, Bodeau D (2021) Enhanced Security Requirements for Protecting Controlled Unclassified Information: A Supplement to NIST Special Publication 800-171. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-172. https://doi.org/10.6028/NIST.SP.800-172

[SP800181r1] Petersen R, Santos D, Wetzel KA, Smith MC, Witte GA (2020 Workforce Framework for Cybersecurity (NICE Framework). (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-181, Rev. 1. https://doi.org/10.6028/NIST.SP.800-181r1

[SwA] Polydys ML, Wisseman S (2008) Software Assurance in Acquisition: Mitigating Risks to the Enterprise. A Reference Guide for Security-Enhanced Software Acquisition and Outsourcing. (National Defense University Press, Washington, D.C.) Information Resources Management College Occasional Paper. Available at https://apps.dtic.mil/dtic/tr/fulltext/u2/a495389.pdf

A.1. C-SCRM Controls Introduction

NIST defines security controls as:

The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. [FIPS199]

[SP80053r5] defines numerous cybersecurity supply chain-related controls within the catalog of information security controls. This section is structured as an enhanced overlay of [SP80053r5]. It identifies and augments C-SCRM-related controls with additional supplemental guidance and provides new controls as appropriate. The C-SCRM controls are organized into the 20 control families of [SP80053r5]. This approach facilitates use of the security controls assessment techniques articulated in [SP80053Ar5] to assess implementation of C-SCRM controls.

The controls provided in this publication are intended for enterprises to implement internally and to require of their contractors and subcontractors if and when applicable and as articulated in a contractual agreement. As with [SP80053r5], the security controls and control enhancements are a starting point from which controls/enhancements may be removed, added, or specialized based on an enterprise’s needs. Each control in this section is listed for its applicability to C-SCRM. Those controls from [SP80053r5] not listed are not considered directly applicable to C-SCRM and, thus, are not included in this publication. Details and supplemental guidance for the various C-SCRM controls in this publication are contained in Sec. A.2.

A.1.1. C-SCRM Controls Summary

During the Respond step of the risk management process articulated in Sec. 2, enterprises select, tailor, and implement controls for mitigating cybersecurity risks throughout the supply chain. [SP80053B] lists a set of information security controls at the [FIPS199] high-, moderate-, and low-impact levels. This section describes how these controls help mitigate risk to information systems and components, as well as the supply chain infrastructure. The section provides 20 C-SCRM control families that include relevant controls and supplemental guidance.

Figure 9 depicts the process used to identify, refine, and add C-SCRM supplemental guidance to the [SP80053r5] C-SCRM-related controls and represents the following steps:

Fig. 9. C-SCRM security controls in SP 800-161, Rev. 1

Note that [SP80053r5] provides C-SCRM-related controls and control families. These controls may be listed in this publication with a summary or additional guidance and a reference to the original [SP80053r5] control and supplemental guidance detail.

As noted in Table 5, C-SCRM controls in this publication are designated by the three levels comprising the enterprise. This is to facilitate the selection of C-SCRM controls specific to enterprises, their various missions, and individual systems, as described in Appendix C under the Respond step of the risk management process. During controls selection, enterprises should use the C-SCRM controls in this section to identify appropriate C-SCRM controls for tailoring per risk assessment. By selecting and implementing applicable C-SCRM controls for each level, enterprises will ensure that they have appropriately addressed C-SCRM.

Acquirers may use C-SCRM controls as the basis from which to communicate their C-SCRM requirements to different types of enterprises that provide products and services to acquirers, including suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Acquirers should avoid using generalized requirements statements, such as “ensure compliance with NIST SP 800-161, Rev. 1 controls.” Acquirers must be careful to select the controls relevant to the specific use case of the service or product being acquired. Acquirers are encouraged to integrate C-SCRM throughout their acquisition activities. More detail on the role of C-SCRM in acquisition is provided in Sec. 3.1 of this document.

It is important to recognize that the controls in this section do not provide specific contracting language. Acquirers should use this publication as guidance to develop their own contracting language with specific C-SCRM requirements for inclusion. The following sections expand upon the supplier, developer, system integrator, external system service provider, and other ICT/OT-related service provider roles with respect to C-SCRM expectations for acquirers.

Enterprises may use multiple techniques to ascertain whether these controls are in place, such as supplier self-assessment, acquirer review, or third-party assessments for measurement and adherence to the enterprise’s requirements. Enterprises should first look to established third-party assessments to see if they meet their needs. When an enterprise defines C-SCRM requirements, it may discover that established third-party assessments may not address all specific requirements. In this case, additional evidence may be needed to justify unaddressed requirements. Please note that the data obtained for this purpose should be appropriately protected.

Suppliers

Suppliers may provide either commercial off-the-shelf (COTS) or, in federal contexts, government off-the-shelf (GOTS) solutions to the acquirer. COTS solutions include non-developmental items (NDI), such as commercially-licensed solutions/products. GOTS solutions are government-only licensable solutions. Suppliers are a diverse group that ranges from very small to large, specialized to diversified, and based in a single country to transnational. Suppliers also range widely in their level of sophistication, resources, and transparency/visibility into their processes and solutions.

Suppliers have diverse levels and types of C-SCRM practices in place. These practices and other related practices may provide the requisite evidence for SCRM evaluation. An example of a federal resource that may be leveraged is the Defense Microelectronics Activity (DMEA) accreditation for trusted suppliers. When appropriate, allow suppliers the opportunity to reuse any existing data and documentation that may provide evidence of C-SCRM implementation.

Enterprises should consider whether the cost of doing business with suppliers may be directly impacted by the extent of supply chain cybersecurity requirements imposed on suppliers, the willingness or ability of suppliers to allow visibility into how their products are developed or manufactured, and how they apply security and supply chain practices to their solutions. When enterprises or system integrators require greater levels of transparency from suppliers, they must consider the possible cost implications of such requirements. Suppliers may opt not to participate in procurements to avoid increased costs or perceived risks to their intellectual property, limiting an enterprise’s supply or technology choices. Additionally, suppliers may face risks from customers imposing multiple and different sets of supply chain cybersecurity requirements with which the supplier must comply on a per-customer basis. The amount of transparency required from suppliers should be commensurate to the suppliers’ criticality, which is sufficient to address inherent risk.

Developers and Manufacturers

Developers and manufactures are personnel that develop or manufacture systems, system components (e.g., software), or system services (e.g., Application Programming Interfaces [APIs]). Development can occur internally within enterprises or through external entities. Developers typically maintain privileged access rights and play an essential role throughout the SDLC. The activities they perform and the work they produce can either enhance security or introduce new vulnerabilities. It is, therefore, essential that developers are both subject to and intimately familiar with C-SCRM requirements and controls.

System Integrators

System integrators provide customized services to the acquirer, including custom development, test, operations, and maintenance. This group usually replies to a request for proposal from an acquirer with a solution or service that is customized to the acquirer’s requirements. Such proposals provided by system integrators can include many layers of suppliers and teaming arrangements with other vendors or subcontractors. The system integrator should ensure that these business entities are vetted and verified with respect to the acquirer’s C-SCRM requirements. Because of the level of visibility that can be obtained in the relationship with the system integrator, the acquirer has the discretion to require rigorous supplier acceptance criteria and any relevant countermeasures to address identified or potential risks.

External System Service Providers of Information System Services

Enterprises use external service providers to perform or support some of their mission and business functions [SP80053r5]. The outsourcing of systems and services creates a set of cybersecurity supply chain concerns that reduces the acquirer’s visibility into and control of the outsourced functions. Therefore, it requires increased rigor from enterprises in defining C-SCRM requirements, stating them in procurement agreements, monitoring delivered services, and evaluating them for compliance with the stated requirements. Regardless of who performs the services, the acquirer is ultimately responsible and accountable for the risk to the enterprise’s systems and data that result from the use of these services. Enterprises should implement a set of compensating C-SCRM controls to address this risk and work with the mission and business process owner or risk executive to accept this risk. A variety of methods may be used to communicate and subsequently verify and monitor C-SCRM requirements through such vehicles as contracts, interagency agreements, lines of business arrangements, licensing agreements, and/or supply chain transactions.

Other ICT/OT-Related Service Providers

Providers of services can perform a wide range of different functions, ranging from consulting to publishing website content to janitorial services. Other ICT/OT-related service providers encompass those providers that require physical or logical access to ICT/OT or the use technology (e.g., an aerial photographer using a drone to take video/pictures or a security firm remotely monitoring a facility using cloud-based video surveillance) as a means of delivering their service. As a result of service provider access or use, the potential for cyber supply chain risk being introduced to the enterprise rises.

Operational technology possesses unique operational and security characteristics that necessitate the application of specialized skills and capabilities to effectively protect them. Enterprises that have significant OT components throughout their enterprise architecture often turn to specialized service providers for the secure implementation and maintenance of these devices, systems, or equipment. Any enterprise or individual providing services that may include authorized access to an ICT or OT system should adhere to enterprise C-SCRM requirements. Enterprises should apply special scrutiny to ICT/OT-related service providers managing mission-critical and/or safety-relevant assets.

A.1.2. Selecting, Tailoring, and Implementing C-SCRM Security Controls

The C-SCRM controls defined in this section should be selected and tailored according to individual enterprise needs and environments using the guidance in [SP80053r5] in order to ensure a cost-effective, risk-based approach to providing enterprise-wide C-SCRM. The C-SCRM baseline defined in this publication addresses the basic needs of a broad and diverse set of constituents. Enterprises must select, tailor, and implement the security controls based on: (i) the environments in which enterprise information systems are acquired and operate; (ii) the nature of operations conducted by enterprises; (iii) the types of threats facing enterprises, mission and business processes, supply chains, and information systems; and (iv) the type of information processed, stored, or transmitted by information systems and the supply chain infrastructure.

After selecting the initial set of security controls, the acquirer should initiate the tailoring process according to NIST SP 800-53B, Control Baselines for Information Systems and Organization, in order to appropriately modify and more closely align the selected controls with the specific conditions within the enterprise. The tailoring should be coordinated with and approved by the appropriate enterprise officials (e.g., authorizing officials, authorizing official designated representatives, risk executive [function], chief information officers, or senior information security officers) prior to implementing the C-SCRM controls. Additionally, enterprises have the flexibility to perform the tailoring process at the enterprise level (either as the required tailored baseline or as the starting point for policy-, program-, or system-specific tailoring) in support of a specific program at the individual information system level or using a combination of enterprise-level, program/mission-level, and system-specific approaches.

Selection and tailoring decisions, including the specific rationale for those decisions, should be included within the C-SCRM documentation at Levels 1, 2, and 3 and Appendix C and approved by the appropriate enterprise officials as part of the C-SCRM plan approval process.

Table 5 shows the format used in this publication for controls providing supplemental C-SCRM guidance on existing [SP80053r5] controls or control enhancements.

C-SCRM controls that do not have a parent [SP80053r5] control generally follow the format described in [SP80053r5] with the addition of relevant levels. New controls are given identifiers consistent with [SP80053r5] but do not duplicate existing control identifiers.

Table 5. C-SCRM control format

CONTROL CONTROL NAME IDENTIFIER

Supplemental C-SCRM Guidance:

Level(s): Related Control(s): Control Enhancement(s): CONTROL NAME | CONTROL ENHANCEMENT NAME

(1)

Supplemental C-SCRM Guidance: Level(s): Related Control(s):

An example of the C-SCRM control format is shown below using C-SCRM Control AC-3 and SCRM Control Enhancement AC-3(8):

AC-3 ACCESS ENFORCEMENT

Supplemental C-SCRM Guidance: Ensure that the information systems and the supply chain have appropriate access enforcement mechanisms in place. This includes both physical and logical access enforcement mechanisms, which likely work in coordination for supply chain needs. Enterprises should ensure a detailed definition of access enforcement.

Level(s): 2, 3

Related Control(s): AC-4

Control Enhancement(s):

(8) ACCESS ENFORCEMENT | REVOCATION OF ACCESS AUTHORIZATIONS

Supplemental C-SCRM Guidance: Prompt revocation is critical to ensure that suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers who no longer require access or who abuse or violate their access privilege are not able to access an enterprise’s system. For example, in a “badge flipping” situation, a contract is transferred from one system integrator enterprise to another with the same personnel supporting the contract. In that situation, the enterprise should disable the existing accounts, retire the old credentials, establish new accounts, and issue completely new credentials.

Level(s): 2, 3

The remainder of Appendix A provides the enhanced C-SCRM overlay of SP 800-53, Rev. 5. This section displays the relationship between SP 800-53, Rev. 5 controls and C-SCRM controls in one of the following ways:

The following new controls and control enhancement have been added:

A.2. C-SCRM Security Controls

[FIPS200] specifies the Access Control minimum security requirement as follows:

Organizations must limit information system access to authorized users, processes acting on behalf of authorized users, devices (including other information systems), and the types of transactions and functions that authorized users are permitted to exercise.

原本PDFの抜粋画像

Systems and components that traverse the supply chain are subject to access by a variety of individuals and enterprises, including suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Such access should be defined and managed to ensure that it does not inadvertently result in the unauthorized release, modification, or destruction of information. This access should be limited to only the necessary type, duration, and level of access for authorized enterprises (and authorized individuals and authorized assets within those enterprises) and monitored for cybersecurity supply chain impact.

Supplemental C-SCRM Guidance: Enterprises should specify and include in agreements (e.g., contracting language) access control policies for their suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers that have access control policies. These should include both physical and logical access to the supply chain and the information system. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.

Level(s): 1, 2, 3

Supplemental C-SCRM Guidance: Use of this control helps establish traceability of actions and actors in the supply chain. This control also helps ensure access authorizations of actors in the supply chain are appropriate on a continuous basis. The enterprise may choose to define a set of roles and associate a level of authorization to ensure proper implementation. Enterprises must utilize unique accounts for contractor personnel and ensure that accounts for contractor personnel do not exceed the period of performance of the contract. Privileged accounts should only be established for appropriately vetted contractor personnel. Enterprises should also have processes in place to establish and manage temporary or emergency accounts for contractor personnel that require access to a mission-critical or mission-enabling system during a continuity or emergency event. For example, during a pandemic event, existing contractor personnel who are not able to work due to illness may need to be temporarily backfilled by new contractor staff. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors. Departments and agencies should refer to Appendix F to implement this guidance in accordance with Executive Order 14028, Improving the Nation’s Cybersecurity.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Ensure that the information systems and the supply chain have appropriate access enforcement mechanisms in place. This includes both physical and logical access enforcement mechanisms, which likely work in coordination for supply chain needs. Enterprises should ensure that a defined consequence framework is in place to address access control violations. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors. Departments and agencies should refer to Appendix F to implement this guidance in accordance with Executive Order 14028, Improving the Nation’s Cybersecurity.

Level(s): 2, 3

Control Enhancement(s):

Supplemental C-SCRM Guidance: Prompt revocation is critical to ensure that suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers who no longer require access or who abuse or violate their access privilege are not able to access an enterprise’s system. Enterprises should include in their agreements a requirement for contractors and sub-tier contractors to immediately return access credentials (e.g., tokens, PIV or CAC cards, etc.) to the enterprise. Enterprises must also have processes in place to promptly process the revocation of access authorizations. For example, in a “badge flipping” situation, a contract is transferred from one system integrator enterprise to another with the same personnel supporting the contract. In that situation, the enterprise should disable the existing accounts, retire the old credentials, establish new accounts, and issue completely new credentials.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Information about the supply chain should be controlled for release between the enterprise and third parties. Information may be exchanged between the enterprise and its suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. The controlled release of enterprise information protects against risks associated with disclosure.

Level(s): 2, 3

Supplemental C- SCRM Guidance: Supply chain information may traverse a large supply chain to a broad set of stakeholders, including the enterprise and its various federal stakeholders, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Specifying the requirements and how information flow is enforced should ensure that only the required information is communicated to various participants in the supply chain. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors. Departments and agencies should refer to Appendix F to implement this guidance in accordance with Executive Order 14028, Improving the Nation’s Cybersecurity.

Level(s): 2, 3

Control Enhancement(s):

Supplemental C-SCRM Guidance: The metadata relevant to C-SCRM is extensive and includes activities within the SDLC. For example, information about systems and system components, acquisition details, and delivery is considered metadata and may require appropriate protections. Enterprises should identify what metadata is directly relevant to their supply chain security and ensure that information flow enforcement is implemented in order to protect applicable metadata.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Within the C-SCRM context, enterprises should specify various source and destination points for information about the supply chain and information that flows through the supply chain. This is so that enterprises have visibility of information flow within the supply chain.

Level(s): 2, 3

Supplemental C-SCRM Guidance: For C-SCRM, the validation of data and the relationship to its metadata are critical. Much of the data transmitted through the supply chain is validated with the verification of the associated metadata that is bound to it. Ensure that proper filtering and inspection is put in place for validation before allowing payloads into the supply chain.

Level(s): 2, 3

Supplemental C-SCRM Guidance: The enterprise should ensure the separation of the information system and supply chain information³⁶ flow. Various mechanisms can be implemented, such as encryption methods (e.g., digital signing). Addressing information flow between the enterprise and its suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers may be challenging, especially when leveraging public networks.

Level(s): 3

Supplemental C-SCRM Guidance: The enterprise should ensure that an appropriate separation of duties is established for decisions that require the acquisition of both information system and supply chain components. The separation of duties helps to ensure that adequate protections are in place for components entering the enterprise’s supply chain, such as denying developers the privilege to promote code that they wrote from development to production environments. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors. Departments and agencies should refer to Appendix F to implement this guidance in accordance with Executive Order 14028, Improving the Nation’s Cybersecurity.

Level(s): 2, 3

Supplemental C-SCRM Guidance: For C-SCRM supplemental guidance, see control enhancements. Departments and agencies should refer to Appendix F to implement this guidance in accordance with Executive Order 14028, Improving the Nation’s Cybersecurity.

Control Enhancement(s):

Supplemental C-SCRM Guidance: Enterprises should ensure that protections are in place to prevent non-enterprise users from having privileged access to enterprise supply chain and related supply chain information. When enterprise users include independent consultants, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers, relevant access requirements may need to use least privilege mechanisms to precisely define what information and/or components are accessible, for what duration, at what frequency, using what access methods, and by whom. Understanding what components are critical and non-critical can aid in understanding the level of detail that may need to be defined regarding least privilege access for non-enterprise users.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Ever more frequently, supply chains are accessed remotely. Whether for the purpose of development, maintenance, or the operation of information systems, enterprises should implement secure remote access mechanisms and allow remote access only to vetted personnel. Remote access to an enterprise’s supply chain (including distributed software development environments) should be limited to the enterprise or contractor personnel and only if and as required to perform their tasks. Remote access requirements – such using a secure remote access solution, employing multi-factor authentication, limiting access to specified business hours, limit access to specific assets (not networks) based on role and from specified geographic locations – must be properly defined in agreements. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors. Departments and agencies should refer to Appendix F to implement this guidance in accordance with Executive Order 14028, Improving the Nation’s Cybersecurity.

Level(s): 2, 3

Control Enhancement(s):

Supplemental C-SCRM Guidance: Enterprises should ensure that detailed requirements are properly defined and that access to information regarding the information system and supply chain is protected from unauthorized use and disclosure. Since supply chain data and metadata disclosure or access can have significant implications for an enterprise’s mission processes, appropriate measures must be taken to vet both the supply chain and personnel processes to ensure that adequate protections are implemented. Ensure that remote access to such information is included in requirements.

Level(s): 2, 3

Supplemental C-SCRM Guidance: An enterprise’s supply chain may include wireless infrastructure that supports supply chain logistics (e.g., radio-frequency identification device [RFID] support, software call home features). Supply chain systems/components traverse the supply chain as they are moved from one location to another, whether within the enterprise’s own environment or during delivery from system integrators or suppliers. Ensuring that appropriate and secure access mechanisms are in place within this supply chain enables the protection of the information systems and components, as well as logistics technologies and metadata used during shipping (e.g., within tracking sensors). The enterprise should explicitly define appropriate wireless access control mechanisms for the supply chain in policy and implement appropriate mechanisms.

Level(s): 1, 2, 3

Supplemental C-SCRM Guidance: The use of mobile devices (e.g., laptops, tablets, e-readers, smartphones, smartwatches) has become common in the supply chain. They are used in direct support of an enterprise’s operations, as well as tracking, supply chain logistics, data as information systems, and components that traverse enterprise or systems integrator supply chains. Ensure that access control mechanisms are clearly defined and implemented where relevant when managing enterprise supply chain components. An example of such an implementation includes access control mechanisms implemented for use with remote handheld units in RFID for tracking components that traverse the supply chain. Access control mechanisms should also be implemented on any associated data and metadata tied to the devices.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Enterprises’ external information systems include those of suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Unlike in an acquirer’s internal enterprise where direct and continuous monitoring is possible, in the external supplier relationship, information may be shared on an as-needed basis and should be articulated in an agreement. Access to the supply chain from such external information systems should be monitored and audited. Enterprises should require their prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors.

Level(s): 1, 2, 3

Control Enhancement(s):

Supplemental C-SCRM Guidance: This enhancement helps limit exposure of the supply chain to the systems of suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Devices that do not belong to the enterprise (e.g., bring your own device [BYOD] policies) increase the enterprise’s exposure to cybersecurity risks throughout the supply chain. This includes devices used by suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers. Enterprises should review the use of non-enterprise devices by non-enterprise personnel and make a risk-based decision as to whether it will allow the use of such devices or furnish devices. Enterprises should furnish devices to those non-enterprise personnel who present unacceptable levels of risk.

Level(s): 2, 3

Supplemental C-SCRM Guidance: Sharing information within the supply chain can help manage cybersecurity risks throughout the supply chain. This information may include vulnerabilities, threats, the criticality of systems and components, or delivery information. This information sharing should be carefully managed to ensure that the information is only accessible to authorized individuals within the enterprise’s supply chain. Enterprises should clearly define boundaries for information sharing with respect to temporal, informational, contractual, security, access, system, and other requirements. Enterprises should monitor and review for unintentional or intentional information sharing within its supply chain activities, including information sharing with suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers.

Level(s): 1, 2

Supplemental C-SCRM Guidance: Within the C-SCRM context, publicly accessible content may include Requests for Information, Requests for Proposal, or information about delivery of systems and components. This information should be reviewed to ensure that only appropriate content is released for public consumption, whether alone or with other information.

Level(s): 2, 3