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 <[email protected]>
---
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...
_______________________________________________
scap-security-guide mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/scap-security-guide
