SA-8(12)—Security and Privacy Engineering Principles | Hierarchical Protection
>Control Description
>DoD Impact Level Requirements
No specific parameter values or requirements for this impact level.
>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.
>Assessment Interview Topics
Questions assessors commonly ask
Process & Governance:
- •What acquisition policies and procedures address the requirements of SA-8(12)?
- •How are security and privacy requirements integrated into the acquisition process?
- •Who is responsible for ensuring that acquisitions comply with SA-8(12)?
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.