[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