SA-8(19)—Security and Privacy Engineering Principles | Continuous Protection
>Control Description
>DoD Impact Level Requirements
No specific parameter values or requirements for this impact level.
>Discussion
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.
>Related Controls
>Assessment Interview Topics
Questions assessors commonly ask
Process & Governance:
- •What acquisition policies and procedures address the requirements of SA-8(19)?
- •How are security and privacy requirements integrated into the acquisition process?
- •Who is responsible for ensuring that acquisitions comply with SA-8(19)?
Technical Implementation:
- •How are security requirements defined and documented in acquisition contracts?
- •What mechanisms ensure that acquired systems and services meet security requirements?
- •How do you validate that vendors and service providers comply with specified security controls?
Evidence & Documentation:
- •Can you provide examples of acquisition documentation that includes security requirements?
- •What evidence demonstrates that acquired systems meet security specifications?
- •Where is acquisition security documentation maintained throughout the system lifecycle?
Ask AI
Configure your API key to use AI features.