auditd configuration for PCI DSS 10.2.x Compliance

[Joshua Ammons]

No, I did not notice that - that is awesome, thanks Steve!

Joshua Ammons Advanced SIEM Engineer, Cybersecurity 
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons at walmart.com

Walmart  
805 Moberly Ln
Bentonville, AR  72716
Save money. Live better.




-----Original Message-----
From: Steve Grubb [mailto:sgrubb at redhat.com] 
Sent: Monday, January 15, 2018 9:45 AM
To: linux-audit at redhat.com
Cc: Joshua Ammons <Joshua.Ammons at walmart.com>
Subject: EXT: Re: auditd configuration for PCI DSS 10.2.x Compliance

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