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-4(7) · NIAP-approved Protection Profiles
View parent controlControl statement and discussion
NIST control statement
(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.
Discussion
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.
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-4(8) · Continuous Monitoring Plan for Controls
View parent controlControl statement and discussion
NIST control statement
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.
Discussion
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.
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-4(9) · Functions, Ports, Protocols, and Services in Use
View parent controlControl statement and discussion
NIST control statement
Require the developer of the system, system component, or system service to identify the functions, ports, protocols, and services intended for organizational use.
Discussion
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-4 (9) — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-4(10) · Use of Approved PIV Products
View parent controlControl statement and discussion
NIST control statement
Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.
Discussion
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.
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-4(11) · System of Records
View parent controlControl statement and discussion
NIST control statement
Include [Assignment: 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.
Discussion
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.
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-4(12) · Data Ownership
View parent controlControl statement and discussion
NIST control statement
(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: time frame].
Discussion
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.
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-5 · System Documentation
Control statement and discussion
NIST control statement
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: actions] in response; and
d. Distribute documentation to [Assignment: personnel or roles].
Discussion
System documentation helps 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 support the management of supply chain risk, incident response, 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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-5 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Base control
SA-8 · Security and Privacy Engineering Principles
Control statement and discussion
NIST control statement
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 systems security and privacy engineering principles].
Discussion
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.
GovRAMP crosswalk
- GovRAMP Moderate Readiness · SA-8 — Direct NIST identifier reference. GovRAMP source matrix
System and Services Acquisition · Enhancement
SA-8(1) · Clear Abstractions
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of clear abstractions.
Discussion
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.
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-8(2) · Least Common Mechanism
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of least common mechanism in [Assignment: systems or system components].
Discussion
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).
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-8(3) · Modularity and Layering
View parent controlControl statement and discussion
NIST control statement
Implement the security design principles of modularity and layering in [Assignment: organization-defined systems or system components].
Discussion
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.
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-8(4) · Partially Ordered Dependencies
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of partially ordered dependencies in [Assignment: systems or system components].
Discussion
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.
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-8(5) · Efficiently Mediated Access
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of efficiently mediated access in [Assignment: systems or system components].
Discussion
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.
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-8(6) · Minimized Sharing
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of minimized sharing in [Assignment: systems or system components].
Discussion
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.
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-8(7) · Reduced Complexity
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of reduced complexity in [Assignment: systems or system components].
Discussion
The principle of reduced complexity states that the system design is as simple and small as possible. A small and simple design is more understandable, more analyzable, and less prone to error. The reduced complexity principle 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. It also 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 benefit of reduced complexity is that it is easier to understand whether the intended 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 the 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. Transitioning from older technologies to newer technologies (e.g., transitioning from IPv4 to IPv6) may require implementing the older and newer technologies simultaneously during the transition period. This may result in a temporary increase in system complexity during the transition.
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-8(8) · Secure Evolvability
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of secure evolvability in [Assignment: systems or system components].
Discussion
The principle of secure evolvability states that a system is developed to facilitate the maintenance of its security properties when there are changes to the system’s structure, interfaces, interconnections (i.e., system architecture), functionality, or configuration (i.e., security policy enforcement). Changes include a new, enhanced, or upgraded system capability; maintenance and sustainment activities; and reconfiguration. Although it is not possible to plan for every aspect of system evolution, system upgrades and changes can be anticipated by analyses of mission or business strategic direction, anticipated changes in the threat environment, and anticipated maintenance and sustainment needs. It is unrealistic to expect that complex systems remain secure in contexts not envisioned during development, whether such contexts are related to the operational environment or to usage. A system may be secure in some new contexts, but there is no guarantee that its emergent behavior will always be secure. It is easier to build trustworthiness into a system from the outset, and it follows that the sustainment of system trustworthiness requires planning for change as opposed to adapting in an ad hoc or non-methodical manner. The benefits of this principle include reduced vendor life cycle costs, reduced cost of ownership, improved system security, more effective management of security risk, and less risk uncertainty.
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-8(9) · Trusted Components
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of trusted components in [Assignment: systems or system components].
Discussion
The principle of trusted components states that a component is trustworthy to at least a level commensurate with the security dependencies it supports (i.e., how much it is trusted to perform its security functions by other components). This principle enables the composition of components such that trustworthiness is not inadvertently diminished and the trust is not consequently misplaced. Ultimately, this principle demands some metric by which the trust in a component and the trustworthiness of a component can be measured on the same abstract scale. The principle of trusted components is particularly relevant when considering systems and components in which there are complex chains of trust dependencies. A trust dependency is also referred to as a trust relationship and there may be chains of trust relationships.
The principle of trusted components also applies to a compound component that consists of subcomponents (e.g., a subsystem), which may have varying levels of trustworthiness. The conservative assumption is that the trustworthiness of a compound component is that of its least trustworthy subcomponent. It may be possible to provide a security engineering rationale that the trustworthiness of a particular compound component is greater than the conservative assumption. However, any such rationale reflects logical reasoning based on a clear statement of the trustworthiness objectives as well as relevant and credible evidence. The trustworthiness of a compound component is not the same as increased application of defense-in-depth layering within the component or a replication of components. Defense-in-depth techniques do not increase the trustworthiness of the whole above that of the least trustworthy component.
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-8(10) · Hierarchical Trust
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of hierarchical trust in [Assignment: systems or system components].
Discussion
The principle of hierarchical trust for components builds on the principle of trusted components and states that the security dependencies in a system will form a partial ordering if they preserve the principle of trusted components. The partial ordering provides the basis for trustworthiness reasoning or an assurance case (assurance argument) when composing a secure system from heterogeneously trustworthy components. To analyze a system composed of heterogeneously trustworthy components for its trustworthiness, it is essential to eliminate circular dependencies with regard to the trustworthiness. If a more trustworthy component located in a lower layer of the system were to depend on a less trustworthy component in a higher layer, this would, in effect, put the components in the same "less trustworthy" equivalence class per the principle of trusted components. Trust relationships, or chains of trust, can have various manifestations. For example, the root certificate of a certificate hierarchy is the most trusted node in the hierarchy, whereas the leaves in the hierarchy may be the least trustworthy nodes. Another example occurs in a layered high-assurance system where the security kernel (including the hardware base), which is located at the lowest layer of the system, is the most trustworthy component. The principle of hierarchical trust, however, does not prohibit the use of overly trustworthy components. There may be cases in a system of low trustworthiness where it is reasonable to employ a highly trustworthy component rather than one that is less trustworthy (e.g., due to availability or other cost-benefit driver). For such a case, any dependency of the highly trustworthy component upon a less trustworthy component does not degrade the trustworthiness of the resulting low-trust 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 · Enhancement
SA-8(11) · Inverse Modification Threshold
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of inverse modification threshold in [Assignment: systems or system components].
Discussion
The principle of inverse modification threshold builds on the principle of trusted components and the principle of hierarchical trust and states that the degree of protection provided to a component is commensurate with its trustworthiness. As the trust placed in a component increases, the protection against unauthorized modification of the component also increases to the same degree. Protection from unauthorized modification can come in the form of the component’s own self-protection and innate trustworthiness, or it can come from the protections afforded to the component from other elements or attributes of the security architecture (to include protections in the environment of operation).
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-8(12) · Hierarchical Protection
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of hierarchical protection in [Assignment: systems or system components].
Discussion
The principle of hierarchical protection states that a component need not be protected from more trustworthy components. In the degenerate case of the most trusted component, it protects itself from all other components. For example, if an operating system kernel is deemed the most trustworthy component in a system, then it protects itself from all untrusted applications it supports, but the applications, conversely, do not need to protect themselves from the kernel. The trustworthiness of users is a consideration for applying the principle of hierarchical protection. A trusted system need not protect itself from an equally trustworthy user, reflecting use of untrusted systems in "system high" environments where users are highly trustworthy and where other protections are put in place to bound and protect the "system high" execution environment.
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-8(13) · Minimized Security Elements
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of minimized security elements in [Assignment: systems or system components].
Discussion
The principle of minimized security elements states that the system does not have extraneous trusted components. The principle of minimized security elements has two aspects: the overall cost of security analysis and the complexity of security analysis. Trusted components are generally costlier to construct and implement, owing to the increased rigor of development processes. Trusted components require greater security analysis to qualify their trustworthiness. Thus, to reduce the cost and decrease the complexity of the security analysis, a system contains as few trustworthy components as possible. The analysis of the interaction of trusted components with other components of the system is one of the most important aspects of system security verification. If the interactions between components are unnecessarily complex, the security of the system will also be more difficult to ascertain than one whose internal trust relationships are simple and elegantly constructed. In general, fewer trusted components result in fewer internal trust relationships and a simpler 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 · Enhancement
SA-8(14) · Least Privilege
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of least privilege in [Assignment: systems or system components].
Discussion
The principle of least privilege states that each system component is allocated sufficient privileges to accomplish its specified functions but no more. Applying the principle of least privilege limits the scope of the component’s actions, which has two desirable effects: the security impact of a failure, corruption, or misuse of the component will have a minimized security impact, and the security analysis of the component will be 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 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 on 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 that the access modes for 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-8(15) · Predicate Permission
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of predicate permission in [Assignment: systems or system components].
Discussion
The principle of predicate permission states that system designers consider requiring multiple authorized entities to provide consent before a highly critical operation or access to highly sensitive data, information, or resources is allowed to proceed. [SALTZER75](#c9495d6e-ef64-4090-8509-e58c3b9009ff) originally named predicate permission the separation of privilege. It is also equivalent to separation of duty. The division of privilege among multiple parties decreases the likelihood of abuse and provides the safeguard that no single accident, deception, or breach of trust is sufficient to enable an unrecoverable action that can lead to significantly damaging effects. The design options for such a mechanism may require simultaneous action (e.g., the firing of a nuclear weapon requires two different authorized individuals to give the correct command within a small time window) or a sequence of operations where each successive action is enabled by some prior action, but no single individual is able to enable more than one action.
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-8(16) · Self-reliant Trustworthiness
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of self-reliant trustworthiness in [Assignment: systems or system components].
Discussion
The principle of self-reliant trustworthiness states that systems minimize their reliance on other systems for their own trustworthiness. A system is trustworthy by default, and any connection to an external entity is used to supplement its function. If a system were required to maintain a connection with another external entity in order to maintain its trustworthiness, then that system would be vulnerable to malicious and non-malicious threats that could result in the loss or degradation of that connection. The benefit of the principle of self-reliant trustworthiness is that the isolation of a system will make it less vulnerable to attack. A corollary to this principle relates to the ability of the system (or system component) to operate in isolation and then resynchronize with other components when it is rejoined with them.
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-8(17) · Secure Distributed Composition
View parent controlControl statement and discussion
NIST control statement
Implement the security design principle of secure distributed composition in [Assignment: systems or system components].
Discussion
The principle of secure distributed composition states that the composition of distributed components that enforce the same system security policy result in a system that enforces that policy at least as well as the individual components do. Many of the design principles for secure systems deal with how components can or should interact. The need to create or enable a capability from the composition of distributed components can magnify the relevancy of these principles. In particular, the translation of security policy from a stand-alone to a distributed system or a system-of-systems can have unexpected or emergent results. Communication protocols and distributed data consistency mechanisms help to ensure consistent policy enforcement across a distributed system. To ensure a system-wide level of assurance of correct policy enforcement, the security architecture of a distributed composite system is thoroughly analyzed.
GovRAMP crosswalk
Not selected in the imported Snapshot or Core sets. This does not establish exclusion from other GovRAMP baselines.
