[PATCH 20/37] Mapped CCI-001500 to requirement_unclear.

Shawn Wells shawn at redhat.com
Sat Jul 7 01:22:30 UTC 2012


On 7/6/12 2:59 PM, Willy Santos wrote:
> CCI-001500 requires automatically implementing safeguards and countermeasures if security functions are changed inappropriately. This mapping is a request for input/discussion.
>
> Signed-off-by: Willy Santos <wsantos at redhat.com>
> ---
>   rhel6/src/input/auxiliary/srg_support.xml |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/rhel6/src/input/auxiliary/srg_support.xml b/rhel6/src/input/auxiliary/srg_support.xml
> index dab32c2..a087c24 100644
> --- a/rhel6/src/input/auxiliary/srg_support.xml
> +++ b/rhel6/src/input/auxiliary/srg_support.xml
> @@ -38,7 +38,7 @@ The requirement is impractical or out of scope.
>   <description>
>   It is unclear how to satisfy this requirement.
>   </description>
> -<ref disa="20,31,218,219,224,1097,1158,1291,1294,1295,1395,1428" />
> +<ref disa="20,31,218,219,224,1097,1158,1291,1294,1295,1395,1428,1500" />
>   </Group> <!-- end requirement_unclear -->
>   
>   <Group id="new_rule_needed">



SRG-OS-000260 	CCI-001500 	The operating system must automatically 
implement organization-defined safeguards and countermeasures if 
security functions (or mechanisms) are changed inappropriately. 	Any 
changes to the hardware, software, and/or firmware components of the 
operating system can potentially have significant effects on the overall 
security of the system. Accordingly, only qualified and authorized 
individuals must be allowed to obtain access to operating system 
components for purposes of initiating changes, including upgrades and 
modifications. In order to ensure a prompt response to unauthorized 
changes to application security functions or security mechanisms, 
organizations may define countermeasures and safeguards the operating 
system must undertake in the event these types of operating system 
changes occur.


IMHO Linux doesn't perform this very robustly. By design we allow 
hotswap of hardware, software, firmware, etc. The only way I see to 
fully enable this would be to mandate trusted boot / TPM technology. And 
I'm not sure if we (the industry/government/integrator) are ready for 
that yet.

Mobile devices are prohibited from connecting through other regulations, 
changes to the hardware require some sort of initialization (e.g. 
formatting the new disk drive), updating software requires admin rights 
which are audited, so I'd think we meet the foundational idea behind 
this requirement.... but I'd leave this as unclear until we can get 
further definition from DISA.

Maybe someone on the list can provide insight into what is really being 
asked here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://fedorahosted.org/pipermail/scap-security-guide/attachments/20120706/22c5b289/attachment.html>


More information about the scap-security-guide mailing list