9:27 a.m.
Thanks Kevin! I will take a look at this. Appreciate the feedback.
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
From: Boyce, Kevin P [US] (AS) [mailto:Kevin.Boyce@ngc.com]
Sent: Monday, January 15, 2018 9:14 AM
To: Joshua Ammons <Joshua.Ammons(a)walmart.com>; linux-audit(a)redhat.com
Subject: EXT: RE: auditd configuration for PCI DSS 10.2.x Compliance
I'm assuming you need PCI compliance?
You might look at the oscap tools that are part of the distribution. They may have
scripts prepared that satisfy most if not all of the PCI requirements.
Assuming you are using RHEL...
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
oscap info /usr/share/xml/scap/content/ssg-rhel7-ds.xml lists that there is a pci-dss
profile available. When you scan your system and generate a report it will typically list
out the scripts required to fix many of the findings. You can keep running the
report/scanning function over to see if you got the changes right (your score should
increase between iterations).
I typically run oscap xccdf eval --results ~/results.xml --report ~/report.html --profile
xccdf_org.ssgproject.content_profile_pcid-dss
/usr/share/xml/scap/content/ssg-rhel7-ds.xml
You can view the report in firefox and expand through the results it should be pretty self
explanatory.
I'd recommend testing everything in a non-production environment before implementing.
Kevin
From: linux-audit-bounces@redhat.com<mailto:linux-audit-bounces@redhat.com>
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Joshua Ammons
Sent: Monday, January 15, 2018 9:52 AM
To: linux-audit@redhat.com<mailto:linux-audit@redhat.com>
Subject: EXT :RE: auditd configuration for PCI DSS 10.2.x Compliance
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.
Thank you!
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons@walmart.com<mailto:Joshua.Ammons@walmart.com>
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image001.png@01D38DE3.0434FB30]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
From: Joshua Ammons
Sent: Thursday, January 11, 2018 4:33 PM
To: 'linux-audit(a)redhat.com'
<linux-audit@redhat.com<mailto:linux-audit@redhat.com>>
Subject: auditd configuration for PCI DSS 10.2.x Compliance
Hello,
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
? 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?
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?
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?
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
* 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?
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?
Joshua Ammons Advanced SIEM Engineer, Cybersecurity
Global Business Services
Office 479.204.4472 | Mobile 479.595.2291
Joshua.Ammons@walmart.com<mailto:Joshua.Ammons@walmart.com>
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image002.png@01D38DE3.0434FB30]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
