| name | SA-8(21)_self-analysis |
| description | Implement the security design principle of self-analysis in [organization-defined]. |
| category | configuration |
| version | 5.2.0 |
| author | cyberstrike-official |
| tags | ["nist","sp800-53","rev5","sa-8-21","sa","enhancement"] |
| tech_stack | ["any"] |
| cwe_ids | ["CWE-16"] |
| chains_with | ["CA-7"] |
| prerequisites | ["SA-8"] |
| severity_boost | {"CA-7":"Chain with CA-7 for comprehensive security coverage"} |
SA-8(21) Self-analysis
Enhancement of: SA-8
High-Level Description
Family: System and Services Acquisition (SA)
Framework: NIST SP 800-53 Rev 5
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.
What to Check
How to Test
Step 1: Review Documentation
Examine the System Security Plan (SSP) and related artifacts for SA-8(21) implementation details. Verify the organization has documented how this control is satisfied.
Step 2: Validate Implementation
# For cloud environments, use cloud-audit-mcp tools
# For on-premises, review system configurations directly
# Example: Check if account management policies exist
grep -r "account.management\|access.control" /etc/security/ 2>/dev/null
Step 3: Test Operating Effectiveness
Verify the control is actively functioning, not just documented. Check logs, configurations, and operational evidence.
Tools