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

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

The principle of continuous protection states that components and data used to enforce the security policy have uninterrupted protection that is consistent with the security policy and the security architecture assumptions. No assurances that the system can provide the confidentiality, integrity, availability, and privacy protections for its design capability can be made if there are gaps in the protection. Any assurances about the ability to secure a delivered capability require that data and information are continuously protected. That is, there are no periods during which data and information are left unprotected while under control of the system (i.e., during the creation, storage, processing, or communication of the data and information, as well as during system initialization, execution, failure, interruption, and shutdown). Continuous protection requires adherence to the precepts of the reference monitor concept (i.e., every request is validated by the reference monitor; the reference monitor is able to protect itself from tampering; and sufficient assurance of the correctness and completeness of the mechanism can be ascertained from analysis and testing) and the principle of secure failure and recovery (i.e., preservation of a secure state during error, fault, failure, and successful attack; preservation of a secure state during recovery to normal, degraded, or alternative operational modes).

Continuous protection also applies to systems designed to operate in varying configurations, including those that deliver full operational capability and degraded-mode configurations that deliver partial operational capability. The continuous protection principle requires that changes to the system security policies be traceable to the operational need that drives the configuration and be verifiable (i.e., it is possible to verify that the proposed changes will not put the system into an insecure state). Insufficient traceability and verification may lead to inconsistent states or protection discontinuities due to the complex or undecidable nature of the problem. The use of pre-verified configuration definitions that reflect the new security policy enables analysis to determine that a transition from old to new policies is essentially atomic and that any residual effects from the old policy are guaranteed to not conflict with the new policy. The ability to demonstrate continuous protection is rooted in the clear articulation of life cycle protection needs as stakeholder security requirements.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(19)

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

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

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

The principle of secure metadata management states that metadata are "first class" objects with respect to security policy when the policy requires either complete protection of information or that the security subsystem be self-protecting. The principle of secure metadata management is driven by the recognition that a system, subsystem, or component cannot achieve self-protection unless it protects the data it relies on for correct execution. Data is generally not interpreted by the system that stores it. It may have semantic value (i.e., it comprises information) to users and programs that process the data. In contrast, metadata is information about data, such as a file name or the date when the file was created. Metadata is bound to the target data that it describes in a way that the system can interpret, but it need not be stored inside of or proximate to its target data. There may be metadata whose target is itself metadata (e.g., the classification level or impact level of a file name), including self-referential metadata.

The apparent secondary nature of metadata can lead to neglect of its legitimate need for protection, resulting in a violation of the security policy that includes the exfiltration of information. A particular concern associated with insufficient protections for metadata is associated with multilevel secure (MLS) systems. MLS systems mediate access by a subject to an object based on relative sensitivity levels. It follows that all subjects and objects in the scope of control of the MLS system are either directly labeled or indirectly attributed with sensitivity levels. The corollary of labeled metadata for MLS systems states that objects containing metadata are labeled. As with protection needs assessments for data, attention is given to ensure that the confidentiality and integrity protections are individually assessed, specified, and allocated to metadata, as would be done for mission, business, and system data.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(20)

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

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

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

The principle of self-analysis states that a system component is able to assess its internal state and functionality to a limited extent at various stages of execution, and that this self-analysis capability is commensurate with the level of trustworthiness invested in the system. At the system level, self-analysis can be achieved through hierarchical assessments of trustworthiness established in a bottom-up fashion. In this approach, the lower-level components check for data integrity and correct functionality (to a limited extent) of higher-level components. For example, trusted boot sequences involve a trusted lower-level component that attests to the trustworthiness of the next higher-level components so that a transitive chain of trust can be established. At the root, a component attests to itself, which usually involves an axiomatic or environmentally enforced assumption about its integrity. Results of the self-analyses can be used to guard against externally induced errors, internal malfunction, or transient errors. By following this principle, some simple malfunctions or errors can be detected without allowing the effects of the error or malfunction to propagate outside of the component. Further, the self-test can be used to attest to the configuration of the component, detecting any potential conflicts in configuration with respect to the expected configuration.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(21)

SA-8(21) Security and Privacy Engineering Principles | Self-analysis
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

The principle of accountability and traceability states that it is possible to trace security-relevant actions (i.e., subject-object interactions) to the entity on whose behalf the action is being taken. The principle of accountability and traceability requires a trustworthy infrastructure that can record details about actions that affect system security (e.g., an audit subsystem). To record the details about actions, the system is able to uniquely identify the entity on whose behalf the action is being carried out and also record the relevant sequence of actions that are carried out. The accountability policy also requires that audit trail itself be protected from unauthorized access and modification. The principle of least privilege assists in tracing the actions to particular entities, as it increases the granularity of accountability. Associating specific actions with system entities, and ultimately with users, and making the audit trail secure against unauthorized access and modifications provide non-repudiation because once an action is recorded, it is not possible to change the audit trail. Another important function that accountability and traceability serves is in the routine and forensic analysis of events associated with the violation of security policy. Analysis of audit logs may provide additional information that may be helpful in determining the path or component that allowed the violation of the security policy and the actions of individuals associated with the violation of the security policy.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(22)

SA-8(22) Security and Privacy Engineering Principles | Accountability and Traceability
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

The principle of secure defaults states that the default configuration of a system (including its constituent subsystems, components, and mechanisms) reflects a restrictive and conservative enforcement of security policy. The principle of secure defaults applies to the initial (i.e., default) configuration of a system as well as to the security engineering and design of access control and other security functions that follow a "deny unless explicitly authorized" strategy. The initial configuration aspect of this principle requires that any "as shipped" configuration of a system, subsystem, or system component does not aid in the violation of the security policy and can prevent the system from operating in the default configuration for those cases where the security policy itself requires configuration by the operational user.

Restrictive defaults mean that the system will operate "as-shipped" with adequate self-protection and be able to prevent security breaches before the intended security policy and system configuration is established. In cases where the protection provided by the "as-shipped" product is inadequate, stakeholders assess the risk of using it prior to establishing a secure initial state. Adherence to the principle of secure defaults guarantees that a system is established in a secure state upon successfully completing initialization. In situations where the system fails to complete initialization, either it will perform a requested operation using secure defaults or it will not perform the operation. Refer to the principles of continuous protection and secure failure and recovery that parallel this principle to provide the ability to detect and recover from failure.

The security engineering approach to this principle states that security mechanisms deny requests unless the request is found to be well-formed and consistent with the security policy. The insecure alternative is to allow a request unless it is shown to be inconsistent with the policy. In a large system, the conditions that are satisfied to grant a request that is denied by default are often far more compact and complete than those that would need to be checked in order to deny a request that is granted by default.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(23)

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

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

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

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

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

The principle of economic security states that security mechanisms are not costlier than the potential damage that could occur from a security breach. This is the security-relevant form of the cost-benefit analyses used in risk management. The cost assumptions of cost-benefit analysis prevent the system designer from incorporating security mechanisms of greater strength than necessary, where strength of mechanism is proportional to cost. The principle of economic security also requires analysis of the benefits of assurance relative to the cost of that assurance in terms of the effort expended to obtain relevant and credible evidence as well as the necessary analyses to assess and draw trustworthiness and risk conclusions from the evidence.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(25)

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

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

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

The principle of performance security states that security mechanisms are constructed so that they do not degrade system performance unnecessarily. Stakeholder and system design requirements for performance and security are precisely articulated and prioritized. For the system implementation to meet its design requirements and be found acceptable to stakeholders (i.e., validation against stakeholder requirements), the designers adhere to the specified constraints that capability performance needs place on protection needs. The overall impact of computationally intensive security services (e.g., cryptography) are assessed and demonstrated to pose no significant impact to higher-priority performance considerations or are deemed to provide an acceptable trade-off of performance for trustworthy protection. The trade-off considerations include less computationally intensive security services unless they are unavailable or insufficient. The insufficiency of a security service is determined by functional capability and strength of mechanism. The strength of mechanism is selected with respect to security requirements, performance-critical overhead issues (e.g., cryptographic key management), and an assessment of the capability of the threat.

The principle of performance security leads to the incorporation of features that help in the enforcement of security policy but incur minimum overhead, such as low-level hardware mechanisms upon which higher-level services can be built. Such low-level mechanisms are usually very specific, have very limited functionality, and are optimized for performance. For example, once access rights to a portion of memory is granted, many systems use hardware mechanisms to ensure that all further accesses involve the correct memory address and access mode. Application of this principle reinforces the need to design security into the system from the ground up and to incorporate simple mechanisms at the lower layers that can be used as building blocks for higher-level mechanisms.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(26)

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

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

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

The principle of human factored security states that the user interface for security functions and supporting services is intuitive, user-friendly, and provides feedback for user actions that affect such policy and its enforcement. The mechanisms that enforce security policy are not intrusive to the user and are designed not to degrade user efficiency. Security policy enforcement mechanisms also provide the user with meaningful, clear, and relevant feedback and warnings when insecure choices are being made. Particular attention is given to interfaces through which personnel responsible for system administration and operation configure and set up the security policies. Ideally, these personnel are able to understand the impact of their choices. Personnel with system administrative and operational responsibilities are able to configure systems before start-up and administer them during runtime with confidence that their intent is correctly mapped to the system's mechanisms. Security services, functions, and mechanisms do not impede or unnecessarily complicate the intended use of the system. There is a trade-off between system usability and the strictness necessary for security policy enforcement. If security mechanisms are frustrating or difficult to use, then users may disable them, avoid them, or use them in ways inconsistent with the security requirements and protection needs that the mechanisms were designed to satisfy.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(27)

SA-8(27) Security and Privacy Engineering Principles | Human Factored Security
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

The principle of acceptable security requires that the level of privacy and performance that the system provides is consistent with the users' expectations. The perception of personal privacy may affect user behavior, morale, and effectiveness. Based on the organizational privacy policy and the system design, users should be able to restrict their actions to protect their privacy. When systems fail to provide intuitive interfaces or meet privacy and performance expectations, users may either choose to completely avoid the system or use it in ways that may be inefficient or even insecure.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(28)

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

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

SA-8(29) Repeatable and Documented Procedures - Discussion
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

The principle of repeatable and documented procedures states that the techniques and methods employed to construct a system component permit the same component to be completely and correctly reconstructed at a later time. Repeatable and documented procedures support the development of a component that is identical to the component created earlier, which may be in widespread use. In the case of other system artifacts (e.g., documentation and testing results), repeatability supports consistency and the ability to inspect the artifacts. Repeatable and documented procedures can be introduced at various stages within the system development life cycle and contribute to the ability to evaluate assurance claims for the system. Examples include systematic procedures for code development and review, procedures for the configuration management of development tools and system artifacts, and procedures for system delivery.
Security and Privacy Controls for Information Systems and Organizations
SA > SA-8 > SA-8(29)

SA-8(29) Security and Privacy Engineering Principles | Repeatable and Documented Procedures
Family: System and Services Acquisition (SA) > SA-8 Security and Privacy Engineering Principles

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

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

The principle of procedural rigor states that the rigor of a system life cycle process is commensurate with its intended trustworthiness. Procedural rigor defines the scope, depth, and detail of the system life cycle procedures. Rigorous system life cycle procedures contribute to the assurance that the system is correct and free of unintended functionality in several ways. First, the procedures impose checks and balances on the life cycle process such that the introduction of unspecified functionality is prevented.

Second, rigorous procedures applied to systems security engineering activities that produce specifications and other system design documents contribute to the ability to understand the system as it has been built rather than trusting that the component, as implemented, is the authoritative (and potentially misleading) specification.

Finally, modifications to an existing system component are easier when there are detailed specifications that describe its current design instead of studying source code or schematics to try to understand how it works. Procedural rigor helps ensure that security functional and assurance requirements have been satisfied, and it contributes to a better-informed basis for the determination of trustworthiness and risk posture. Procedural rigor is commensurate with the degree of assurance desired for the system. If the required trustworthiness of the system is low, a high level of procedural rigor may add unnecessary cost, whereas when high trustworthiness is critical, the cost of high procedural rigor is merited.