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

SA-17(5) Conceptually Simple Design - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

The principle of reduced complexity states that the system design is as simple and small as possible (see [SA-8(7)](#sa-8.7) ). A small and simple design is easier to understand and analyze and is also less prone to error (see [AC-25](#ac-25), [SA-8(13)](#sa-8.13) ). The principle of reduced complexity applies to any aspect of a system, but it has particular importance for security due to the various analyses performed to obtain evidence about the emergent security property of the system. For such analyses to be successful, a small and simple design is essential. Application of the principle of reduced complexity contributes to the ability of system developers to understand the correctness and completeness of system security functions and facilitates the identification of potential vulnerabilities. The corollary of reduced complexity states that the simplicity of the system is directly related to the number of vulnerabilities it will contain. That is, simpler systems contain fewer vulnerabilities. An important benefit of reduced complexity is that it is easier to understand whether the security policy has been captured in the system design and that fewer vulnerabilities are likely to be introduced during engineering development. An additional benefit is that any such conclusion about correctness, completeness, and existence of vulnerabilities can be reached with a higher degree of assurance in contrast to conclusions reached in situations where the system design is inherently more complex.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(5)

SA-17(5) Developer Security and Privacy Architecture and Design | Conceptually Simple Design
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Require the developer of the system, system component, or system service to:
(a) Design and structure the security-relevant hardware, software, and firmware to use a complete, conceptually simple protection mechanism with precisely defined semantics; and
(b) Internally structure the security-relevant hardware, software, and firmware with specific regard for this mechanism.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(6) > Discussion

SA-17(6) Structure for Testing - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Applying the security design principles in [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) promotes complete, consistent, and comprehensive testing and evaluation of systems, system components, and services. The thoroughness of such testing contributes to the evidence produced to generate an effective assurance case or argument as to the trustworthiness of the system, system component, or service.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(6)

SA-17(6) Developer Security and Privacy Architecture and Design | Structure for Testing
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(7) > Discussion

SA-17(7) Structure for Least Privilege - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

The principle of least privilege states that each component is allocated sufficient privileges to accomplish its specified functions but no more (see [SA-8(14)](#sa-8.14) ). Applying the principle of least privilege limits the scope of the component's actions, which has two desirable effects. First, the security impact of a failure, corruption, or misuse of the system component results in a minimized security impact. Second, the security analysis of the component is simplified. Least privilege is a pervasive principle that is reflected in all aspects of the secure system design. Interfaces used to invoke component capability are available to only certain subsets of the user population, and component design supports a sufficiently fine granularity of privilege decomposition. For example, in the case of an audit mechanism, there may be an interface for the audit manager, who configures the audit settings; an interface for the audit operator, who ensures that audit data is safely collected and stored; and, finally, yet another interface for the audit reviewer, who only has a need to view the audit data that has been collected but no need to perform operations on that data.

In addition to its manifestations at the system interface, least privilege can be used as a guiding principle for the internal structure of the system itself. One aspect of internal least privilege is to construct modules so that only the elements encapsulated by the module are directly operated upon by the functions within the module. Elements external to a module that may be affected by the module's operation are indirectly accessed through interaction (e.g., via a function call) with the module that contains those elements. Another aspect of internal least privilege is that the scope of a given module or component includes only those system elements that are necessary for its functionality, and the access modes to the elements (e.g., read, write) are minimal.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(7)

SA-17(7) Developer Security and Privacy Architecture and Design | Structure for Least Privilege
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate controlling access with least privilege.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(8) > Discussion

SA-17(8) Orchestration - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Security resources that are distributed, located at different layers or in different system elements, or are implemented to support different aspects of trustworthiness can interact in unforeseen or incorrect ways. Adverse consequences can include cascading failures, interference, or coverage gaps. Coordination of the behavior of security resources (e.g., by ensuring that one patch is installed across all resources before making a configuration change that assumes that the patch is propagated) can avert such negative interactions.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(8)

SA-17(8) Developer Security and Privacy Architecture and Design | Orchestration
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Design [Assignment: organization-defined critical systems] with coordinated behavior to implement the following capabilities: [Assignment: organization-defined capabilities].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(9) > Discussion

SA-17(9) Design Diversity - Discussion
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Design diversity is achieved by supplying the same requirements specification to multiple developers, each of whom is responsible for developing a variant of the system or system component that meets the requirements. Variants can be in software design, in hardware design, or in both hardware and a software design. Differences in the designs of the variants can result from developer experience (e.g., prior use of a design pattern), design style (e.g., when decomposing a required function into smaller tasks, determining what constitutes a separate task and how far to decompose tasks into sub-tasks), selection of libraries to incorporate into the variant, and the development environment (e.g., different design tools make some design patterns easier to visualize). Hardware design diversity includes making different decisions about what information to keep in analog form and what information to convert to digital form, transmitting the same information at different times, and introducing delays in sampling (temporal diversity). Design diversity is commonly used to support fault tolerance.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-17 > SA-17(9)

SA-17(9) Developer Security and Privacy Architecture and Design | Design Diversity
Family: System and Services Acquisition (SA) > SA-17 Developer Security and Privacy Architecture and Design

Use different designs for [Assignment: organization-defined critical systems] to satisfy a common set of requirements or to provide equivalent functionality.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-20

SA-20 Customized Development of Critical Components
Family: System and Services Acquisition (SA)

Reimplement or custom develop the following critical system components: [Assignment: organization-defined critical system].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-20 > Discussion

SA-20 Customized Development of Critical Components - Discussion
Family: System and Services Acquisition (SA)

Organizations determine that certain system components likely cannot be trusted due to specific threats to and vulnerabilities in those components for which there are no viable security controls to adequately mitigate risk. Reimplementation or custom development of such components may satisfy requirements for higher assurance and is carried out by initiating changes to system components (including hardware, software, and firmware) such that the standard attacks by adversaries are less likely to succeed. In situations where no alternative sourcing is available and organizations choose not to reimplement or custom develop critical system components, additional controls can be employed. Controls include enhanced auditing, restrictions on source code and system utility access, and protection from deletion of system and application files.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-21

SA-21 Developer Screening
Family: System and Services Acquisition (SA)

Require that the developer of [Assignment: organization-defined system, systems component, or system service]:
a. Has appropriate access authorizations as determined by assigned [Assignment: organization-defined official government duties] ; and
b. Satisfies the following additional personnel screening criteria: [Assignment: organization-defined additional personnel screening criteria].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-21 > Discussion

SA-21 Developer Screening - Discussion
Family: System and Services Acquisition (SA)

Developer screening is directed at external developers. Internal developer screening is addressed by [PS-3](#ps-3) . Because the system, system component, or system service may be used in critical activities essential to the national or economic security interests of the United States, organizations have a strong interest in ensuring that developers are trustworthy. The degree of trust required of developers may need to be consistent with that of the individuals who access the systems, system components, or system services once deployed. Authorization and personnel screening criteria include clearances, background checks, citizenship, and nationality. Developer trustworthiness may also include a review and analysis of company ownership and relationships that the company has with entities that may potentially affect the quality and reliability of the systems, components, or services being developed. Satisfying the required access authorizations and personnel screening criteria includes providing a list of all individuals who are authorized to perform development activities on the selected system, system component, or system service so that organizations can validate that the developer has satisfied the authorization and screening requirements.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-22

SA-22 Unsupported System Components
Family: System and Services Acquisition (SA)

a. Replace system components when support for the components is no longer available from the developer, vendor, or manufacturer; or
b. Provide the following options for alternative sources for continued support for unsupported components [Selection; one or more: in-house support; [Assignment: organization-defined support from external providers] ].
Security and Privacy Controls for Information Systems and Organizations
SA > SA-22 > Discussion

SA-22 Unsupported System Components - Discussion
Family: System and Services Acquisition (SA)

Support for system components includes software patches, firmware updates, replacement parts, and maintenance contracts. An example of unsupported components includes when vendors no longer provide critical software patches or product updates, which can result in an opportunity for adversaries to exploit weaknesses in the installed components. Exceptions to replacing unsupported system components include systems that provide critical mission or business capabilities where newer technologies are not available or where the systems are so isolated that installing replacement components is not an option.

Alternative sources for support address the need to provide continued support for system components that are no longer supported by the original manufacturers, developers, or vendors when such components remain essential to organizational mission and business functions. If necessary, organizations can establish in-house support by developing customized patches for critical software components or, alternatively, obtain the services of external providers who provide ongoing support for the designated unsupported components through contractual relationships. Such contractual relationships can include open-source software value-added vendors. The increased risk of using unsupported system components can be mitigated, for example, by prohibiting the connection of such components to public or uncontrolled networks, or implementing other forms of isolation.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-23

SA-23 Specialization
Family: System and Services Acquisition (SA)

Employ [Selection; one or more: design modification; augmentation; reconfiguration] on [Assignment: organization-defined systems or system components] supporting mission essential services or functions to increase the trustworthiness in those systems or components.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-23 > Discussion

SA-23 Specialization - Discussion
Family: System and Services Acquisition (SA)

It is often necessary for a system or system component that supports mission-essential services or functions to be enhanced to maximize the trustworthiness of the resource. Sometimes this enhancement is done at the design level. In other instances, it is done post-design, either through modifications of the system in question or by augmenting the system with additional components. For example, supplemental authentication or non-repudiation functions may be added to the system to enhance the identity of critical resources to other resources that depend on the organization-defined resources.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-24

SA-24 Design For Cyber Resiliency
Family: System and Services Acquisition (SA)

a. Design organizational systems, system components, or system services to achieve cyber resiliency by:
1. Defining the following cyber resiliency goals: [Assignment: organization-defined cyber resiliency goals].
2. Defining the following cyber resiliency objectives: [Assignment: organization-defined cyber resiliency objectives].
3. Defining the following cyber resiliency techniques: [Assignment: organization-defined cyber resiliency techniques].
4. Defining the following cyber resiliency implementation approaches: [Assignment: organization-defined cyber resiliency implementation approaches].
5. Defining the following cyber resiliency design principles: [Assignment: organization-defined cyber resiliency design principles].
b. Implement the selected cyber resiliency goals, objectives, techniques, implementation approaches, and design principles as part of an organizational risk management process or systems security engineering process.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-24 > Discussion

SA-24 Design For Cyber Resiliency - Discussion
Family: System and Services Acquisition (SA)

Cyber resiliency is critical to ensuring the survivability of mission critical systems and high value assets. Cyber resiliency focuses on limiting the damage from adversity or the conditions that can cause a loss of assets. Damage can affect: (1) organizations (e.g., loss of reputation, increased existential risk); (2) missions or business functions (e.g., decreased capability to complete current missions and to accomplish future missions); (3) security (e.g., decreased capability to achieve security objectives or to prevent, detect, and respond to cyber incidents); (4) systems (e.g., unauthorized use of system resources or decreased capability to meet system requirements); or (5) specific system elements (e.g., physical destruction; corruption, modification, or fabrication of information).

Cyber resiliency goals are intended to help organizations maintain a state of informed preparedness for adversity, continue essential mission or business functions despite adversity, restore mission or business functions during and after adversity, and modify mission or business functions and their supporting capabilities in response to predicted changes in technical, operational, or threat environments.

NIST SP 800-160, Volume 2 provides additional information on the Cyber Resiliency Engineering Framework to include detailed descriptions of cyber resiliency goals, objectives, techniques, implementation approaches, and design principles. NIST SP 800-160, Vol 1 provides additional information on achieving cyber resiliency as an emergent property of an engineered system.
Security and Privacy Controls for Information Systems and Organizations
SC > SC-1

SC-1 Policy and Procedures
Family: System and Communications Protection (SC)

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 communications protection 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 communications protection policy and the associated system and communications protection controls;
b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and
c. Review and update the current system and communications protection:
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
SC > SC-1 > Discussion

SC-1 Policy and Procedures - Discussion
Family: System and Communications Protection (SC)

System and communications protection policy and procedures address the controls in the SC 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 communications protection 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 communications protection policy and procedures include assessment or audit findings, security incidents or breaches, or changes in applicable 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
SC > SC-2

SC-2 Separation of System and User Functionality
Family: System and Communications Protection (SC)

Separate user functionality, including user interface services, from system management functionality.
Security and Privacy Controls for Information Systems and Organizations
SC > SC-2 > Discussion

SC-2 Separation of System and User Functionality - Discussion
Family: System and Communications Protection (SC)

System management functionality includes functions that are necessary to administer databases, network components, workstations, or servers. These functions typically require privileged user access. The separation of user functions from system management functions is physical or logical. Organizations may separate system management functions from user functions by using different computers, instances of operating systems, central processing units, or network addresses; by employing virtualization techniques; or some combination of these or other methods. Separation of system management functions from user functions includes web administrative interfaces that employ separate authentication methods for users of any other system resources. Separation of system and user functions may include isolating administrative interfaces on different domains and with additional access controls. The separation of system and user functionality can be achieved by applying the systems security engineering design principles in [SA-8](#sa-8) , including [SA-8(1)](#sa-8.1), [SA-8(3)](#sa-8.3), [SA-8(4)](#sa-8.4), [SA-8(10)](#sa-8.10), [SA-8(12)](#sa-8.12), [SA-8(13)](#sa-8.13), [SA-8(14)](#sa-8.14) , and [SA-8(18)](#sa-8.18).