Browse 1,193 controls and enhancements across 20 security and privacy families. Use the GovRAMP crosswalk to locate controls referenced by Security Snapshot, Core, and Moderate.
A shared catalog supports common-control planning; designation as a common, hybrid, or system-specific control depends on your organization’s implementation and inheritance decisions.
System and Services Acquisition · Enhancement
SA-15(8) · Reuse of Threat and Vulnerability Information
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to use threat modeling and vulnerability analyses from similar systems, components, or services to inform the current development process.
Discussion
Analysis of vulnerabilities found in similar software applications can inform potential design and implementation issues for systems under development. Similar systems or system components may exist within developer organizations. Vulnerability information is available from a variety of public and private sector sources, including the NIST National Vulnerability Database.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-15(10) · Incident Response Plan
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to provide, implement, and test an incident response plan.
Discussion
The incident response plan provided by developers may provide information not readily available to organizations and be incorporated into organizational incident response plans. Developer information may also be extremely helpful, such as when organizations respond to vulnerabilities in commercial off-the-shelf products.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-15(11) · Archive System or Component
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system or system component to archive the system or component to be released or delivered together with the corresponding evidence supporting the final security and privacy review.
Discussion
Archiving system or system components requires the developer to retain key development artifacts, including hardware specifications, source code, object code, and relevant documentation from the development process that can provide a readily available configuration baseline for system and component upgrades or modifications.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-15(12) · Minimize Personally Identifiable Information
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system or system component to minimize the use of personally identifiable information in development and test environments.
Discussion
Organizations can minimize the risk to an individual’s privacy by using techniques such as de-identification or synthetic data. Limiting the use of personally identifiable information in development and test environments helps reduce the level of privacy risk created by a system.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-16 · Developer-provided Training
Control statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to provide the following training on the correct use and operation of the implemented security and privacy functions, controls, and/or mechanisms: [Assignment: training].
Discussion
Developer-provided training applies to external and internal (in-house) developers. Training personnel is essential to ensuring the effectiveness of the controls implemented within organizational systems. Types of training include web-based and computer-based training, classroom-style training, and hands-on training (including micro-training). Organizations can also request training materials from developers to conduct in-house training or offer self-training to organizational personnel. Organizations determine the type of training necessary and may require different types of training for different security and privacy functions, controls, and mechanisms.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-17 · Developer Security and Privacy Architecture and Design
Control statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:
a. Is consistent with the organization’s security and privacy architecture that is an integral part the organization’s enterprise architecture;
b. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and
c. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection.
Discussion
Developer security and privacy architecture and design are directed at external developers, although they could also be applied to internal (in-house) development. In contrast, [PL-8](#pl-8) is directed at internal developers to ensure that organizations develop a security and privacy architecture that is integrated with the enterprise architecture. The distinction between SA-17 and [PL-8](#pl-8) is especially important when organizations outsource the development of systems, system components, or system services and when there is a requirement to demonstrate consistency with the enterprise architecture and security and privacy architecture of the organization. [ISO 15408-2](#87087451-2af5-43d4-88c1-d66ad850f614), [ISO 15408-3](#4452efc0-e79e-47b8-aa30-b54f3ef61c2f) , and [SP 800-160-1](#e3cc0520-a366-4fc9-abc2-5272db7e3564) provide information on security architecture and design, including formal policy models, security-relevant components, formal and informal correspondence, conceptually simple design, and structuring for least privilege and testing.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(1) · Formal Policy Model
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
(a) Produce, as an integral part of the development process, a formal policy model describing the [Assignment: organization-defined elements of organizational security and privacy policy] to be enforced; and
(b) Prove that the formal policy model is internally consistent and sufficient to enforce the defined elements of the organizational security and privacy policy when implemented.
Discussion
Formal models describe specific behaviors or security and privacy policies using formal languages, thus enabling the correctness of those behaviors and policies to be formally proven. Not all components of systems can be modeled. Generally, formal specifications are scoped to the behaviors or policies of interest, such as nondiscretionary access control policies. Organizations choose the formal modeling language and approach based on the nature of the behaviors and policies to be described and the available tools.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(2) · Security-relevant Components
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
(a) Define security-relevant hardware, software, and firmware; and
(b) Provide a rationale that the definition for security-relevant hardware, software, and firmware is complete.
Discussion
The security-relevant hardware, software, and firmware represent the portion of the system, component, or service that is trusted to perform correctly to maintain required security properties.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(3) · Formal Correspondence
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
(a) Produce, as an integral part of the development process, a formal top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects;
(b) Show via proof to the extent feasible with additional informal demonstration as necessary, that the formal top-level specification is consistent with the formal policy model;
(c) Show via informal demonstration, that the formal top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;
(d) Show that the formal top-level specification is an accurate description of the implemented security-relevant hardware, software, and firmware; and
(e) Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the formal top-level specification but strictly internal to the security-relevant hardware, software, and firmware.
Discussion
Correspondence is an important part of the assurance gained through modeling. It demonstrates that the implementation is an accurate transformation of the model, and that any additional code or implementation details that are present have no impact on the behaviors or policies being modeled. Formal methods can be used to show that the high-level security properties are satisfied by the formal system description, and that the formal system description is correctly implemented by a description of some lower level, including a hardware description. Consistency between the formal top-level specification and the formal policy models is generally not amenable to being fully proven. Therefore, a combination of formal and informal methods may be needed to demonstrate such consistency. Consistency between the formal top-level specification and the actual implementation may require the use of an informal demonstration due to limitations on the applicability of formal methods to prove that the specification accurately reflects the implementation. Hardware, software, and firmware mechanisms internal to security-relevant components include mapping registers and direct memory input and output.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(4) · Informal Correspondence
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to:
(a) Produce, as an integral part of the development process, an informal descriptive top-level specification that specifies the interfaces to security-relevant hardware, software, and firmware in terms of exceptions, error messages, and effects;
(b) Show via [Selection (one): informal demonstration, convincing argument with formal methods as feasible] that the descriptive top-level specification is consistent with the formal policy model;
(c) Show via informal demonstration, that the descriptive top-level specification completely covers the interfaces to security-relevant hardware, software, and firmware;
(d) Show that the descriptive top-level specification is an accurate description of the interfaces to security-relevant hardware, software, and firmware; and
(e) Describe the security-relevant hardware, software, and firmware mechanisms not addressed in the descriptive top-level specification but strictly internal to the security-relevant hardware, software, and firmware.
Discussion
Correspondence is an important part of the assurance gained through modeling. It demonstrates that the implementation is an accurate transformation of the model, and that additional code or implementation detail has no impact on the behaviors or policies being modeled. Consistency between the descriptive top-level specification (i.e., high-level/low-level design) and the formal policy model is generally not amenable to being fully proven. Therefore, a combination of formal and informal methods may be needed to show such consistency. Hardware, software, and firmware mechanisms strictly internal to security-relevant hardware, software, and firmware include mapping registers and direct memory input and output.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(5) · Conceptually Simple Design
View parent controlControl statement and discussion
NIST control statement
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.
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(6) · Structure for Testing
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to structure security-relevant hardware, software, and firmware to facilitate testing.
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(7) · Structure for Least Privilege
View parent controlControl statement and discussion
NIST control statement
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.
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(8) · Orchestration
View parent controlControl statement and discussion
NIST control statement
Design [Assignment: critical systems] with coordinated behavior to implement the following capabilities: [Assignment: capabilities].
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Enhancement
SA-17(9) · Design Diversity
View parent controlControl statement and discussion
NIST control statement
Use different designs for [Assignment: critical systems] to satisfy a common set of requirements or to provide equivalent functionality.
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-20 · Customized Development of Critical Components
Control statement and discussion
NIST control statement
Reimplement or custom develop the following critical system components: [Assignment: critical system].
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-21 · Developer Screening
Control statement and discussion
NIST control statement
Require that the developer of [Assignment: system, systems component, or system service]:
a. Has appropriate access authorizations as determined by assigned [Assignment: official government duties] ; and
b. Satisfies the following additional personnel screening criteria: [Assignment: additional personnel screening criteria].
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Services Acquisition · Base control
SA-22 · Unsupported System Components
Control statement and discussion
NIST control statement
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: support from external providers] ].
Discussion
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-22 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Base control
SA-23 · Specialization
Control statement and discussion
NIST control statement
Employ [Selection (one-or-more): design modification; augmentation; reconfiguration] on [Assignment: systems or system components] supporting mission essential services or functions to increase the trustworthiness in those systems or components.
Discussion
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.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Communications Protection · Base control
SC-1 · Policy and Procedures
Control statement and discussion
NIST control statement
a. Develop, document, and disseminate to [Assignment: 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: 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: frequency] and following [Assignment: events] ; and
2. Procedures [Assignment: frequency] and following [Assignment: events].
Discussion
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SC-1 — Direct NIST identifier reference. GovRAMP source matrix
System and Communications Protection · Base control
SC-2 · Separation of System and User Functionality
Control statement and discussion
NIST control statement
Separate user functionality, including user interface services, from system management functionality.
Discussion
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).
GovRAMP crosswalk
- GovRAMP Core Readiness — 60 Controls · SC-2 — Direct NIST identifier reference. GovRAMP source matrix
- GovRAMP Moderate Readiness · SC-2 — Direct NIST identifier reference. GovRAMP source matrix
System and Communications Protection · Enhancement
SC-2(1) · Interfaces for Non-privileged Users
View parent controlControl statement and discussion
NIST control statement
Prevent the presentation of system management functionality at interfaces to non-privileged users.
Discussion
Preventing the presentation of system management functionality at interfaces to non-privileged users ensures that system administration options, including administrator privileges, are not available to the general user population. Restricting user access also prohibits the use of the grey-out option commonly used to eliminate accessibility to such information. One potential solution is to withhold system administration options until users establish sessions with administrator privileges.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Communications Protection · Enhancement
SC-2(2) · Disassociability
View parent controlControl statement and discussion
NIST control statement
Store state information from applications and software separately.
Discussion
If a system is compromised, storing applications and software separately from state information about users’ interactions with an application may better protect individuals’ privacy.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Communications Protection · Base control
SC-3 · Security Function Isolation
Control statement and discussion
NIST control statement
Isolate security functions from nonsecurity functions.
Discussion
Security functions are isolated from nonsecurity functions by means of an isolation boundary implemented within a system via partitions and domains. The isolation boundary controls access to and protects the integrity of the hardware, software, and firmware that perform system security functions. Systems implement code separation in many ways, such as through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that protect the code on disk and address space protections that protect executing code. Systems can restrict access to security functions using access control mechanisms and by implementing least privilege capabilities. While the ideal is for all code within the defined security function isolation boundary to only contain security-relevant code, it is sometimes necessary to include nonsecurity functions as an exception. The isolation of security functions from nonsecurity functions 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).
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
System and Communications Protection · Enhancement
SC-3(1) · Hardware Separation
View parent controlControl statement and discussion
NIST control statement
Employ hardware separation mechanisms to implement security function isolation.
Discussion
Hardware separation mechanisms include hardware ring architectures that are implemented within microprocessors and hardware-enforced address segmentation used to support logically distinct storage objects with separate attributes (i.e., readable, writeable).
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
