ezesecops/rmf-ato-core huggingface dataset:
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(5)

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

Require the developer of the system, system component, or system service to:
(a) Deliver the system, component, or service with [Assignment: organization-defined security configurations] implemented; and
(b) Use the configurations as the default for any subsequent system, component, or service reinstallation or upgrade.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(6) > Discussion

SA-4(6) Use of Information Assurance Products - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Commercial off-the-shelf IA or IA-enabled information technology products used to protect classified information by cryptographic means may be required to use NSA-approved key management. See [NSA CSFC](#3d575737-98cb-459d-b41c-d7e82b73ad78).
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(6)

SA-4(6) Acquisition Process | Use of Information Assurance Products
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

(a) Employ only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and
(b) Ensure that these products have been evaluated and/or validated by NSA or in accordance with NSA-approved procedures.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(7) > Discussion

SA-4(7) NIAP-approved Protection Profiles - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

See [NIAP CCEVS](#795aff72-3e6c-4b6b-a80a-b14d84b7f544) for additional information on NIAP. See [NIST CMVP](#1acdc775-aafb-4d11-9341-dc6a822e9d38) for additional information on FIPS-validated cryptographic modules.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(7)

SA-4(7) Acquisition Process | NIAP-approved Protection Profiles
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

(a) Limit the use of commercially provided information assurance and information assurance-enabled information technology products to those products that have been successfully evaluated against a National Information Assurance partnership (NIAP)-approved Protection Profile for a specific technology type, if such a profile exists; and
(b) Require, if no NIAP-approved Protection Profile exists for a specific technology type but a commercially provided information technology product relies on cryptographic functionality to enforce its security policy, that the cryptographic module is FIPS-validated or NSA-approved.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(8) > Discussion

SA-4(8) Continuous Monitoring Plan for Controls - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

The objective of continuous monitoring plans is to determine if the planned, required, and deployed controls within the system, system component, or system service continue to be effective over time based on the inevitable changes that occur. Developer continuous monitoring plans include a sufficient level of detail such that the information can be incorporated into continuous monitoring programs implemented by organizations. Continuous monitoring plans can include the types of control assessment and monitoring activities planned, frequency of control monitoring, and actions to be taken when controls fail or become ineffective.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(8)

SA-4(8) Acquisition Process | Continuous Monitoring Plan for Controls
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Require the developer of the system, system component, or system service to produce a plan for continuous monitoring of control effectiveness that is consistent with the continuous monitoring program of the organization.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(9) > Discussion

SA-4(9) Functions, Ports, Protocols, and Services in Use - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

The identification of functions, ports, protocols, and services early in the system development life cycle (e.g., during the initial requirements definition and design stages) allows organizations to influence the design of the system, system component, or system service. This early involvement in the system development life cycle helps organizations avoid or minimize the use of functions, ports, protocols, or services that pose unnecessarily high risks and understand the trade-offs involved in blocking specific ports, protocols, or services or requiring system service providers to do so. Early identification of functions, ports, protocols, and services avoids costly retrofitting of controls after the system, component, or system service has been implemented. [SA-9](#sa-9) describes the requirements for external system services. Organizations identify which functions, ports, protocols, and services are provided from external sources.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(9)

SA-4(9) Acquisition Process | Functions, Ports, Protocols, and Services in Use
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(10) > Discussion

SA-4(10) Use of Approved PIV Products - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Products on the FIPS 201-approved products list meet NIST requirements for Personal Identity Verification (PIV) of Federal Employees and Contractors. PIV cards are used for multi-factor authentication in systems and organizations.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(10)

SA-4(10) Acquisition Process | Use of Approved PIV Products
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(11) > Discussion

SA-4(11) System of Records - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

When, by contract, an organization provides for the operation of a system of records to accomplish an organizational mission or function, the organization, consistent with its authority, causes the requirements of the [PRIVACT](#18e71fec-c6fd-475a-925a-5d8495cf8455) to be applied to the system of records.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(11)

SA-4(11) Acquisition Process | System of Records
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Include [Assignment: organization-defined Privacy Act requirements] in the acquisition contract for the operation of a system of records on behalf of an organization to accomplish an organizational mission or function.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(12) > Discussion

SA-4(12) Data Ownership - Discussion
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

Contractors who operate a system that contains data owned by an organization initiating the contract have policies and procedures in place to remove the data from their systems and/or return the data in a time frame defined by the contract.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-4 > SA-4(12)

SA-4(12) Acquisition Process | Data Ownership
Family: System and Services Acquisition (SA) > SA-4 Acquisition Process

(a) Include organizational data ownership requirements in the acquisition contract; and
(b) Require all data to be removed from the contractor's system and returned to the organization within [Assignment: organization-defined time frame].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-5

SA-5 System Documentation
Family: System and Services Acquisition (SA)

a. Obtain or develop administrator documentation for the system, system component, or system service that describes:
1. Secure configuration, installation, and operation of the system, component, or service;
2. Effective use and maintenance of security and privacy functions and mechanisms; and
3. Known vulnerabilities regarding configuration and use of administrative or privileged functions;
b. Obtain or develop user documentation for the system, system component, or system service that describes:
1. User-accessible security and privacy functions and mechanisms and how to effectively use those functions and mechanisms;
2. Methods for user interaction, which enables individuals to use the system, component, or service in a more secure manner and protect individual privacy; and
3. User responsibilities in maintaining the security of the system, component, or service and privacy of individuals;
c. Document attempts to obtain system, system component, or system service documentation when such documentation is either unavailable or nonexistent and take [Assignment: organization-defined actions] in response; and
d. Distribute documentation to [Assignment: organization-defined personnel or roles].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-5 > Discussion

SA-5 System Documentation - Discussion
Family: System and Services Acquisition (SA)

System artifacts and documentation created by the developer helps organizational personnel understand the implementation and operation of controls. Organizations consider establishing specific measures to determine the quality and completeness of the content provided. System documentation may be used to delineate roles, responsibilities and expectations of the developer and organization, support the management of supply chain risk, incident response, flaw remediation, and other functions. Personnel or roles that require documentation include system owners, system security officers, and system administrators. Attempts to obtain documentation include contacting manufacturers or suppliers and conducting web-based searches. The inability to obtain documentation may occur due to the age of the system or component or the lack of support from developers and contractors. When documentation cannot be obtained, organizations may need to recreate the documentation if it is essential to the implementation or operation of the controls. The protection provided for the documentation is commensurate with the security category or classification of the system. Documentation that addresses system vulnerabilities may require an increased level of protection. Secure operation of the system includes initially starting the system and resuming secure system operation after a lapse in system operation. An example of least privilege in software development is minimizing the functions that operate with elevated privileges (e.g., limiting the tools and functionality that operate in kernel mode)
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8

SA-8 Security and Privacy Engineering Principles
Family: System and Services Acquisition (SA)

Apply the following systems security and privacy engineering principles in the specification, design, development, implementation, and modification of the system and system components: [Assignment: organization-defined organization-defined systems security and privacy engineering principles].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > Discussion

SA-8 Security and Privacy Engineering Principles - Discussion
Family: System and Services Acquisition (SA)

Systems security and privacy engineering principles are closely related to and implemented throughout the system development life cycle (see [SA-3](#sa-3) ). Organizations can apply systems security and privacy engineering principles to new systems under development or to systems undergoing upgrades. For existing systems, organizations apply systems security and privacy engineering principles to system upgrades and modifications to the extent feasible, given the current state of hardware, software, and firmware components within those systems.

The application of systems security and privacy engineering principles helps organizations develop trustworthy, secure, and resilient systems and reduces the susceptibility to disruptions, hazards, threats, and the creation of privacy problems for individuals. Examples of system security engineering principles include: developing layered protections; establishing security and privacy policies, architecture, and controls as the foundation for design and development; incorporating security and privacy requirements into the system development life cycle; delineating physical and logical security boundaries; ensuring that developers are trained on how to build secure software; tailoring controls to meet organizational needs; and performing threat modeling to identify use cases, threat agents, attack vectors and patterns, design patterns, and compensating controls needed to mitigate risk.

Organizations that apply systems security and privacy engineering concepts and principles can facilitate the development of trustworthy, secure systems, system components, and system services; reduce risk to acceptable levels; and make informed risk management decisions. System security engineering principles can also be used to protect against certain supply chain risks, including incorporating tamper-resistant hardware into a design.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(1) > Discussion

SA-8(1) Clear Abstractions - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of clear abstractions states that a system has simple, well-defined interfaces and functions that provide a consistent and intuitive view of the data and how the data is managed. The clarity, simplicity, necessity, and sufficiency of the system interfaces- combined with a precise definition of their functional behavior-promotes ease of analysis, inspection, and testing as well as the correct and secure use of the system. The clarity of an abstraction is subjective. Examples that reflect the application of this principle include avoidance of redundant, unused interfaces; information hiding; and avoidance of semantic overloading of interfaces or their parameters. Information hiding (i.e., representation-independent programming), is a design discipline used to ensure that the internal representation of information in one system component is not visible to another system component invoking or calling the first component, such that the published abstraction is not influenced by how the data may be managed internally.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(1)

SA-8(1) Security and Privacy Engineering Principles | Clear Abstractions
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

Implement the security design principle of clear abstractions.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(2) > Discussion

SA-8(2) Least Common Mechanism - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of least common mechanism states that the amount of mechanism common to more than one user and depended on by all users is minimized [POPEK74](#79453f84-26a4-4995-8257-d32d37aefea3) . Mechanism minimization implies that different components of a system refrain from using the same mechanism to access a system resource. Every shared mechanism (especially a mechanism involving shared variables) represents a potential information path between users and is designed with care to ensure that it does not unintentionally compromise security [SALTZER75](#c9495d6e-ef64-4090-8509-e58c3b9009ff) . Implementing the principle of least common mechanism helps to reduce the adverse consequences of sharing the system state among different programs. A single program that corrupts a shared state (including shared variables) has the potential to corrupt other programs that are dependent on the state. The principle of least common mechanism also supports the principle of simplicity of design and addresses the issue of covert storage channels [LAMPSON73](#d1cdab13-4218-400d-91a9-c3818dfa5ec8).
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(2)

SA-8(2) Security and Privacy Engineering Principles | Least Common Mechanism
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

Implement the security design principle of least common mechanism in [Assignment: organization-defined systems or system components].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(3) > Discussion

SA-8(3) Modularity and Layering - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principles of modularity and layering are fundamental across system engineering disciplines. Modularity and layering derived from functional decomposition are effective in managing system complexity by making it possible to comprehend the structure of the system. Modular decomposition, or refinement in system design, is challenging and resists general statements of principle. Modularity serves to isolate functions and related data structures into well-defined logical units. Layering allows the relationships of these units to be better understood so that dependencies are clear and undesired complexity can be avoided. The security design principle of modularity extends functional modularity to include considerations based on trust, trustworthiness, privilege, and security policy. Security-informed modular decomposition includes the allocation of policies to systems in a network, separation of system applications into processes with distinct address spaces, allocation of system policies to layers, and separation of processes into subjects with distinct privileges based on hardware-supported privilege domains.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(3)

SA-8(3) Security and Privacy Engineering Principles | Modularity and Layering
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

Implement the security design principles of modularity and layering in [Assignment: organization-defined organization-defined systems or system components].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(4) > Discussion

SA-8(4) Partially Ordered Dependencies - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of partially ordered dependencies states that the synchronization, calling, and other dependencies in the system are partially ordered. A fundamental concept in system design is layering, whereby the system is organized into well-defined, functionally related modules or components. The layers are linearly ordered with respect to inter-layer dependencies, such that higher layers are dependent on lower layers. While providing functionality to higher layers, some layers can be self-contained and not dependent on lower layers. While a partial ordering of all functions in a given system may not be possible, if circular dependencies are constrained to occur within layers, the inherent problems of circularity can be more easily managed. Partially ordered dependencies and system layering contribute significantly to the simplicity and coherency of the system design. Partially ordered dependencies also facilitate system testing and analysis.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(4)

SA-8(4) Security and Privacy Engineering Principles | Partially Ordered Dependencies
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

Implement the security design principle of partially ordered dependencies in [Assignment: organization-defined systems or system components].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(5) > Discussion

SA-8(5) Efficiently Mediated Access - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of efficiently mediated access states that policy enforcement mechanisms utilize the least common mechanism available while satisfying stakeholder requirements within expressed constraints. The mediation of access to system resources (i.e., CPU, memory, devices, communication ports, services, infrastructure, data, and information) is often the predominant security function of secure systems. It also enables the realization of protections for the capability provided to stakeholders by the system. Mediation of resource access can result in performance bottlenecks if the system is not designed correctly. For example, by using hardware mechanisms, efficiently mediated access can be achieved. Once access to a low-level resource such as memory has been obtained, hardware protection mechanisms can ensure that out-of-bounds access does not occur.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(5)

SA-8(5) Security and Privacy Engineering Principles | Efficiently Mediated Access
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

Implement the security design principle of efficiently mediated access in [Assignment: organization-defined systems or system components].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(6) > Discussion

SA-8(6) Minimized Sharing - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of minimized sharing states that no computer resource is shared between system components (e.g., subjects, processes, functions) unless it is absolutely necessary to do so. Minimized sharing helps to simplify system design and implementation. In order to protect user-domain resources from arbitrary active entities, no resource is shared unless that sharing has been explicitly requested and granted. The need for resource sharing can be motivated by the design principle of least common mechanism in the case of internal entities or driven by stakeholder requirements. However, internal sharing is carefully designed to avoid performance and covert storage and timing channel problems. Sharing via common mechanism can increase the susceptibility of data and information to unauthorized access, disclosure, use, or modification and can adversely affect the inherent capability provided by the system. To minimize sharing induced by common mechanisms, such mechanisms can be designed to be reentrant or virtualized to preserve separation. Moreover, the use of global data to share information is carefully scrutinized. The lack of encapsulation may obfuscate relationships among the sharing entities.