ezesecops/rmf-ato-core huggingface dataset:
Security and Privacy Controls for Information Systems and Organizations
RA > RA-9 > Discussion

RA-9 Criticality Analysis - Discussion
Family: Risk Assessment (RA)

Not all system components, functions, or services necessarily require significant protections. For example, criticality analysis is a key tenet of supply chain risk management and informs the prioritization of protection activities. The identification of critical system components and functions considers applicable laws, executive orders, regulations, directives, policies, standards, system functionality requirements, system and component interfaces, and system and component dependencies. Systems engineers conduct a functional decomposition of a system to identify mission-critical functions and components. The functional decomposition includes the identification of organizational missions supported by the system, decomposition into the specific functions to perform those missions, and traceability to the hardware, software, and firmware components that implement those functions, including when the functions are shared by many components within and external to the system.

The operational environment of a system or a system component may impact the criticality, including the connections to and dependencies on cyber-physical systems, devices, system-of-systems, and outsourced IT services. System components that allow unmediated access to critical system components or functions are considered critical due to the inherent vulnerabilities that such components create. Component and function criticality are assessed in terms of the impact of a component or function failure on the organizational missions that are supported by the system that contains the components and functions.

Criticality analysis is performed when an architecture or design is being developed, modified, or upgraded. If such analysis is performed early in the system development life cycle, organizations may be able to modify the system design to reduce the critical nature of these components and functions, such as by adding redundancy or alternate paths into the system design. Criticality analysis can also influence the protection measures required by development contractors. In addition to criticality analysis for systems, system components, and system services, criticality analysis of information is an important consideration. Such analysis is conducted as part of security categorization in [RA-2](#ra-2).
Security and Privacy Controls for Information Systems and Organizations
RA > RA-10

RA-10 Threat Hunting
Family: Risk Assessment (RA)

a. Establish and maintain a cyber threat hunting capability to:
1. Search for indicators of compromise in organizational systems; and
2. Detect, track, and disrupt threats that evade existing controls; and
b. Employ the threat hunting capability [Assignment: organization-defined frequency].
Security and Privacy Controls for Information Systems and Organizations
RA > RA-10 > Discussion

RA-10 Threat Hunting - Discussion
Family: Risk Assessment (RA)

Threat hunting is an active means of cyber defense in contrast to traditional protection measures, such as firewalls, intrusion detection and prevention systems, quarantining malicious code in sandboxes, and Security Information and Event Management technologies and systems. Cyber threat hunting involves proactively searching organizational systems, networks, and infrastructure for advanced threats. The objective is to track and disrupt cyber adversaries as early as possible in the attack sequence and to measurably improve the speed and accuracy of organizational responses. Indications of compromise include unusual network traffic, unusual file changes, and the presence of malicious code. Threat hunting teams leverage existing threat intelligence and may create new threat intelligence, which is shared with peer organizations, Information Sharing and Analysis Organizations (ISAO), Information Sharing and Analysis Centers (ISAC), and relevant government departments and agencies.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-1

SA-1 Policy and Procedures
Family: System and Services Acquisition (SA)

a. Develop, document, and disseminate to [Assignment: organization-defined organization-defined personnel or roles]:
1. [Selection; one or more: organization-level; mission/business process-level; system-level] system and services acquisition policy that:
(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
(b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and
2. Procedures to facilitate the implementation of the system and services acquisition policy and the associated system and services acquisition controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the system and services acquisition policy and procedures; and
c. Review and update the current system and services acquisition:
1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events] ; and
2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-1 > Discussion

SA-1 Policy and Procedures - Discussion
Family: System and Services Acquisition (SA)

System and services acquisition policy and procedures address the controls in the SA family that are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on the development of system and services acquisition policy and procedures. Security and privacy program policies and procedures at the organization level are preferable, in general, and may obviate the need for mission- or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations. Procedures can be established for security and privacy programs, for mission or business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents. Events that may precipitate an update to system and services acquisition policy and procedures include assessment or audit findings, security incidents or breaches, or changes in laws, executive orders, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-2

SA-2 Allocation of Resources
Family: System and Services Acquisition (SA)

a. Determine the high-level information security and privacy requirements for the system or system service in mission and business process planning;
b. Determine, document, and allocate the resources required to protect the system or system service as part of the organizational capital planning and investment control process; and
c. Establish a discrete line item for information security and privacy in organizational programming and budgeting documentation.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-2 > Discussion

SA-2 Allocation of Resources - Discussion
Family: System and Services Acquisition (SA)

Resource allocation for information security and privacy includes funding for system and services acquisition, sustainment, and supply chain-related risks throughout the system development life cycle.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3

SA-3 System Development Life Cycle
Family: System and Services Acquisition (SA)

a. Acquire, develop, and manage the system using [Assignment: organization-defined system-development life cycle] that incorporates information security and privacy considerations;
b. Define and document information security and privacy roles and responsibilities throughout the system development life cycle;
c. Identify individuals having information security and privacy roles and responsibilities; and
d. Integrate the organizational information security and privacy risk management process into system development life cycle activities.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > Discussion

SA-3 System Development Life Cycle - Discussion
Family: System and Services Acquisition (SA)

A system development life cycle process provides the foundation for the successful development, implementation, and operation of organizational systems. The integration of security and privacy considerations early in the system development life cycle is a foundational principle of systems security engineering and privacy engineering. To apply the required controls within the system development life cycle requires a basic understanding of information security and privacy, threats, vulnerabilities, adverse impacts, and risk to critical mission and business functions. The security engineering principles in [SA-8](#sa-8) help individuals properly design, code, and test systems and system components. Organizations include qualified personnel (e.g., senior agency information security officers, senior agency officials for privacy, security and privacy architects, and security and privacy engineers) in system development life cycle processes to ensure that established security and privacy requirements are incorporated into organizational systems. Role-based security and privacy training programs can ensure that individuals with key security and privacy roles and responsibilities have the experience, skills, and expertise to conduct assigned system development life cycle activities.

The effective integration of security and privacy requirements into enterprise architecture also helps to ensure that important security and privacy considerations are addressed throughout the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with the risk management strategy of the organization. Because the system development life cycle involves multiple organizations, (e.g., external suppliers, developers, integrators, service providers), acquisition and supply chain risk management functions and controls play significant roles in the effective management of the system during the life cycle.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > SA-3(1) > Discussion

SA-3(1) Manage Preproduction Environment - Discussion
Family: System and Services Acquisition (SA) > SA-3 System Development Life Cycle

The preproduction environment includes development, test, and integration environments. The program protection planning processes established by the Department of Defense are examples of managing the preproduction environment for defense contractors. Criticality analysis and the application of controls on developers also contribute to a more secure system development environment.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > SA-3(1)

SA-3(1) System Development Life Cycle | Manage Preproduction Environment
Family: System and Services Acquisition (SA) > SA-3 System Development Life Cycle

Protect system preproduction environments commensurate with risk throughout the system development life cycle for the system, system component, or system service.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > SA-3(2) > Discussion

SA-3(2) Use of Live or Operational Data - Discussion
Family: System and Services Acquisition (SA) > SA-3 System Development Life Cycle

Live data is also referred to as operational data. The use of live or operational data in preproduction (i.e., development, test, and integration) environments can result in significant risks to organizations. In addition, the use of personally identifiable information in testing, research, and training increases the risk of unauthorized disclosure or misuse of such information. Therefore, it is important for the organization to manage any additional risks that may result from the use of live or operational data. Organizations can minimize such risks by using test or dummy data during the design, development, and testing of systems, system components, and system services. Risk assessment techniques may be used to determine if the risk of using live or operational data is acceptable.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > SA-3(2)

SA-3(2) System Development Life Cycle | Use of Live or Operational Data
Family: System and Services Acquisition (SA) > SA-3 System Development Life Cycle

(a) Approve, document, and control the use of live data in preproduction environments for the system, system component, or system service; and
(b) Protect preproduction environments for the system, system component, or system service at the same impact or classification level as any live data in use within the preproduction environments.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > SA-3(3) > Discussion

SA-3(3) Technology Refresh - Discussion
Family: System and Services Acquisition (SA) > SA-3 System Development Life Cycle

Technology refresh planning may encompass hardware, software, firmware, processes, personnel skill sets, suppliers, service providers, and facilities. The use of obsolete or nearing obsolete technology may increase the security and privacy risks associated with unsupported components, counterfeit or repurposed components, components unable to implement security or privacy requirements, slow or inoperable components, components from untrusted sources, inadvertent personnel error, or increased complexity. Technology refreshes typically occur during the operations and maintenance stage of the system development life cycle.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-3 > SA-3(3)

SA-3(3) System Development Life Cycle | Technology Refresh
Family: System and Services Acquisition (SA) > SA-3 System Development Life Cycle

Plan for and implement a technology refresh schedule for the system throughout the system development life cycle.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4

SA-4 Acquisition Process
Family: System and Services Acquisition (SA)

Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Selection; one or more: standardized contract language; [Assignment: organization-defined contract language] ] in the acquisition contract for the system, system component, or system service:
a. Security and privacy functional requirements;
b. Strength of mechanism requirements;
c. Security and privacy assurance requirements;
d. Controls needed to satisfy the security and privacy requirements.
e. Security and privacy documentation requirements;
f. Requirements for protecting security and privacy documentation;
g. Description of the system development environment and environment in which the system is intended to operate;
h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
i. Acceptance criteria.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > Discussion

SA-4 Acquisition Process - Discussion
Family: System and Services Acquisition (SA)

Security and privacy functional requirements are typically derived from the high-level security and privacy requirements described in [SA-2](#sa-2) . The derived requirements include security and privacy capabilities, functions, and mechanisms. Strength requirements associated with such capabilities, functions, and mechanisms include degree of correctness, completeness, resistance to tampering or bypass, and resistance to direct attack. Assurance requirements include development processes, procedures, and methodologies as well as the evidence from development and assessment activities that provide grounds for confidence that the required functionality is implemented and possesses the required strength of mechanism. [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) describes the process of requirements engineering as part of the system development life cycle.

Controls can be viewed as descriptions of the safeguards and protection capabilities appropriate for achieving the particular security and privacy objectives of the organization and for reflecting the security and privacy requirements of stakeholders. Controls are selected and implemented in order to satisfy system requirements and include developer and organizational responsibilities. Controls can include technical, administrative, and physical aspects. In some cases, the selection and implementation of a control may necessitate additional specification by the organization in the form of derived requirements or instantiated control parameter values. The derived requirements and control parameter values may be necessary to provide the appropriate level of implementation detail for controls within the system development life cycle.

Security and privacy documentation requirements address all stages of the system development life cycle. Documentation provides user and administrator guidance for the implementation and operation of controls. The level of detail required in such documentation is based on the security categorization or classification level of the system and the degree to which organizations depend on the capabilities, functions, or mechanisms to meet risk response expectations. Requirements can include mandated configuration settings that specify allowed functions, ports, protocols, and services. Acceptance criteria for systems, system components, and system services are defined in the same manner as the criteria for any organizational acquisition or procurement.

Organizations can determine other requirements that support security and operations, to include responsibilities for the organization and developer, and notification and timing requirements for support, maintenance and updates.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(1) > Discussion

SA-4(1) Functional Properties of Controls - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Functional properties of security and privacy controls describe the functionality (i.e., security or privacy capability, functions, or mechanisms) visible at the interfaces of the controls and specifically exclude functionality and data structures internal to the operation of the controls.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(1)

SA-4(1) Acquisition Process | Functional Properties of Controls
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Require the developer of the system, system component, or system service to provide a description of the functional properties of the controls to be implemented.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(2) > Discussion

SA-4(2) Design and Implementation Information for Controls - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Organizations may require different levels of detail in the documentation for the design and implementation of controls in organizational systems, system components, or system services based on mission and business requirements, requirements for resiliency and trustworthiness, and requirements for analysis and testing. Systems can be partitioned into multiple subsystems. Each subsystem within the system can contain one or more modules. The high-level design for the system is expressed in terms of subsystems and the interfaces between subsystems providing security-relevant functionality. The low-level design for the system is expressed in terms of modules and the interfaces between modules providing security-relevant functionality. Design and implementation documentation can include manufacturer, version, serial number, verification hash signature, software libraries used, date of purchase or download, and the vendor or download source. Source code and hardware schematics are referred to as the implementation representation of the system.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(2)

SA-4(2) Acquisition Process | Design and Implementation Information for Controls
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Require the developer of the system, system component, or system service to provide design and implementation information for the controls that includes: [Selection; one or more: security-relevant external system interfaces; high-level design; low-level design; source code or hardware schematics; [Assignment: organization-defined design and implementation information] ] at [Assignment: organization-defined level of detail].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(3) > Discussion

SA-4(3) Development Methods, Techniques, and Practices - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Following a system development life cycle that includes state-of-the-practice software development methods, systems engineering methods, systems security and privacy engineering methods, and quality control processes helps to reduce the number and severity of latent errors within systems, system components, and system services. Reducing the number and severity of such errors reduces the number of vulnerabilities in those systems, components, and services. Transparency in the methods and techniques that developers select and implement for systems engineering, systems security and privacy engineering, software development, component and system assessments, and quality control processes provides an increased level of assurance in the trustworthiness of the system, system component, or system service being acquired.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(3)

SA-4(3) Acquisition Process | Development Methods, Techniques, and Practices
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Require the developer of the system, system component, or system service to demonstrate the use of a system development life cycle process that includes:
(a) [Assignment: organization-defined systems engineering methods];
(b) [Selection; one or more: [Assignment: organization-defined system security engineering methods] ; [Assignment: organization-defined privacy engineering methods] ] ; and
(c) [Selection; one or more: [Assignment: organization-defined software development methods] ; [Assignment: organization-defined testing, evaluation, assessment, verification, and validation methods] ; [Assignment: organization-defined quality control processes] ].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(5) > Discussion

SA-4(5) System, Component, and Service Configurations - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Examples of security configurations include the U.S. Government Configuration Baseline (USGCB), Security Technical Implementation Guides (STIGs), and any limitations on functions, ports, protocols, and services. Security characteristics can include requiring that default passwords have been changed.