* RE: auditd configuration for PCI DSS 10.2.x Compliance
@ 2018-01-15 14:52 Joshua Ammons
2018-01-15 15:14 ` Boyce, Kevin P [US] (AS)
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Joshua Ammons @ 2018-01-15 14:52 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1.1: Type: text/plain, Size: 4276 bytes --]
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
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image001.png@01D38DDE.1EEEA9D0]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
From: Joshua Ammons
Sent: Thursday, January 11, 2018 4:33 PM
To: 'linux-audit@redhat.com' <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@01D38DDE.1EEEA9D0]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
[-- Attachment #1.1.2: Type: text/html, Size: 24209 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 6820 bytes --]
[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 6810 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread* RE: auditd configuration for PCI DSS 10.2.x Compliance
2018-01-15 14:52 auditd configuration for PCI DSS 10.2.x Compliance Joshua Ammons
@ 2018-01-15 15:14 ` Boyce, Kevin P [US] (AS)
2018-01-15 15:27 ` Joshua Ammons
2018-01-15 15:45 ` Steve Grubb
2018-01-16 8:49 ` Shinoj Gangadharan
2 siblings, 1 reply; 7+ messages in thread
From: Boyce, Kevin P [US] (AS) @ 2018-01-15 15:14 UTC (permalink / raw)
To: Joshua Ammons, linux-audit@redhat.com
[-- Attachment #1.1.1: Type: text/plain, Size: 5693 bytes --]
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/html/security_guide/sect-using_oscap
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] On Behalf Of Joshua Ammons
Sent: Monday, January 15, 2018 9:52 AM
To: 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@01D38DE8.9DD24A90]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
From: Joshua Ammons
Sent: Thursday, January 11, 2018 4:33 PM
To: 'linux-audit@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@01D38DE8.9DD24A90]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
[-- Attachment #1.1.2: Type: text/html, Size: 27326 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 6820 bytes --]
[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 6810 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: auditd configuration for PCI DSS 10.2.x Compliance
2018-01-15 15:14 ` Boyce, Kevin P [US] (AS)
@ 2018-01-15 15:27 ` Joshua Ammons
0 siblings, 0 replies; 7+ messages in thread
From: Joshua Ammons @ 2018-01-15 15:27 UTC (permalink / raw)
To: Boyce, Kevin P [US] (AS), linux-audit@redhat.com
[-- Attachment #1.1.1: Type: text/plain, Size: 6134 bytes --]
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@walmart.com>; linux-audit@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/html/security_guide/sect-using_oscap
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@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>
[-- Attachment #1.1.2: Type: text/html, Size: 28652 bytes --]
[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 6820 bytes --]
[-- Attachment #1.3: image002.png --]
[-- Type: image/png, Size: 6810 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: auditd configuration for PCI DSS 10.2.x Compliance
2018-01-15 14:52 auditd configuration for PCI DSS 10.2.x Compliance Joshua Ammons
2018-01-15 15:14 ` Boyce, Kevin P [US] (AS)
@ 2018-01-15 15:45 ` Steve Grubb
2018-01-15 15:55 ` Joshua Ammons
2018-01-16 8:49 ` Shinoj Gangadharan
2 siblings, 1 reply; 7+ messages in thread
From: Steve Grubb @ 2018-01-15 15:45 UTC (permalink / raw)
To: linux-audit
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: Re: auditd configuration for PCI DSS 10.2.x Compliance
2018-01-15 15:45 ` Steve Grubb
@ 2018-01-15 15:55 ` Joshua Ammons
0 siblings, 0 replies; 7+ messages in thread
From: Joshua Ammons @ 2018-01-15 15:55 UTC (permalink / raw)
To: Steve Grubb, linux-audit@redhat.com
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@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@redhat.com
Cc: Joshua Ammons <Joshua.Ammons@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: auditd configuration for PCI DSS 10.2.x Compliance
2018-01-15 14:52 auditd configuration for PCI DSS 10.2.x Compliance Joshua Ammons
2018-01-15 15:14 ` Boyce, Kevin P [US] (AS)
2018-01-15 15:45 ` Steve Grubb
@ 2018-01-16 8:49 ` Shinoj Gangadharan
2 siblings, 0 replies; 7+ messages in thread
From: Shinoj Gangadharan @ 2018-01-16 8:49 UTC (permalink / raw)
To: Joshua Ammons, linux-audit
[-- Attachment #1.1.1: Type: text/plain, Size: 6747 bytes --]
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@redhat.com [mailto:
linux-audit-bounces@redhat.com] *On Behalf Of *Joshua Ammons
*Sent:* 15 January 2018 20:22
*To:* linux-audit@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@walmart.com <Joshua.Ammons@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@redhat.com' <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 <Joshua.Ammons@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.*
[-- Attachment #1.1.2: Type: text/html, Size: 24740 bytes --]
[-- Attachment #1.2: image005.png --]
[-- Type: image/png, Size: 6820 bytes --]
[-- Attachment #1.3: image006.png --]
[-- Type: image/png, Size: 6810 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* auditd configuration for PCI DSS 10.2.x Compliance
@ 2018-01-11 22:33 Joshua Ammons
0 siblings, 0 replies; 7+ messages in thread
From: Joshua Ammons @ 2018-01-11 22:33 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1.1: Type: text/plain, Size: 3492 bytes --]
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
Walmart
805 Moberly Ln
Bentonville, AR 72716
Save money. Live better.
[cid:image002.png@01D38AF9.D79607E0]<https://walmart.facebook.com/groups/435932993428953/?fref=nf>
[-- Attachment #1.1.2: Type: text/html, Size: 21098 bytes --]
[-- Attachment #1.2: image002.png --]
[-- Type: image/png, Size: 6810 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-01-16 8:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-15 14:52 auditd configuration for PCI DSS 10.2.x Compliance Joshua Ammons
2018-01-15 15:14 ` Boyce, Kevin P [US] (AS)
2018-01-15 15:27 ` Joshua Ammons
2018-01-15 15:45 ` Steve Grubb
2018-01-15 15:55 ` Joshua Ammons
2018-01-16 8:49 ` Shinoj Gangadharan
-- strict thread matches above, loose matches on Subject: below --
2018-01-11 22:33 Joshua Ammons
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
![[-- Attachment #1.2: image001.png --] [-- Type: image/png, Size: 6820 bytes --]](../../c35aad32d256414ea9a71032790ccf76@XCGVAG30.northgrum.com/1.2-image001.png){kind=link}
![[-- Attachment #1.3: image002.png --] [-- Type: image/png, Size: 6810 bytes --]](../../c35aad32d256414ea9a71032790ccf76@XCGVAG30.northgrum.com/1.3-image002.png){kind=link}
![[-- Attachment #1.2: image001.png --] [-- Type: image/png, Size: 6820 bytes --]](../../DM3P100MB01403710DBA98989C2BB11DFF2EB0@DM3P100MB0140.NAMP100.PROD.OUTLOOK.COM/1.2-image001.png){kind=link}
![[-- Attachment #1.3: image002.png --] [-- Type: image/png, Size: 6810 bytes --]](../../DM3P100MB01403710DBA98989C2BB11DFF2EB0@DM3P100MB0140.NAMP100.PROD.OUTLOOK.COM/1.3-image002.png){kind=link}
![[-- Attachment #1.2: image005.png --] [-- Type: image/png, Size: 6820 bytes --]](../../c30a43ce1ddf602cd860f0748fea9073@mail.gmail.com/1.2-image005.png){kind=link}
![[-- Attachment #1.3: image006.png --] [-- Type: image/png, Size: 6810 bytes --]](../../c30a43ce1ddf602cd860f0748fea9073@mail.gmail.com/1.3-image006.png){kind=link}