auditd configuration for PCI DSS 10.2.x Compliance

Tue Jan 16 08:49:20 UTC 2018

Hi Joshua,

A few minor things for your consideration :

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?

Ensure that only root users have access to /var/log and you are already
monitoring actions of users using pam_tty_audit etc. Additionally you are
sending logs to remote servers which will ensure that logs are present on
the remote server even if they are deleted locally. And since user actions
are being monitored, you will also be able to know that logs were
modified/deleted.

10.2.7

In addition to what you have mentioned, I am sure you are already
monitoring these using a FIM like OSSEC.

Regards,

Shinoj.

*From:* linux-audit-bounces at redhat.com [mailto:
linux-audit-bounces at redhat.com] *On Behalf Of *Joshua Ammons
*Sent:* 15 January 2018 20:22
*To:* linux-audit at redhat.com
*Subject:* 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 at walmart.com <Joshua.Ammons at walmart.com>*

Walmart

805 Moberly Ln

Bentonville, AR  72716

*Save money. Live better.*

<https://walmart.facebook.com/groups/435932993428953/?fref=nf>

*From:* Joshua Ammons
*Sent:* Thursday, January 11, 2018 4:33 PM
*To:* 'linux-audit at redhat.com' <linux-audit at 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 at walmart.com <Joshua.Ammons at walmart.com>*

Walmart

805 Moberly Ln

Bentonville, AR  72716

*Save money. Live better.*

<https://walmart.facebook.com/groups/435932993428953/?fref=nf>

-- 

*DISCLAIMER* *: **The information and the attachments in this email may be 
confidential and legally privileged. Access to the contents of this message 
by anyone other than the intended recipient is unauthorized. If you are not 
the intended recipient, any disclosure , copying, or distribution of the 
message, or any action or omission taken by you in reliance on it, is 
prohibited and may be unlawful. If you have received this email message in 
error, please notify the sender immediately by email, facsimile, or 
telephone, and then delete/destroy the original message and all copies of 
it from your systems.*

*Wave Crest cannot guarantee this email communication and associated 
attachments to be free of malicious code and assumes no liability for any 
loss or injury resulting from the contents of the message. **The views 
expressed may not necessarily be those of *Wave Crest*, and unless 
otherwise noted in the text of the message, the message may not reflect 
official policy.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20180116/c3847753/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 6820 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20180116/c3847753/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 6810 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20180116/c3847753/attachment-0001.png>