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@redhat.com]
Sent: Tuesday, October 04, 2011 9:18 AM
To: Worsham, Michael
Cc: linux-audit(a)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.