NIST.SP.800-161.pdf
PDF 4 MB Posted
- Attached to
- Human Capital Management
- Solicitation number
- HHM402-24-Q-0001
- Issued by
-
Defense Intelligence Agency
About this file
This is a solicitation from the Defense Intelligence Agency seeking human capital management services. The solicitation requests proposals for providing professional services to support the agency's human resources programs, including staffing, classification, compensation, benefits, employee relations, and training. Offerors should have experience supporting federal civilian personnel programs. Proposals are due by the specified date in 2024, and the resulting contract will have a one-year base period and four one-year options extending to 2029.
View the file
Other files
Show all 38
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
NIST Special Publication 800-161
Supply Chain Risk Management
Practices for Federal Information
Systems and Organizations
Jon Boyens
Celia Paulsen
Rama Moorthy
Nadya Bartol
This publication is available free of charge from:
http://dx.doi.org/10.6028/NIST.SP.800-161
C O M P U T E R S E C U R I T Y
NIST Special Publication 800-161
Supply Chain Risk Management
Practices for Federal Information
Systems and Organizations
Jon Boyens
Celia Paulsen
Computer Security Division
Information Technology Laboratory
Rama Moorthy
Hatha Systems
Washington, D.C.
Nadya Bartol
Utilities Telecom Council
Washington, D.C.
April 2015
U.S. Department of Commerce Penny Pritzker, Secretary
National Institute of Standards and Technology
Willie May, Acting Under Secretary of Commerce for Standards and Technology and Acting Director
Page ii
Special Publication 800-161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations
Authority
This publication has been developed by National Institute of Standards and Technology (NIST) in accordance with its statutory responsibilities under the Federal Information Security Modernization
Act (FISMA) of 2014, 44 U.S.C. § 3541 et seq., Public Law 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, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular
A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular
A-130, Appendix III, Security of Federal Automated Information Resources.
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.
National Institute of Standards and Technology Special Publication 800-161 Natl. Inst. Stand. Technol. Spec. Publ. 800-161, 282 pages (April 2015)
CODEN: NSPUE2
National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 Email: scrm-nist@nist.gov
Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment 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. All NIST Computer Security Division publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.
Information Systems and Organizations
Page iii
Reports on Computer Systems Technology
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.
Abstract
Federal agencies are concerned about the risks associated with information and communications technology (ICT) products and services that may contain potentially malicious functionality, are counterfeit, or are vulnerable due to poor manufacturing and development practices within the ICT supply chain. These risks are associated with the federal agencies’ decreased visibility into, understanding of, and control over how the technology that they acquire is developed, integrated and deployed, as well as the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products and services.
This publication provides guidance to federal agencies on identifying, assessing, and mitigating ICT supply chain risks at all levels of their organizations. The publication integrates ICT supply chain risk management (SCRM) into federal agency risk management activities by applying a multitiered, SCRM-specific approach, including guidance on assessing supply chain risk and applying mitigation activities.
Keywords
Acquire; Information and Communication Technology Supply Chain Risk Management; ICT SCRM; risk management; supplier; supply chain; supply chain assurance; supply chain risk; supply chain risk assessment; supply chain security
Acknowledgements
The authors, Jon Boyens, National Institute of Standards and Technology (NIST), Celia Paulsen (NIST), Rama Moorthy (Hatha Systems), and Nadya Bartol (Utilities Telecom Council), would like to acknowledge and thank the ICT SCRM community, which has provided the authors invaluable insight and diverse perspectives to managing the ICT supply chain. We would especially like to thank Kelly
Dempsey (NIST), Dr. Ron Ross (NIST), and Stephanie Shankles (Booz Allen Hamilton) for their contribution to the content during the document development and review. We would also like to thank numerous reviewers within the information technology community who took the time to provide valuable feedback and comments to the public drafts. Finally, we would like to thank the participants of NIST’s
October 2012 ICT SCRM Workshop for providing the guiding foundation to the approach this publication has taken.
Page iv
Table of Contents
INTRODUCTION
1.1 PURPOSE
1.2 SCOPE 2
1.3 TARGET AUDIENCE
1.4 BACKGROUND
1.4.1 Federal Agencies ICT Supply Chain
1.4.2 ICT Supply Chain Risk
1.4.3 Federal Agency Relationships with System Integrators, Suppliers, and External Service Providers .. 8
1.5 FOUNDATIONAL PRACTICES
1.6 RELATIONSHIP TO OTHER PROGRAMS AND PUBLICATIONS
1.7 METHODOLOGY FOR BUILDING ICT SCRM GUIDANCE USING SP 800-39 AND NIST SP 800-53 REVISION 4.. 13
1.7.1 Integration into Risk Management Process
1.7.2 Enhanced ICT SCRM Overlay
1.8 ORGANIZATION OF THIS SPECIAL PUBLICATION
INTEGRATION OF ICT SCRM INTO ORGANIZATION-WIDE RISK MANAGEMENT
2.1 MULTITIERED RISK MANAGEMENT
2.1.1 TIER 1 – ORGANIZATION
2.1.2 TIER 2 – MISSION/BUSINESS PROCESS
2.1.3 TIER 3 – INFORMATION SYSTEMS
2.2 ICT SCRM ACTIVITIES IN RISK MANAGEMENT PROCESS
2.2.1 FRAME
2.2.2 ASSESS
2.2.3 RESPOND
2.2.4 MONITOR
ICT SCRM CONTROLS
3.1 ICT SCRM CONTROLS SUMMARY
3.2 ICT SCRM CONTROLS THROUGHOUT THE ORGANIZATION
3.3 APPLYING ICT SCRM CONTROLS TO ACQUIRING ICT PRODUCTS AND SERVICES
3.3.1 System Integrators
3.3.2 Suppliers
3.3.3 External Providers of Information System Services
3.4 SELECTING AND TAILORING IMPLEMENTING ICT SCRM SECURITY CONTROLS
3.4.1 ICT SCRM Control Format
3.4.2 Using ICT SCRM Controls in This Publication
3.5 ICT SCRM SECURITY CONTROLS
FAMILY: ACCESS CONTROL
FAMILY: AWARENESS AND TRAINING
FAMILY: AUDIT AND ACCOUNTABILITY
Page v
FAMILY: SECURITY ASSESSMENT AND AUTHORIZATION
FAMILY: CONFIGURATION MANAGEMENT
FAMILY: CONTINGENCY PLANNING
FAMILY: IDENTIFICATION AND AUTHENTICATION
FAMILY: INCIDENT RESPONSE
FAMILY: MAINTENANCE
FAMILY: MEDIA PROTECTION
FAMILY: PHYSICAL AND ENVIRONMENTAL PROTECTION
FAMILY: PLANNING
FAMILY: PROGRAM MANAGEMENT
FAMILY: PERSONNEL SECURITY
FAMILY: PROVENANCE
FAMILY: RISK ASSESSMENT
FAMILY: SYSTEM AND SERVICES ACQUISITION
FAMILY: SYSTEM AND COMMUNICATIONS PROTECTION
FAMILY: SYSTEM AND INFORMATION INTEGRITY
ICT SCRM CONTROL SUMMARY
NIST SP 800-53 ICT SCRM-RELEVANT CONTROLS
FAMILY: ACCESS CONTROL
FAMILY: AWARENESS AND TRAINING
FAMILY: AUDIT AND ACCOUNTABILITY
FAMILY: SECURITY ASSESSMENT AND AUTHORIZATION
FAMILY: CONFIGURATION MANAGEMENT
FAMILY: CONTINGENCY PLANNING
FAMILY: IDENTIFICATION AND AUTHENTICATION
FAMILY: INCIDENT RESPONSE
FAMILY: MAINTENANCE
FAMILY: MEDIA PROTECTION
FAMILY: PHYSICAL AND ENVIRONMENTAL PROTECTION
FAMILY: PLANNING
FAMILY: PROGRAM MANAGEMENT
FAMILY: PERSONNEL SECURITY
FAMILY: RISK ASSESSMENT
FAMILY: SYSTEM AND SERVICES ACQUISITION
FAMILY: SYSTEM AND COMMUNICATIONS PROTECTION
FAMILY: SYSTEM AND INFORMATION INTEGRITY
ICT SUPPLY CHAIN THREAT EVENTS
SUPPLY CHAIN THREAT SCENARIOS AND ANALYSIS FRAMEWORK
DEVELOPING AND ANALYZING THREAT SCENARIOS & IDENTIFYING APPLICABLE CONTROLS
SAMPLE SCENARIOS
SCENARIO 1: Telecommunications Counterfeits SCENARIO 2: Industrial Espionage SCENARIO 3: Malicious Code Insertion SCENARIO 4: Unintentional Compromise
ICT SCRM PLAN TEMPLATE
1 INTRODUCTION
Page vi
1.1 Purpose and Scope
1.2 Authority
1.3 Audience
2 ROLES AND RESPONSIBILITIES
2.1 Responsibility for the plan
2.2 Key Contributors
3 ICT SCRM CONTROLS
4 USING AND REVISING ICT SCRM PLAN
4.1 Communicating ICT SCRM Plan
4.2 Revision and Improvement
4.3 Implementing and Assessing Effectiveness of ICT SCRM Plans
4.4 Use of ICT SCRM Plan during Contingencies and Emergencies
ATTACHMENTS
GLOSSARY
ACRONYMS
REFERENCES
Page vii
List of Figures and Tables
FIGURE 1-1: FOUR PILLARS OF ICT SCRM
FIGURE 1-2: FEDERAL AGENCY RELATIONSHIPS WITH SYSTEM INTEGRATORS, SUPPLIERS, AND EXTERNAL SERVICE PROVIDERS WITH
RESPECT TO THE SCOPE OF NIST SP 800-161
FIGURE 1-3: ICT SUPPLY CHAIN RISK
FIGURE 1-4: AN ORGANIZATION’S VISIBILITY, UNDERSTANDING, AND CONTROL OF ITS ICT SUPPLY CHAINS
FIGURE 1-5: ICT SCRM SECURITY CONTROLS IN NIST SP 800-161, CHAPTER 3.5
FIGURE 2-1: RISK MANAGEMENT PROCESS
FIGURE 2-2: MULTITIERED ORGANIZATION-WIDE RISK MANAGEMENT
FIGURE 2-3: ICT SCRM RISK MANAGEMENT
FIGURE 2-4: ICT SCRM ACTIVITIES IN RISK MANAGEMENT PROCESS
FIGURE 2-5: ICT SCRM IN THE FRAME STEP
FIGURE 2-6: ICT SCRM IN THE ASSESS STEP
FIGURE 2-7: ICT SCRM IN THE RESPOND STEP
FIGURE 2-8: ICT SCRM IN THE MONITOR STEP
FIGURE 3-1: ICT SCRM SECURITY CONTROLS IN NIST SP 800-161, CHAPTER 3.5
FIGURE D-1: SAMPLE THREAT SCENARIO ANALYSIS FRAMEWORK ..................................................................................... D-4
FIGURE E-1: ISO/IEC 15288 LIFE CYCLE PROCESSES ..................................................................................................... E-1
FIGURE E-2: ICT SCRM PLAN AND LIFE CYCLES ............................................................................................................. E-2
FIGURE E-3: AGENCY IMPLEMENTATION OF ICT SCRM PLAN ........................................................................................... E-7
TABLE 2-1: SUPPLY CHAIN RISK MANAGEMENT STAKEHOLDERS
TABLE 2-2: EXAMPLES OF ICT SUPPLY CHAIN THREAT AGENTS
TABLE 2-3: SUPPLY CHAIN THREAT CONSIDERATIONS
TABLE 2-4: SUPPLY CHAIN VULNERABILITY CONSIDERATIONS
TABLE 2-5: SUPPLY CHAIN CONSTRAINTS
TABLE 2-6: EXAMPLES OF ICT SUPPLY CHAIN VULNERABILITIES MAPPED TO THE ORGANIZATIONAL TIERS
TABLE 2-7: ICT SCRM PLAN CONTROLS AT TIERS 1, 2, AND 3
TABLE 3-2: ICT SCRM CONTROL FORMAT
TABLE A-1: ICT SCRM CONTROL SUMMARY ............................................................................................................... A-1
TABLE C-1: ADVERSARIAL ICT SUPPLY CHAIN THREAT EVENTS ......................................................................................... C-1
TABLE C-2: NON-ADVERSARIAL ICT SUPPLY CHAIN THREAT EVENTS ................................................................................. C-6
CHAPTER 1 PAGE 1
CHAPTER ONE
INTRODUCTION
nformation and Communications Technology (ICT) relies on a complex, globally distributed, and interconnected supply chain ecosystem that is long, has geographically diverse routes, and consists of multiple tiers of outsourcing. This ecosystem is composed of public and private sector entities (e.g., acquirers, system integrators, suppliers, and external service providers) and technology, law, policy, procedures, and practices that interact to design, manufacture, distribute, deploy, and use ICT products and services. This ecosystem has evolved to provide a set of highly refined, cost-effective, reusable ICT solutions. Federal government information systems1 have rapidly adopted this ecosystem of solution options, which has increased their reliance on commercially available products, system integrator support for custom-built systems, and external service providers. This in turn has resulted in increased complexity, diversity, and scale of the federal government’s ICT supply chains.
Commercially available ICT solutions present significant benefits including low cost, interoperability, rapid innovation, a variety of product features, and choice among competing vendors. These commercial off-the-shelf (COTS) solutions can be proprietary or open source and can meet the needs of a global base of public and private sector customers. However, the same globalization and other factors that allow for such benefits also increase the risk of a threat event which can directly or indirectly affect the ICT supply chain, often undetected, and in a manner that may result in risks to the end user.
These ICT supply chain risks may include insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software and hardware, as well as poor manufacturing and development practices in the ICT supply chain. These risks are associated with an organization’s decreased visibility into, and understanding of, how the technology that they acquire is developed, integrated, and deployed, as well as the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products and services.2 Threats and vulnerabilities created by malicious actors (individuals, organizations, or nation states) are often especially sophisticated and difficult to detect, and thus provide a significant risk to organizations. It should be noted that ICT products (including libraries, frameworks, and toolkits) or services originating anywhere (domestically or abroad) might contain vulnerabilities that
1 An information system is a discrete set of information resources organized expressly for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. Information systems also include specialized systems such as industrial/process controls systems, telephone switching/private branch exchange (PBX) systems, and environmental control systems.[NIST SP 800-53 Rev. 4]
2 This document adapts the definition of risk from [FIPS 200] to establish a definition for ICT supply chain risk as follows:
Risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.
I
CHAPTER 1 PAGE 2
can present opportunities for ICT supply chain compromises.3 For example, an adversary may have the power to insert malicious capability into a product or to coerce a manufacturer to hand over the manufacturing specifications of a sensitive U.S. system. Note that it is impossible to completely eliminate all risks.
Currently, organizations, and many private sector integrators and suppliers use varied and not yet standardized practices, which make it difficult to consistently measure and manage ICT supply chain risks across different organizations. ICT Supply Chain Risk Management (SCRM) is the process of identifying, assessing, and mitigating the risks associated with the global and distributed nature of ICT product and service supply chains.
1.1 PURPOSE
The purpose of this publication is to provide guidance to federal agencies on identifying, assessing, selecting, and implementing risk management processes and mitigating controls throughout their organizations to help manage ICT supply chain risks.
The processes and controls identified in this document can be modified or augmented with organization-specific requirements from policies, guidelines, and other documents. This publication empowers organizations to develop ICT SCRM mitigation strategies that are tailored to their particular mission/business needs, threats, and operational environments. The publication does not provide contract language or a complete list of ICT SCRM methods and techniques that mitigate specific supply chain threats.
1.2 SCOPE
This publication provides guidance to federal agencies on managing ICT supply chain risks to their information systems and organizations. The processes and controls described in this publication build on federal agency guidance and are for federal agencies to consider and implement. While entities outside of the federal government may decide to consult this publication as a source of good practices, the publication does not contain any specific guidance for those entities.
The guidance and controls in this publication are recommended for use with high-impact systems according to Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems [FIPS 199]. However, because of interdependencies and individual needs, agencies may choose to apply the guidance to systems at a lower-impact level or to specific system components.
Agencies should carefully consider the potential costs of applying ICT SCRM controls beyond high-impact information systems and weigh the costs against the risks to the organization of not applying ICT
3 This document defines an ICT Supply Chain Compromise as:
An occurrence within the ICT supply chain whereby an adversary jeopardizes the confidentiality, integrity, or availability of a system or the information the system processes, stores, or transmits. An ICT supply chain compromise can occur anywhere within the system development life cycle of the product or service.
CHAPTER 1 PAGE 3
SCRM controls. Implementing these controls will require financial and human resources, not just from the agencies directly but also potentially from their systems integrators, suppliers, and external service providers that would also result in increased costs to the acquirer. ICT SCRM controls support risk management, and should be considered in the context of the agency’s or organization’s unique missions, operational environments, and risks.
In applying the processes and controls, organizations may decide to include requirements that they include in their policies, acquisition guidelines, and procurement documents.
In this document, the word organization refers to the federal agency. In the context of this document, the acquirer is the federal agency.
Federal agencies are a diverse set of organizations with different missions, structures, and sizes. The guidance in this publication applies across the federal sector, and therefore this publication does not differentiate between the terms federal agency and organization, and uses those terms interchangeably.
1.3 TARGET AUDIENCE
ICT SCRM is an organization-wide activity that should be directed under the overall agency governance, regardless of the specific organizational structure. At the organization level, ICT SCRM activities should be led by the risk executive function, described in [NIST SP 800-39], and implemented throughout the organization by a variety of individuals in different roles. The audience for this publication is federal agency personnel involved in engineering/developing, testing, deploying, acquiring, maintaining, and retiring ICT components and systems. These functions may include, but are not limited to, information technology, information security, contracting, risk executive, program management, legal, supply chain and logistics, acquisition and procurement, other related functions, and system owner. Other personnel or entities are free to make use of the guidance as appropriate to their situation.
1.4 BACKGROUND
ICT SCRM encompasses activities in the system development life cycle, including research and development (R&D), design, manufacturing, acquisition, delivery, integration, operations, and disposal/retirement of an organization’s ICT products (i.e., hardware and software) and services. ICT
SCRM lies at the intersection of security, integrity, resilience, and quality, as depicted in Figure 1-1.
Security provides the confidentiality, integrity, and availability of information that (a) describes the ICT supply chain (e.g., information about the paths of ICT products and services, both logical and physical); or (b) traverses the ICT supply chain (e.g., intellectual property contained in ICT products and services), as well as information about the parties participating in the ICT supply chain (anyone who touches an ICT product or service throughout its life cycle);
Integrity is focused on ensuring that the ICT products or services in the ICT supply chain are genuine, unaltered, and that the ICT products and services will perform according to acquirer specifications and without additional unwanted functionality.
Resilience is focused on ensuring that ICT supply chain will provide required ICT products and services under stress or failure; and
Quality is focused on reducing vulnerabilities that may limit the intended function of a component, lead to component failure, or provide opportunities for exploitation.
This publication addresses the overlap of the four pillars of ICT SCRM - security, integrity, resilience, and quality - as depicted in Figure 1-1. The publication does not address the entire body of knowledge of these disciplines that is depicted by the non-overlapping areas of the circles in Figure 1-1.
CHAPTER 1 PAGE 4
Figure 1-1: Four Pillars of ICT SCRM
1.4.1 Federal Agencies ICT Supply Chain
Federal agencies run complex information systems and networks to support their missions. These information systems and networks are composed of ICT products and components made available by ICT suppliers. Federal agencies also acquire and deploy an array of IT services, including those that:
Integrate or provide operations, maintenance, and disposal support for federal information systems and networks within and outside of the federal agency authorization boundaries,4 made available by system integrators; and
Provide external services to support federal agency operations that are provided from both within or outside of the federal agency authorization boundaries, made available by external service providers.
In addition to operating information systems and networks internally, organizations also host system development and integration activities within their authorization boundaries. Those activities may be performed by the agency themselves or by system integrators. The ICT supply chain infrastructure is the integrated set of components (hardware, software, and processes) within the organizational boundary that
4 NIST SP 800-53 Rev. 4 defines Authorization Boundary as:
All components of an information system to be authorized for operation by an authorizing official and excludes separately authorized systems, to which the information system is connected.[NIST SP 800-53 Rev. 4, p. B-2]
CHAPTER 1 PAGE 5
composes the environment in which a system is developed or manufactured, tested, deployed, maintained, and retired/decommissioned. Figure 1-2 depicts a federal agency ICT supply chain that consists of multiple layers of system integrators, external service providers, and suppliers with respect to the scope of this publication and the drivers that influence activities described herein.
The ICT supply chain infrastructure is the integrated set of components (hardware, software and processes) within the organizational boundary that composes the environment in which a system is developed or manufactured, tested, deployed, maintained, and retired/decommissioned.
Depicted in Figure 1-2, organizations define which mission functions and information systems compose the ICT supply chain infrastructure, potentially including system integrator and external service provider support.
An organization’s ICT supply chain infrastructure includes internal development, information, information systems, services, components, and processes to create, maintain, and retire an organization’s information systems. Examples include development environments, individuals who are working within the organization’s facilities, logistics/delivery environments that transport information systems and components, or applicable system and communications interfaces. These elements of the ICT supply chain infrastructure may be provided by the organization itself, system integrator, or external service provider. Inclusion in ICT supply chain infrastructure is defined by agreement documents for organization’s information systems between system integrator or external service provider or the organization.
Figure 1-2: Federal Agency Relationships with System Integrators, Suppliers, and External Service Providers with
Respect to the Scope of NIST SP 800-161.
CHAPTER 1 PAGE 6
The ICT supply chain infrastructure does not include:
The information system traversing the supply chain;
Any information system not used in the development, testing, maintenance, or retirement of information system components;
System integrator, supplier, and external service provider information systems that are outside of the organization’s information system boundaries as defined by [NIST SP 800-37 Rev. 1];
System integrator, supplier, and external service provider people, processes, and technology that are not engaged in supporting the information system sytem development life cycle (SDLC); and
The organization’s people, processes, and technology not engaged in the SDLC for an information system. For example, organization’s shipping and receiving processes handling non-
ICT are not included in the ICT supply chain infrastructure, such as food services or paper clips.
Supplier and system integrator are included under the definition of “developer” by NIST SP 800-53
Revision 4, Security and Privacy Controls for Federal Information Systems and Organizations:
A general term that includes: (i) developers or manufacturers of information systems, system components, or information system services; (ii) systems integrators; (iii) vendors; and (iv) product resellers. Development of systems, components, or services can occur internally within organizations (i.e., in-house development) or through external entities.[NIST SP 800-53 Rev. 4, p.
B-6]
NIST SP 800-161 uses NIST SP 800-53 Revision 4 developer definition items (i), (iii), and (iv) to define supplier and item (ii) to define system integrator.
NIST SP 800-53 Revision 4 describes external information system service provider as follows:
External services can be provided by: (i) entities within the organization but outside of the security authorization boundaries established for organizational information systems; (ii) entities outside of the organization either in the public sector (e.g., federal agencies) or private sector (e.g., commercial service providers); or (iii) some combination of the public and private sector options.
External information system services include, for example, the use of service-oriented architectures (SOAs), cloud-based services (infrastructure, platform, software), or data center operations. External information system services may be used by, but are typically not part of, organizational information systems. In some situations, external information system services may completely replace or heavily augment the routine functionality of internal organizational information systems. [NIST SP 800-53 Rev. 4, p. B-8]
Additionally, NIST SP 800-53 Revision 4 describes organizational users as follows:
An organizational employee or an individual the organization deems to have equivalent status of an employee including, for example, contractor, guest researcher, or individual detailed from another organization.[NIST SP 800-53 Rev. 4, p. B-16]
CHAPTER 1 PAGE 7
1.4.2 ICT Supply Chain Risk
ICT supply chain risks include insertion of counterfeits, unauthorized production, tampering, theft, insertion of malicious software and hardware (e.g., GPS tracking devices, computer chips, etc.), as well as poor manufacturing and development practices in the ICT supply chain. These risks are realized when threats in the ICT supply chain exploit existing vulnerabilities.
Figure 1-3 depicts ICT supply chain risk resulting from the likelihood that relevant threats may exploit applicable vulnerabilities and the consequential potential impact.
Figure 1-3: ICT Supply Chain Risk
It should be noted that it might take years for a vulnerability stemming from the ICT supply chain to be exploited or discovered. In addition, it may be difficult to determine whether an event was the direct result of a supply chain vulnerability. This may result in a persistent negative impact on an organization’s missions that could range from reduction in service levels leading to customer dissatisfaction to theft of intellectual property or degradation of mission-critical functions.
CHAPTER 1 PAGE 8
1.4.3 Federal Agency Relationships with System Integrators, Suppliers, and External Service Providers
ICT supply chain risks are associated with an organization’s decreased visibility into, and understanding of, how the technology that they acquire is developed, integrated, and deployed. They are also associated with the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products and services. Federal agencies have a variety of relationships with their system integrators, suppliers, and external service providers. Figure 1-4 depicts how the diverse types of these relationships affect an organization’s visibility and control of the supply chain.
Figure 1-4: An Organization’s Visibility, Understanding, and Control of its ICT Supply Chains
Some supply chain relationships are tightly intermingled, such as when a system integrator develops a complex information system to be operated within the federal agency’s authorization boundary or when an external service provider manages federal agency information systems and resources on behalf of the department. These relationships are usually guided by an agreement (e.g., contract) that establishes detailed functional and security requirements and may provide for custom development or significant customization of ICT products and services. For these relationships, system integrators and external service providers are likely to be able to work with the federal agency to implement those processes and controls listed within this document, which are deemed appropriate based on the results of a risk assessment and cost/benefit analysis. This may include floating requirements upstream in the supply chain that can significantly impact costs to the supplier. The cost of requiring system integrators and external service providers to implement ICT SCRM processes and controls should be weighed against the risks to the organization of not adhering to those additional requirements. Often, working directly with the system
CHAPTER 1 PAGE 9
integrators and external service providers to identify appropriate mitigation processes and controls will help create a more cost-effective strategy.
Procuring ICT products directly from ICT suppliers establishes a direct relationship between those suppliers and the acquirers. This relationship is also usually guided by an agreement between the acquirer and ICT supplier. However, commercial ICT developed by suppliers are typically designed for general purposes for a global market and typically are not tailored to any individual customer’s specific operational or threat environments. Organizations should establish a dialog with ICT suppliers regarding their specific ICT SCRM requirements to determine if an ICT solution is “fit for purpose."5
This dialog will help acquirers understand the capabilities of existing ICT products and services, set expectations and requirements for suppliers, and identify ICT SCRM needs not yet satisfied by the market. It can also help identify emerging solutions that may at least partially support the acquirer need.
Overall, the dialog will allow the acquirer to better articulate their requirements to align with and drive market offerings.
This dialog will also help system integrators, suppliers, and external service providers achieve a more nuanced understanding of the organization’s requirements and how their current and emerging ICT products and services may be able to satisfy them.
Organizations should recognize that ICT suppliers may or may not be able to offer customization or tailoring to their ICT SCRM needs, and that such tailoring may have cost implications. Acquirers should weigh the costs and benefits afforded by these products to make their final acquisition decision. Acquirers should also recognize that ICT suppliers may choose to keep their processes or products as is and not support the acquirer’s security and ICT SCRM requirements. The dialog between acquirers and ICT suppliers may help acquirers and ICT suppliers achieve an understanding and identify acceptable solutions when such challenges occur.
Requiring a greater level of testing, documentation, or security features from system integrators, suppliers, and external service providers may increase the price of a product or service. Additional costs may include the development or testing of products, or the collection, analysis, storage and protection of data. This is especially true for those products and services developed for general-purpose application and not tailored to the specific organization’s security or ICT SCRM requirements. Acquirers should evaluate and weigh the costs of adding ICT SCRM requirement into agreements against the risks to the organization of not adding ICT SCRM requirements.
5 “Fit for purpose” is a term used informally to describe a process, configuration item, IT service, etc., that is capable of meeting its objectives or service levels. Being fit for purpose requires suitable design, implementation, control, and maintenance.
(Adapted from Information Technology Infrastructure Library (ITIL) Service Strategy.[ITIL Service Strategy)
CHAPTER 1 PAGE 10
1.5 FOUNDATIONAL PRACTICES
ICT supply chain risk management builds on existing standardized practices in multiple disciplines.
Organizations should consider reaching a base level of maturity in foundational practices prior to specifically focusing on ICT SCRM practices that are more advanced. Those foundational practices are described in NIST standards and guidelines as well as other applicable national and international standards and best practices. They include: ensuring that organizations understand the cost and scheduling constraints of implementing ICT SCRM; integrating information security requirements into the acquisition process; using applicable baseline security controls as one of the sources for security requirements; ensuring a robust software quality control process; and establishing multiple sources, e.g., delivery routes, for critical system elements. A formal program and process, including dedicated resources, may be used to reach a base level of maturity. [FIPS 199] “high-impact” systems should already have these foundational practices established.
Having foundational practices in place is critical to successfully and productively interacting with mature system integrators and suppliers who may have such practices standardized and in place.
The following are specific examples of the multidisciplinary foundational practices that can be implemented incrementally to improve an organization’s ability to develop and implement more advanced
ICT SCRM practices:
Implement a risk management hierarchy and risk management process (in accordance with NIST
SP 800-39, Managing Information Security Risk [NIST SP 800-39]) including an organization-wide risk assessment process (in accordance with NIST SP 800-30 Revision 1, Guide for
Conducting Risk Assessments [NIST SP 800-30 Rev. 1]);
Establish an organization governance structure that integrates ICT SCRM requirements and incorporates these requirements into the organizational policies;
Establish consistent, well-documented, repeatable processes for determining [FIPS 199]impact levels;
Use risk assessment processes after the [FIPS 199] impact level has been defined, including criticality analysis, threat analysis, and vulnerability analysis;
Implement a quality and reliability program that includes quality assurance and quality control process and practices;
Establish a set of roles and responsibilities for ICT SCRM that ensures that the broad set of appropriate stakeholders are involved in decision making, including who has the required authority to take action, who has accountability for an action or result, and who should be consulted and/or informed (e.g., Legal, Risk Executive, HR, Finance, Enterprise IT, Program
Management/System Engineering, Information Security, Acquisition/procurement, supply chain logistics, etc.);
Ensure that adequate resources are allocated to information security and ICT SCRM to ensure proper implementation of guidance and controls;
Implement consistent, well-documented, repeatable processes for system engineering, ICT security practices, and acquisition;
Implement an appropriate and tailored set of baseline information security controls in NIST SP
800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and
Organizations [NIST SP 800-53 Rev. 4];
Establish internal checks and balances to assure compliance with security and quality requirements;
CHAPTER 1 PAGE 11
Establish a supplier management program including, for example, guidelines for purchasing directly from qualified original equipment manufacturers (OEMs)6 or their authorized distributors and resellers;
Implement a tested and repeatable contingency plan that integrates ICT supply chain risk considerations to ensure the integrity and reliability of the supply chain including during adverse events (e.g., natural disasters such as hurricanes or economic disruptions such as labor strikes);
and
Implement a robust incident management program to successfully identify, respond to, and mitigate security incidents. This program should be capable of identifying causes of security incidents, including those originating from the ICT supply chain.
The guidance and controls contained in this publication are built on existing practices from multiple disciplines and are intended to increase the ability of organizations to strategically manage ICT supply chain risks over the entire life cycle of systems, products, and services.
1.6 RELATIONSHIP TO OTHER PROGRAMS AND PUBLICATIONS
This publication builds on the Joint Task Force Transformation Initiative Unified Information Security
Framework7 and uses concepts described in a number of NIST publications to facilitate integration with the agencies’ existing organization-wide activities. These publications are complementary and work together to help organizations build risk-based information security programs to help protect their operations and assets against a range of diverse and increasingly sophisticated threats. This publication will be revised to remain consistent with the NIST SP 800-53 security controls catalog, using an iterative process as the ICT SCRM discipline matures.
NIST SP 800-161 builds on the fundamental concepts described in:
FIPS 199, Standards for Security Categorization of Federal Information and Information
Systems, to conduct criticality analysis to scoping ICT SCRM activities to high-impact components or systems [FIPS 199];
NIST SP 800-30, Revision 1, Guide for Conducting Risk Assessments, to integrate ICT SCRM into the risk assessment process [NIST SP 800-30 Rev 1];
NIST SP 800-37, Revision 1, Guide for Applying the Risk Management Framework to Federal
Information Systems [NIST SP 800-37 Rev. 1];
6 For purposes of this publication, the term original equipment manufacturers includes original component manufacturers.
7 The Unified Information Security Framework is a comprehensive, flexible, risk-based information security framework developed by the Joint Task Force, a partnership among the National Institute of Standards and Technology, the Department of
Defense, the U.S. Intelligence Community, and the Committee on National Security Systems. The Unified Information Security
Framework consists of five core publications including: [NIST SP 800-39]; [NIST SP 800-30 Rev. 1]; [NIST SP 800-53 Rev. 4];
and [NIST SP 800-37 Rev. 1].
CHAPTER 1 PAGE 12
NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information
System View, to integrate ICT SCRM into the risk management tiers and risk management process [NIST SP 800-39];
NIST 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and
Organizations, to provide information security controls for enhancing and tailoring to ICT SCRM context [NIST SP 800-53 Rev. 4]; and
NIST SP 800-53A Revision 4, Guide for Assessing the Security Controls in Federal Information
Systems and Organizations, Building Effective Security Assessment Plans, to enable the assessment techniques to be applicable to ICT SCRM controls in this publication [NIST SP 800-
53A Rev. 4].
NIST SP 800-161 refines the multitiered risk management approach of [NIST SP 800-39], by providing
ICT SCRM guidance at Organization, Mission, and Information System Tiers. It also contains an enhanced overlay of specific ICT SCRM controls, building on [NIST SP 800-53 Rev. 4]. Appendix C of this publication contains threat events described in [NIST SP 800-30 Rev. 1] .
For specific guidance on system security engineering, the readers of NIST SP 800-161 should consult
NIST SP 800-160, Systems Security Engineering [NIST SP 800-160]. They complement each other; NIST
SP 800-161 addresses the security engineering aspects of ICT SCRM while NIST SP 800-160 addresses system security engineering more broadly throughout SDLC processes. Both publications build on [NIST
SP 800-53 Rev. 4].
NIST SP 800-161 draws from a collaborative ICT SCRM community workshop hosted in October 2012
[NIST SCRM Proceedings 2012] and NIST Interagency Report (IR) 7622, Notional Supply Chain Risk
Management Practices for Federal Information Systems [NIST IR 7622], which resulted from several years of rigorous study of the ICT SCRM discipline and provided NIST the insight required to scope and develop this special publication. NISTIR 7622 can be used by the reader for background materials in support of applying the special publication to their specific acquisition processes.
NIST SP 800-161 also draws from several external publications, including:
Department of Defense and Department of Homeland Security Software Assurance Acquisition
Working Group, Software Assurance in Acquisition: Mitigating Risks to the Enterprise [SwA];
National Defense Industrial Association (NDIA), Engineering for System Assurance [NDIA];
International Organization for Standardization/International Electrotechnical Commission
(ISO/IEC) 15288 – System Life Cycle Processes [ISO/IEC 15288];
Draft ISO/IEC 27036 – Information Technology – Security Techniques – Information Security for
Supplier Relationships [ISO/IEC 27036];
The Open Group’s Open Trusted Technology Provider™ Standard (O-TTPS), Version 1.0, Mitigating Maliciously Tainted and Counterfeit Products [O-TTPS]; and
Software Assurance Forum for Excellence in Code (SAFECode) Software Integrity Framework
[SAFECode 2] and Software Integrity Best Practices [SAFECode 1].
CHAPTER 1 PAGE 13
This publication does not replace guidance provided with respect to federal agency assessment of cloud service providers’ security. The external service providers discussed in this publication include cloud service providers. 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 NIST SP 800-161 for those processes and controls that are not addressed by FEDRAMP.8
1.7 METHODOLOGY FOR BUILDING ICT SCRM GUIDANCE USING SP 800-39 AND
NIST SP 800-53 REVISION 4
This publication applies the multitiered risk management approach of [NIST SP 800-39], by providing
ICT SCRM guidance at organization, mission, and system tiers. It also contains an enhanced overlay of specific ICT SCRM controls, building on NIST SP 800-53 Revision 4.
The guidance/controls contained in this publication are built on existing practices from multiple disciplines and are intended to increase the ability of organizations to strategically manage the associated
ICT supply chain risks over the entire life cycle of systems, products, and services. It should be noted that this publication gives organizations the flexibility to either develop stand-alone documentation (e.g., policies, assessment and authorization [A&A] plan and ICT SCRM plan) for ICT SCRM or to integrate it into existing agency documentation.
For individual systems, this guidance is recommended for use for those information systems that are categorized as high-impact systems according to [FIPS 199]. The agencies may choose to apply this guidance to systems at a lower-impact level or to specific system components. Finally, NIST SP 800-161 describes the development and implementation of an ICT SCRM plan to be developed at all levels of an organization. An ICT SCRM plan is an output of ICT supply chain risk assessment and should contain
ICT SCRM controls tailored to specific agency mission/business needs, operational environments, and/or implementing technologies.
1.7.1 Integration into Risk Management Process
The processes in this publication should be integrated into agencies’ existing SDLCs and organizational environments at all levels of the risk management processes and hierarchy (organization, mission, system) as described in [NIST SP 800-39]. Chapter 2.1 provides an overview of the [NIST SP 800-39] risk management hierarchy and approach, and identifies ICT SCRM activities in the risk management process.
The structure of Chapter 2.1 mirrors [NIST SP 800-39]. Chapter 2.2 builds on Chapter 3 of [NIST SP
800-39], providing descriptions and explanations of ICT SCRM activities.
8 For cloud services, FEDRAMP is applicable for low- and moderate-impact systems [FEDRAMP]. Ongoing work will address high-impact systems utilizing cloud services. Once the work is completed, agencies should refer to FEDRAMP for guidance applicable to high-impact systems utilizing cloud services.
CHAPTER 1 PAGE 14
1.7.2 Enhanced ICT SCRM Overlay
This publication contains an enhanced overlay of [NIST SP 800-53 Rev. 4]. Chapter 3 identifies, refines, and expands ICT SCRM-related controls from [NIST SP 800-53 Rev. 4], adds new controls that address specific ICT SCRM concerns, and offers ICT SCRM-specific supplemental guidance where appropriate.
Figure 1-5 illustrates the process used to create the enhanced overlay. The individual controls and enhancements from [NIST SP 800-53 Rev. 4] that were relevant to ICT SCRM were extracted. These controls were analyzed to determine how they apply to ICT SCRM. Additional supplemental guidance was then developed and included for each control and control enhancement. The resulting set of controls and enhancements were evaluated to determine whether all ICT SCRM concerns were addressed. A new control family, Provenance, and some additional controls and control enhancements were created to address specific remaining ICT SCRM concerns.
Figure 1-5: ICT SCRM Security Controls in NIST SP 800-161, Chapter 3.5
1.8 ORGANIZATION OF THIS SPECIAL PUBLICATION
This publication is organized as follows:
Chapter 1 provides the purpose, scope, and applicability of the publication and describes foundational concepts and practices;
Managing Cost and Resources
Organizations should be aware that implementing these controls will require financial and human resources. Any requirements that result from federal agencies implementing these controls may also require financial and human resources from their system integrators, suppliers, and external service providers potentially resulting in increased costs to the federal acquirers. The acquirers should be cognizant of the costs and weigh them against the risks to the organization of not selecting ICT SCRM controls. When appropriate, allow system integrators, suppliers, and external services providers the opportunity to reuse any existing data and documentation that may provide evidence to support ICT
SCRM. The challenge of balancing ICT supply chain risks with the costs and benefits of mitigating controls should be a key component of the acquirer’s overall approach to ICT SCRM.
CHAPTER 1 PAGE 15
Chapter…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .