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

Jeffrey Blank blank at eclipse.ncsc.mil
Fri Jul 6 18:58:58 UTC 2012


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 <wsantos at redhat.com> <mailto: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...
> 
> 
> 
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/scap-security-guide

-- 
___________________________
Jeffrey Blank
410-854-8675
Technology and Systems Analysis / Network Components
NSA Information Assurance


More information about the scap-security-guide mailing list