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").