Logging for PCI-DSS 3.1 using AWS and Papertrail

Logging is a very important aspect in PCI-DSS, it is covered in detail on Requirement 10: Track and monitor all access to network resources and cardholder data.

With proper logging you can detect and act based on the input received from the logs.

PCI-DSS requires that logging must be stored for at least 1 year and it must be readily searchable. There are other requirements that focus on audit trail and access of logging itself.

In this article I will focus on 3 easy solutions that makes most of this requirement a breeze to be compliant: Rsyslog+auditd, Papertrail and AWS S3 storage.

Auditd

Auditd is probably the most usefull tool in linux that lets you generate logs for most actions on your linux servers. Auditd can be configured to log all actions to help achieve PCI-DSS requirements such as File change monitoring, ntp changes, time/date changes, authentication audit trail and account changes. Detailed auditd configurations can be found on the CIS benchmark white papers for your distribution.

The requirements Auditd helps comply:

• Successful or Failed user authentication from SSH and TTY console (authlog) Requirements: 10.1, 10.2.3, 10.2.4, 10.2.5, 10.3
• User account changes and password (passwd, shadow, groups) 8.1.4, 8.2.4
• NTP time change. Req: 10.4
• File access and file changes for crucial system files (i.e. /etc, /bin/, /usr, /root)
• Sudo and Root commands. Req. 10.2.2

Auditd is supposed to be used in conjuction with Rsyslog, which then sends all logs to Papertrail. I will talk about Papertrail soon.

AWS S3

S3 offers a permenent storage for logs so that they are never deleted. Accessing files in an S3 bucket can be logged which also satisfy some PCI-DSS requirements for “log access”.

However an S3 bucket must have the following settings enabled:

• Versioning. So that an entry is never deleted from S3. You can recover deleted objects. Requirements: 10.7, Retaining audit logs for at least one year.
• Logging. So that every all access to logs in an S3 bucket are logged. You may need to create another bucket in the same zone to store the access logs, make sure that bucket also has versioning enabled. Requirements: 10.5.1, 10.5.2, 10.5.3, 10.5.4, 10.5.5

Papertrail

Papertrail offers a nice interface to view your logs in live mode as they arrive. It also offers other features such as log matching alerts and notifications, which is the most important feature here in regards to PCI-DSS.

Papertrails offers the ability to relay your logs to an S3 bucket for permanent storage, to complay with PCI-DSS Req 10.5.2, 10.5.3, 10.7
All you need to do is imput your bucket credentials such as list-bucket and write only.

With Papertrail you can create specific events to notify you by email or to your slack channel whenver a match is found. Req. 10.6
For example, I have compiled a few rules that you can use to generate usefull alerts:

SSH/Auditd and OpenVPN Events:

• “Accepted publickey” to alert you when a user has logged in. Req. 10.3
• “program:audispd sshd terminal=ssh res=success” if you use auditd in RHEL
• “Connection Initiated with” if you use openvpn, when a user connects. Req. 10.3
• “Invalid user” to alert for failed login attempts. Req. 10.3
• “rsyslogd was HUPed” or “The audit daemon is exiting” when rsyslog or auditd daemons restarts or stops, Req. 10.2.6
• “/usr/bin/sudo” to alert of sudo commands, Req. 10.2.2

And, there are many more that you can create tailored to your needs. I usually create a few high priority alerts that is checked every 1 minute going straigth to our Slack channel, and lower priority checked every hour.

Another feature of Papertrail that you could benefit in PCI-DSS is to create read-only users for your organization in order to comply with Req. 10.5.1, 10.5.2, 10.5.3, 10.5.4.

Papertrail website: https://papertrailapp.com/