Suppress messages from /var/log/audit.log via audit.rules

[Worsham, Michael]

SRR still shows this as a failure, using stig.rules contents for audit.rules:

GEN002720: UNIX STIG: 3.16 - The audit system is not configured to audit failed attempts to access files and programs.
AUDITING is NOT correctly CONFIGURED on va33-time.
Ensure that -a exit,always -S open -F success=0 is in /etc/audit/audit.rules on va33-time.
PDI Number: GEN002720
Finding Category: CAT II
Reference: UNIX STIG: 3.16
Description: The audit system is not configured to audit failed attempts to access files and programs.
Status: Open


Is there any documentation that says that the stig.rules file is compliant for GEN002720? The project security folks will only be looking at the SRR output, which says it's not.

We are using the rules as found here: https://fedorahosted.org/audit/browser/trunk/contrib/stig.rules

-- Michael


-----Original Message-----
From: Steve Grubb [mailto:sgrubb at redhat.com]
Sent: Tuesday, October 04, 2011 9:18 AM
To: Worsham, Michael
Cc: linux-audit at redhat.com
Subject: Re: Suppress messages from /var/log/audit.log via audit.rules

On Monday, October 03, 2011 10:36:31 PM Worsham, Michael wrote:
> About the rule that's 'killing' us (which I totally agree it is), this is
> what the stig.rules project says about it (GEN002720):
>
> 78    ## (GEN002720-GEN002840: CAT II) (Previously G100-G106) The SA will
> 79    ## configure the auditing system to audit the following events for
> all 80    ## users and root:
> 81    ##
> 82    ## - Logon (unsuccessful and successful) and logout (successful)
> 83    ##
> 84    ## Handled by pam, sshd, login, and gdm
>
> But here is what the latest version of the Unix checklist says the
> vulnerability is, and how to check if its mitigated:
>
> Unix Checklist v5r1-30 20110729
> 3.2.1.119
> PDI:  GEN002720   - Audit Failed File and Program Access Attempts
> PDI Description: The audit system is not configured to audit failed
> attempts to access files and programs. Reference: UNIX STIG: 3.16
> -  Linux

I'll have to double check the numbering. Things may have shifted since I wrote the
stig.rules file.


>    For LAUS:
>    # grep "@open-ops" /etc/audit/filter.conf
>
>    For auditd:
>    # grep "-a exit,always -S open -F success=0" /etc/audit.rules

This would appear that you are using an old stig.rules file. You might want to update
it.


> The two don't seem to jibe as to what the vulnerability is. I'm not sure
> how login, sshd, etc, can give information about failed attempts to access
> files.

The rules file is listing several requirements which has the rules in-between the
requirements. The first part is to satisfy the logon/off requirements. Farther down is
the unsuccessful access requirement.

> As to altering the rule, while I'm sure the results would be much more
> useful and relevant (you can tell DISA's thinking is out-of-date by the
> mitigation steps above), my only concern is that it would no longer be
> STIG compliant, or something that would always come up as a finding, that
> we would have to explain each time.

I occassionally chat with the DISA FSO people. The intent is the stig.rules file in the
audit package is compliant. I think they have altered the auditing requirements to
match what is shipped. But you just need to update to a newer version of the file.

-Steve

CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s).  This email may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.