Re: auditd configuration for PCI DSS 10.2.x Compliance

[Steve Grubb <sgrubb@redhat.com>]

On Monday, January 15, 2018 9:52:07 AM EST Joshua Ammons wrote:
> Hello All,
> 
> Just thought I'd give this one more shot to see if anyone had any comments
> on my prior message (see below)?  Any input you have would be greatly
> appreciated.  I won't bother the group any more on this topic.

Not sure if you noticed, but the audit system ships with a PCI set of rules.
# rpm -ql audit | grep pci
/usr/share/doc/audit/rules/30-pci-dss-v31.rules


> I was wondering if anyone had any experience putting together an auditd
> configuration to meet PCI DSS 10.2.x requirements?  Below are the
> requirements and my thoughts for each one...if anyone has anything that
> they have done I'd love to hear it!
> 
> 10.2.2    All actions taken by any individual with root or administrative
> privileges
> 
> *         Enable the pam_tty_audit.so shared library in
> /etc/pam.d/[su/sudo/sudo-i/su-l] files.
> 
> o   USER_TTY event type will contain all commands from privileged user.
> 
> *         Add following lines to /etc/audit/rules.d/audit.rules file:
> 
> o   # Audit all actions by any individual with root or administrative
> privileges
> 
> o   -a exit,always -F arch=b64 -F euid=0 -S execve -k root-commands
> 
> o   -a exit,always -F arch=b32 -F euid=0 -S execve -k root-commands

The above is best done by TTY auditing.

 
> ?  EXECVE event type will contain all commands from user with elevated
> privileges.
> 
> ?  Question: with the pam_tty_audit.so enabled, and those commands being
> logged to USER_TTY events...is this rule needed also? 

No. And you would want to add -F auid >= 1000  -F auid != -1 if you were 
keeping it.

> 10.2.3    Access to all audit trails
> *         I'm not sure the best route to cover this one.  If I add a rule
> to watch /var/log/* for 'wa' actions, those logs are constantly being
> written to so that would be too noisy I believe. Does anyone know how I
> would form a rule that would fire when a file within /var/log is accessed
> directly by a user?  Also, if the user makes any manual changes, such as
> deleting a file or modifying its contents? 

Its not too noisy. Check the rules for this in the pci file. It picks up 
everything.

> 10.2.4    Invalid logical access attempts
> 
> *         Based on my understanding, this wouldn't really be covered by
> auditd, but by the standard authpriv facility.  Anybody configure anything
> in auditd to cover this requirement? 

pam probably covers this.

> 10.2.5    Use of and changes to identification and authentication
> mechanisms-including but not limited to creation of new accounts and
> elevation of privileges-and all changes, additions, or deletions to
> accounts with root or administrative privileges

Put a watch on passwd & group and shadow-utils does the rest.
 
> *         CRED_ACQ (sudo) and USER_AUTH (su) events should contain when a
> user sudo's or su's to privileged account.  My understanding is that these
> would not require any extra rules to be written.  However, I'm not quite
> sure how to handle the requirements to log creation of new accounts, and
> all changes, or deletions to accounts with root/admin privileges...any
> ideas?

Shadow utils covers this.

> 10.2.6.   Initialization, stopping, or pausing of the audit logs
> 
> *         Auditd:
> 
> o   DAEMON_END events would indicate auditd was stopped.
> 
> o   DAEMON_START and SERVICE_START events would indicate when auditd
> initialized.
> 
> o   Anything else anybody would add here?
> 
> *         Rsyslog:
> 
> o   SERVICE_START event (unit=rsyslog) when rsyslog is initialized
> 
> o   SERVICE_STOP event (unit=rsyslog) when rsyslog is stopped
> 
> o   Anything else anybody would add here?
> 10.2.7    Creation and deletion of system- level objects
> 
> *         -w [DIRECTORY] -p wa rules for the directories below:
> 
> o   /bin
> 
> o   /sbin
> 
> o   /usr/bin
> 
> o   /usr/sbin
> 
> o   /var/lib
> 
> o   /usr/lib
> 
> o   /usr/libexec
> 
> o   /lib64
> 
> o   /usr/lib64
> 
> ?  Would the above cover this requirement?  Any other suggestions here?

This will probably make you very unhappy when you do yum update. But you can 
add those rules.

-Steve