RE: Re: auditd configuration for PCI DSS 10.2.x Compliance
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(a)walmart.com
WalmartÂ
805 Moberly Ln
Bentonville, ARÂ 72716
Save money. Live better.
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Monday, January 15, 2018 9:45 AM
To: linux-audit(a)redhat.com
Cc: Joshua Ammons <Joshua.Ammons(a)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