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

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

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(7)

SA-8(7) Security and Privacy Engineering Principles | Reduced Complexity
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(8)

SA-8(8) Security and Privacy Engineering Principles | Secure Evolvability
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(9)

SA-8(9) Security and Privacy Engineering Principles | Trusted Components
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(10)

SA-8(10) Security and Privacy Engineering Principles | Hierarchical Trust
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

SA-8(11) Inverse Modification Threshold - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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).
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(11)

SA-8(11) Security and Privacy Engineering Principles | Inverse Modification Threshold
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(12)

SA-8(12) Security and Privacy Engineering Principles | Hierarchical Protection
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(13)

SA-8(13) Security and Privacy Engineering Principles | Minimized Security Elements
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(14)

SA-8(14) Security and Privacy Engineering Principles | Least Privilege
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(15)

SA-8(15) Security and Privacy Engineering Principles | Predicate Permission
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

SA-8(16) Self-reliant Trustworthiness - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(16)

SA-8(16) Security and Privacy Engineering Principles | Self-reliant Trustworthiness
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

SA-8(17) Secure Distributed Composition - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(17)

SA-8(17) Security and Privacy Engineering Principles | Secure Distributed Composition
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

SA-8(18) Trusted Communications Channels - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of trusted communication channels states that when composing a system where there is a potential threat to communications between components (i.e., the interconnections between components), each communication channel is trustworthy to a level commensurate with the security dependencies it supports (i.e., how much it is trusted by other components to perform its security functions). Trusted communication channels are achieved by a combination of restricting access to the communication channel (to ensure an acceptable match in the trustworthiness of the endpoints involved in the communication) and employing end-to-end protections for the data transmitted over the communication channel (to protect against interception and modification and to further increase the assurance of proper end-to-end communication).
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(18)

SA-8(18) Security and Privacy Engineering Principles | Trusted Communications Channels
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

Implement the security design principle of trusted communications channels in [Assignment: organization-defined systems or system components].