[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