ezesecops/rmf-ato-core huggingface dataset:
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 1.2. Relationship With Other NIST Publications

1.2. Relationship With Other NIST Publications

This publication is designed to support the NIST portfolio of risk management initiatives and
publications5 that address security, privacy, and supply chain risk management concepts and
methodologies, including:
• SP 800-37, Risk Management Framework for Information Systems and Organizations: A
System Life Cycle Approach for Security and Privacy [SP800-37]
• SP 800-53, Security and Privacy Controls for Information Systems and Organizations
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 1.3. Document Organization

1.3. Document Organization

The publication is organized into the following sections:
• Section 2 describes system security, system privacy, and C-SCRM plans and discusses the
development of consolidated plans.
• Section 3 identifies elements that may be included in system security, privacy, and
C-SCRM plans and describes how automation can support the collection and reporting
of system information.
• Section 4 provides a management-level overview of how system plans are developed
and maintained in relation to the NIST RMF.
• The References section lists the source materials cited in this publication.
The following appendices provide additional information and resources that support the
development of system plans:
5 The full range of NIST cybersecurity-related publications can be found in the Information Technology Laboratory (ITL) Computer Security
Resource Center [CSRC]. Additional resources are available through the NIST Cybersecurity and Privacy Reference Tool [CPRT].
• Appendix A summarizes the RMF task outputs included in system plans.
• Appendix B lists the abbreviations and acronyms used in this publication.
• Appendix C provides a glossary of the terms used in this publication.
• Appendix D provides a publication change log.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 2. Overview

2. Overview

Based on the organization's risk management strategy and NIST guidelines (e.g., [SP800-37],
[SP800-53], [SP800-161]), system plans:
• Identify the authorization boundary of the system;
• Identify individuals who are responsible for managing and supporting the system;
• Help organizational personnel understand how to manage risks to an acceptable level
throughout the system life cycle and respond to changing risks in a timely manner;
• Demonstrate the application of security engineering approaches to building resilient and
trustworthy systems following [SP800-160v1r1] and [SP800-160v2r1];
• Define capabilities to defend the organization against threats and threat actors;
• Consider requirements for information technology, operational technology, and
emerging technologies that may be informed by system artifacts, such as risk
assessments, business impact analyses (BIAs), and information exchange agreements;
• Address organizationally defined parameters, acceptable risk thresholds, and
organizational policies that support the organization's security, privacy, and C-SCRM
objectives;
• Provide sufficient evidence to support risk-based decisions regarding the ongoing
operation or use of the system; and
• Require methodical reviews and periodic updates to maintain information about the
system's mission, technologies, components, personnel, and the status of controls that
are selected and allocated for system implementation.
This section addresses the objectives and purposes of the system security plan, system privacy
plan, and C-SCRM plan.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 2.1. System Security Plan

2.1. System Security Plan

The system security plan identifies the system's security requirements and describes the
controls that are planned and implemented to meet those requirements. The system security
plan:
• Supports situational awareness of the system security posture over the course of the
system life cycle (i.e., "living document");
• Enables organizational leadership and system management personnel to manage
security risks and make effective risk management decisions;
• Identifies the individuals responsible for maintaining the security protections and
safeguards for information and systems;
• Consolidates details about the system, including its purpose, authorization boundary,
[FIPS199] security categorization, operational status, and environment of operation; and
• Explains how controls are implemented to achieve security objectives (i.e.,
confidentiality, integrity, and availability).
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 2.2. System Privacy Plan

2.2. System Privacy Plan

The system privacy plan identifies controls that are allocated and implemented to address
privacy risks related to both cybersecurity events and data processing. The privacy plan:
• Aligns the system's privacy objectives with the organization's mission, risk tolerance,
and privacy goals;
• Defines system requirements with respect to the privacy engineering objectives of
predictability, manageability, and disassociability and the Fair Information Practice
Principles (FIPPs)6; and
• Describes planned and implemented controls to address privacy requirements and data
processing activities that may compromise privacy (i.e., problematic data actions7).
Systems must comply with laws governing data subject rights (i.e., the right to access, correct,
or delete information8). The system privacy plan describes how the organization manages the
risks of over-collection, unauthorized profiling, or the misuse of data about individuals.
Privacy requirements may be informed by the following:
• Legal and regulatory obligations
• Privacy activities and artifacts including the Privacy Impact Assessment (PIA) and Privacy
Risk Assessment (PRA)9
• Information exchange agreements [SP800-47]
• Public notices for the collection and use of personal information, such as a System of
Records Notice (SORN)[PRIVACT]
This includes identifying and cataloging key inputs, such as data actions, contextual factors that
describe the circumstances surrounding data processing, privacy capabilities, and privacy
engineering and security objectives based on organizational mission needs, risk tolerance, and
privacy goals.
6 The FIPPs have been adopted in various forms in law and policy within the U.S. Government and by international organizations, such as the
Organization for Economic Cooperation and Development (OECD) and the European Union. [OMB A-130] identifies and explains the FIPPs for
U.S. federal agencies.
7 Per the NIST Privacy Framework [NIST PF], a problematic data action (PDA) may cause an adverse effect for individuals.
8 Many laws, regulations, and guidance focus on a defined scope of information that is covered by privacy protections for PII, such as
[OMB A-130] or the California Privacy Rights Act [CPRA]. However, data processing may still introduce privacy risks, even if data does not meet
a narrow privacy definition (e.g., some data that is not PII can be combined with other information during processing to become PII).
9 The NIST Privacy Risk Assessment Methodology [PRAM] helps organizations analyze, assess, and prioritize privacy risks to identify appropriate
responses and solutions.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 2.4. Consolidated System Plan

2.4. Consolidated System Plan

Organizations determine whether to consolidate the system security, system privacy, or
C-SCRM plans, as described in RMF [SP800-37] Task S-4, Documentation of Planned Control
Implementations, and [SP800-161]. For a consolidated plan:
• Common elements in the security, privacy, and C-SCRM plans (e.g., System Name and
Identifier, System Operational Status, System Overview, Authorization Boundary
Description) provide consistent information about the system's mission, purpose, and
environment of operation.
• Roles and responsibilities are defined to support the ongoing collaboration between
individuals who are responsible for meeting system security, privacy, and C-SCRM
requirements.
• Each control that is allocated, tailored, and implemented or planned for implementation
has details that clearly address system requirements.
When choosing whether to consolidate plans, an organization may consider the
interrelationship of controls that address the risks associated with overlapping cybersecurity,
cybersecurity supply chain, and privacy incidents or events, as shown in Fig. 1.
Fig. 1. Cybersecurity, privacy, and cybersecurity supply chain risk relationships
While security-related controls can support system privacy outcomes, privacy risks may require
additional privacy-focused controls that go beyond protecting confidentiality, integrity, and
availability. Some may also introduce privacy risks that require additional management, such as
monitoring for insider threats. For example, an implemented software component may have
vulnerabilities that allow organization users to gain unauthorized access to datasets with
employees' personal information.
Cybersecurity and cybersecurity supply chain controls may not address certain aspects of data
handling and governance that can arise from the authorized processing of personal
information. For example, an attacker may exfiltrate an organization's customer data files
through the exploitation of a third-party service provider entrusted with the data.
Unauthorized data access and authorized disclosures that are made without sufficient
disassociability can introduce privacy problems for individuals that may have an impact on the
organization and result in noncompliance costs, direct business costs, or other impacts [PDAP].
Incorporating the security, privacy, and C-SCRM controls into a unified system plan provides a
holistic view of the risk management requirements and activities throughout the system life
cycle.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 3. System Plan Elements

3. System Plan Elements

This section describes the types of system information to include in the system plan.
Information management tools (e.g., GRC, SOAR, SIEM) can be used to capture, report, and
update system information details following consistent and logical structures that address
security, privacy, and C-SCRM risk management objectives. Organizations define the methods,
structures, and formats used to develop system plans that include the described elements and
additional organization- or system-specific elements as needed to achieve security, privacy, and
cybersecurity supply chain risk management program objectives.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 3.3. Automation Support for System Plan Information

3.3. Automation Support for System Plan Information

Automating the collection of system plan element information can increase the effectiveness
and efficiency of maintaining system plans. Organizations have the flexibility to decide when,
where, and how to use automation tools (e.g., GRC, SOAR, SIEM) to manage information for the
system plan elements associated with each system. For instance, automation tools can:
• Capture control implementation status information to demonstrate ongoing risk
management activities,16
• Support the tracking of POA&M activities to ensure that remediation actions are
completed,
• Facilitate the management of system plan reviews, and
• Control access to system plan information.
While some organizations have the resources to implement dedicated, organization-wide
information management tools to manage many system plans, organizations with limited
resources may be able to leverage commercially available services (e.g., office productivity
applications, open-source solutions, cloud-based services) to manage information for the
limited number of system plans within the organization.
NIST does not recommend, endorse, or certify specific products, vendors, or technologies for
the automation of system plan development and maintenance.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 3.3.1. System Plan Information Collection

3.3.1. System Plan Information Collection

The information contained in the system elements may be collected from both organization-
wide and system-specific data sources, including:
• System component inventory information (e.g., technology, function, role, and
configuration of components used within the operational environment17)
• Personnel contact information from an organizational directory
• Information types that are detected within the system but excluded from system
categorization determination
• Changes to common controls and the inherited portion of hybrid controls
• Changes to system plan information to enforce separation of duties
• New, in-process, and resolved POA&Ms
The collected information informs various management activities, such as prioritizing security,
privacy, or C-SCRM initiatives and allocating resources based on impact priorities. Automating
the collection of system-level risk information in a centralized repository following organization-
defined data standards can reduce inconsistencies that may lead to erroneous risk-based
decisions.
16 The [OSCAL] implementation layer includes a system security plan model that allows for the granular implementation and documentation of
various controls (e.g., security, privacy, safety, accessibility) that require automated governance, risk management, and compliance processes.
The OSCAL resources provide additional information and examples at https://nist.gov/OSCAL (documentation),
https://github.com/usnistgov/OSCAL (OSCAL models), and https://github.com/usnistgov/oscal-content (OSCAL SP 800-53 catalog, SP 800-53B
baselines, and SP 800-53A included in the OSCAL catalog).
17 [OSCAL] provides a "Component Definition" model that can be used by vendors to convey how controls are implemented by their products or
by organizations to create playbooks that describe the implementation of specific controls that support secure configurations for system
components.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 3.3.2. System Plan Information Sharing and Usability

3.3.2. System Plan Information Sharing and Usability

Maintaining system plan element information in a central repository using well-designed user
interfaces (e.g., dashboards, search functions, reporting methods) in place of potentially
lengthy traditional security plan artifacts may improve the responsiveness of risk-based
decision-making. Increased information usability supports various stakeholders, including:
• Senior leadership and risk managers to evaluate the organizational risk profile across all
systems in the organization's inventory
• Authorizing officials, senior agency officials for privacy, and system owners to quickly
locate, review, and update specific system plan elements in support of continuous
monitoring activities and ongoing authorization processes
• System management personnel to track approval processes for change management
functions and review control implementation metrics
The dashboard interfaces and reporting functions of organization-wide information
management tools can ensure that authorized personnel receive updates on system
component inventory information and the status of risk management efforts, including the
system's operational status, assessment and reauthorization schedules, POA&M statuses (e.g.,
late POA&Ms, expiring POA&Ms), and accepted risk information.
Information management tools may share control implementation statuses, control assessment
statuses, and implementation details with system owners and other authorized individuals
from:
• Interconnected systems within the organization,
• Systems inheriting common controls, and
• External organizations participating in approved information exchanges.
Relevant control assessment status information may also be shared in support of information
exchanges with external organizations.
Information that is relevant to the preparation, planning, and execution of control assessments
can be restricted to prevent the inadvertent release of system information by third-party
assessors. Assessors may be given limited access to input assessment results and artifacts
directly into the information management tool to generate assessment reports.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 3.3.3. System Plan Information Management

3.3.3. System Plan Information Management

Automation facilitates system plan information management throughout the system life cycle,
including:
• Tracking changes to system plan elements, including control implementations,
agreements for information exchanges, POA&Ms, and supporting roles
• Managing specific configuration settings on defined components within a system or
across all systems within the organization to facilitate continuous monitoring reporting
• Alerting organizational leaders and system management of changes or inconsistencies in
the collected system plan information
• Generating system plans using organization-approved templates to minimize the
duplication of element-specific content (e.g., system description, system environment,
identification of roles related to risk management or system operations)
Automation can be particularly useful in assessing and continuously monitoring controls
throughout the system life cycle. Storing system plan data in machine-readable formats can
facilitate updates to control implementation details due to assessment results, control catalog
or baseline updates, and other system changes. For example, POA&Ms for "other than
satisfied" findings in a machine-readable assessment report can trigger updates to system plans
and other system artifacts that are stored within a central repository.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 3.3.4. System Plan Information Protection

3.3.4. System Plan Information Protection

Organizations determine the level of protection required for system plan element information
based on the system's information types [SP800-60v2] and organizational requirements.
Centralized access control policies in an organization-wide information management tool can
manage logical access to information about the system to:
• Limit the visibility of information about the system to specific access holders based on
their management role
• Ensure that only authorized users can update system information, review change
records, and approve changes that have been made
Additional access controls can be applied to prevent unauthorized access to the system's
weakness and vulnerability information. Organization- and system-specific policies may further
control access to technical details about the system, such as IP addresses, vulnerability
information, and architectural designs.
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4. System Plan Development Through the Risk Management Framework Steps

4. System Plan Development Through the Risk Management Framework Steps

The following subsections provide organizational leadership and risk managers with a broader
understanding of each RMF step in relation to the development and maintenance of system
plans. The RMF provides a methodology for managing system risks using organizational policies
and system-level procedures to support system plan development, including responsibilities,
ongoing reviews and updates, the approval of system plans, and assessments of control
implementations. Fig. 2 shows the seven steps of the RMF.
Fig. 2. NIST Risk Management Framework Steps
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.1. Prepare

4.1. Prepare

System plans support organization- and system-level risk management strategies, including
regulatory and compliance obligations that define system-level requirements. To enable
oversight and promote accountability, the plans designate individuals with roles and
responsibilities for security, privacy, and supply chain risk management, such as those identified
in [SP800-37] Appendix D, Roles and Responsibilities. These roles align with broader
organizational information security and privacy program plans [SP800-37] and the C-SCRM
strategy and implementation plan [SP800-161] for consistency across all systems within the
organization.
Common control providers develop system plan artifacts that identify and provide
implementation details for inheritable common controls. A common control plan describes
privacy protections (e.g., data minimization, transparency, consent management) and identifies
systems outside of the authorization boundary as a common control provider from which
implemented controls are inherited. Inherent relationships with common control providers may
be based on specific operational relationships with service providers in the supply chain.
Organizations may develop tailored control baselines for systems with specialized or
unconventional mission, business, or operational requirements to provide details that are
incorporated into system plans, including:
• Predetermined organization-defined parameter (ODP) values for control assignment and
selection operations
• Additional controls, control enhancements, and compensating controls to address
organization-specific risks
• Supplemental scoping information to explain the applicability of the tailored controls to
specialized system, system element, or component operations based on security and
privacy assumptions
Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Jeremy Miller2, Julie Snyder > 4.2. Categorize

4.2. Categorize

The system's [FIPS199] security categorization reflects potential adverse impacts of the loss of
confidentiality, integrity, or availability; determines the [FIPS200] minimum security
requirements; and supports the RMF Select step. Security categorization information in the
system plan provides the rationale for categorization decisions, including privacy and C-SCRM
impacts [SP800-60v2]. Approving the security categorization may require additional input from
the senior agency official for privacy and the senior procurement official.
To account for both privacy and security risks in system plans, impact levels for each
information type reflect potential adverse impacts on organizational operations and assets and
the privacy of individuals whose data is processed by the system. Privacy impacts are informed
by other risk management activities and documentation, such as PIAs, SORNs, MOUs, and the
NIST PRAM.
The C-SCRM plan is generally developed for high- and moderate-impact systems, as indicated in
[SP800-161]. However, there is value in developing the C-SCRM plan to protect low-impact
systems as well, particularly if the low-impact system uses the same components found in high-
and moderate-impact systems. In the absence of a C-SCRM plan for a low-impact system, the
system security plan can identify the inheritance of C-SCRM controls from organization-level
common control providers, enumerate organizational and system risk tolerances, and
demonstrate the acceptance versus the transfer or mitigation of cybersecurity supply chain
risks via system-specific controls.