Yes, this would seem to map nicely to our rule for ensuring that rsyslog is on.
Updating in a subsequent commit would be fine (since the original got ACK'ed already). On 07/05/2012 05:20 PM, Shawn Wells wrote: > 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]> <mailto:[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 -- ___________________________ Jeffrey Blank 410-854-8675 Technology and Systems Analysis / Network Components NSA Information Assurance _______________________________________________ scap-security-guide mailing list [email protected] https://fedorahosted.org/mailman/listinfo/scap-security-guide
