[PATCH 17/33] Mapped CCI-001311 to requirement_unclear.

Shawn Wells shawn at redhat.com
Thu Jul 5 21:20:47 UTC 2012


On 7/5/12 4:52 PM, Willy Santos wrote:
> CCI-001311 requires identifying potentially security-relevant error conditions. 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 2dff8d7..03cf83a 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,1239,1291,1294,1295,1310" />
> +<ref disa="20,31,218,219,224,1097,1158,1239,1291,1294,1295,1310,1311" />
>   </Group> <!-- end requirement_unclear -->
>   
>   <Group id="new_rule_needed">

SRG-OS-000204 	CCI-001311 	The operating system must identify 
potentially security-relevant error conditions. 	The structure and 
content of error messages need to be carefully considered by the 
organization. The extent to which the operating system is able to 
identify and handle error conditions is guided by organizational policy 
and operational requirements.



met_inherently via syslog message levels?

*DEBUG:*
Info useful to developers for debugging the application, not useful 
during operations

*INFORMATIONAL:*
Normal operational messages - may be harvested for reporting, measuring 
throughput, etc - no action required

*NOTICE:*
Events that are unusual but not error conditions - might be summarized 
in an email to developers or admins to spot potential problems - no 
immediate action required

*WARNING:*
Warning messages - not an error, but indication that an error will occur 
if action is not taken, e.g. file system 85% full - each item must be 
resolved within a given time

*ERROR:*
Non-urgent failures - these should be relayed to developers or admins; 
each item must be resolved within a given time

*ALERT:*
Should be corrected immediately - notify staff who can fix the problem - 
example is loss of backup ISP connection

*CRITICAL:*
Should be corrected immediately, but indicates failure in a primary 
system - fix CRITICAL problems before ALERT - example is loss of primary 
ISP connection

*EMERGENCY:*
A "panic" condition - notify all tech staff on call? (earthquake? 
tornado?) - affects multiple apps/servers/sites...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://fedorahosted.org/pipermail/scap-security-guide/attachments/20120705/82c1e2e5/attachment.html>


More information about the scap-security-guide mailing list