On 6/29/12 5:45 PM, Willy Santos wrote:
CCI-000024 requires the OS to prevent access to security-relevant information except during non-operable system states (e.g. maintenance windows, etc.). This mapping is open to discussion and change.

SRG-OS-000008 CCI-000024 The operating system must prevent access to organization-defined security-relevant information except during secure, non-operable system states. Security-relevant information is any information within the information system potentially impacting the operation of security functions in a manner that could result in failure to enforce the system security policy or maintain isolation of code and data. Organizations may define specific security relevant information requiring protection. Filtering rules for routers and firewalls, cryptographic key management information, key configuration parameters for security services, and access control lists are examples of security-relevant information. Secure, non-operable system states are states in which the information system is not performing mission/business-related processing (e.g., the system is off-line for maintenance, troubleshooting, boot-up, shutdown). Access to these types of data is to be prevented unless the system is in a maintenance mode or has otherwise been brought off-line. The goal is to minimize the potential that a security configuration or data may be dynamically and perhaps surreptitiously overwritten or changed (without going through a formal system change process documenting the changes).


IMHO, this belongs to unmet_impractical_guidance as it conflicts with other requirements stating that we have to be able dynamically adjust the system. I'd also map this to unmet_impractical_product as it's impractical at this point of Linux's maturity to completely change the access policies to prevent system adjustments unless in runlevel 1 (which I see as the only true way to truly enforce something like this, which requires "non-operable system state").