auditd configuration for PCI DSS 10.2.x Compliance

Joshua Ammons Joshua.Ammons at
Mon Jan 15 15:55:59 UTC 2018

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

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

-----Original Message-----
From: Steve Grubb [mailto:sgrubb at] 
Sent: Monday, January 15, 2018 9:45 AM
To: linux-audit at
Cc: Joshua Ammons <Joshua.Ammons at>
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

> 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 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 enabled, and those commands 
> being logged to USER_TTY 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.


More information about the Linux-audit mailing list