Implement Logging for PCI DSS – A How to Guide

PCI DSS Requirement 10 calls for a full audit trail of all activity for all devices and users, and specifically requires all event and audit logs to be gathered centrally and securely backed up. The thinking here is twofold.

Firstly, as a pro-active security measure, the PCI DSS requires all logs to be reviewed on a daily basis (yes - you did read that correctly - Review ALL logs DAILY - we shall return to this potentially overwhelming burden later...) requires the Security Team to become more intimate with the daily 'business as usual' workings of the network. This way, when a genuine security threat arises, it will be more easily detected through unusual events and activity patterns.

The second driver for logging all activity is to give a 'black box' recorded audit trail so that if a cyber crime is committed, a forensic analysis of the activity surrounding the security incident can be conducted. At best, the perpetrator and the extent of their wrongdoing can be identified and remediated. At worst - lessons can be learned from the attack so that processes and/or technological security defenses can be improved. Of course, if you are a PCI Merchant reading this, then your main driver is that this is a mandatory PCI DSS requirement - so we should get moving!

Which Devices are within scope of PCI Requirement 10? Same answer as to which devices are within scope of the PCI DSS as a whole - anything involved with handling or with access to card data is within scope and we there for need to capture an audit trail from each of them. The most critical devices are the firewall, servers with settlement or transaction files and any Domain Controller for the PCI Estate, although all 'in scope' devices must be covered without exception.

How do we get Event Logs from 'in scope' PCI devices?
We'll take them in turn -

How do I get PCI Event Logs from Firewalls? -the exact command set varies between manufacturers and firewall versions but you will need to enable 'logging' via either the Firewall Web interface or the Command Line. Taking a typical example - a Cisco ASA - the CLI command sequence is as follows logging on no logging console no logging monitor logging a.b.c.d (where a.b.c.d is the address of your syslog server) logging trap informational This will make sure all 'Informational' level and above messages are forwarded to the syslog server and guarantee all logon and log off events are captured.

How do I get PCI Audit Trails from Windows Servers and EPoS/Tills? - There are a few more steps required for Windows Servers and PCs/EPoS devices. First of all it is necessary to make sure that logon and logoff events, privilege use, policy change and, depending on your application and how card data is handled, object access. Use the Local Security Policy You may also wish to enable System Event logging if you want to use your SIEM system to help troubleshoot and pre-empt system problems e.g. a failing disk can be preempted before complete failure by spotting disk errors. Typically we will need Success and Failure to be logged for each Event -

• Account Logon Events- Success and Failure
• Account Management Events- Success and Failure
• Directory Service Access Events- Failure
• Logon Events- Success and Failure
• Object Access Events- Success and Failure
• Policy Change Events- Success and Failure
• Privilege Use Events- Failure
• Process Tracking- No Auditing
• System Events- Success and Failure

* Directory Service Access Events available on a Domain Controller only

** Object Access - Used in conjunction with Folder and File Auditing. Auditing Failures reveals attempted access to forbidden secure objects which may be an attempted security breach. Auditing Success is used to give an Audit Trail of all access to secured date, such as, card data in a settlement/transaction file/folder.
*** Process Tracking - not recommended as this will generate a large number of events. Better to use a specialized whitelisting/blacklisting technology l
**** System Events - Not required for PCI DSS compliance but often used to provided extra 'added value' from a PCI DSS initiative, providing early warning signs of problems with hardware and so pre-empt system failures. Once events are being audited, they then need to be relayed back to your central syslog server. A Windows Syslog agent program will automatically bind into the Windows Event logs and send all events via syslog. The added benefit of an agent like this is that events can be formatted into standard syslog severity and facility codes and also pre-filtered. It is vital that events are forwarded to the secure syslog server in real-time to ensure they are backed up before there is any opportunity to clear the local server event log.
Unix/Linux Servers- Enable logging using the syslogd daemon which is a standard part of all UNIX and Linux Operating Systems such as Red Hat Enterprise Linux, CentOS and Ubuntu. Edit the /etc/syslog.conf file and enter details of the syslog server.

For example, append the following line to the /etc/syslog.conf file
*.* @(a.b.c.d)
Or if using Solaris or other System 5-type UNIX
*.debug @a.b.c.d
*.info @ a.b.c.d
*.notice @ a.b.c.d
*.warning @ a.b.c.d
*.err @ a.b.c.d
*.crit @ a.b.c.d
*.alert @ a.b.c.d
*.emerg @ a.b.c.d

Where a.b.c.d is the IP address of the targeted syslog server.
If you need to collect logs from a third-party application eg Oracle, then you may need to use specialized Unix Syslog agent which allows third-party log files to be relayed via syslog.

Other Network Devices Routers and Switches within the scope of PCI DSS will also need to be configured to send events via syslog. As was detailed for firewalls earlier, syslog is an almost universally supported function for all network devices and appliances. However, in the rare case that syslog is not supported, SNMP traps can be used provided the syslog server being used can receive and interpret SNMP traps.

PCI DSS Requirement 10.6 "Review logs for all system components at least daily" We have now covered how to get the right logs from all devices within scope of the PCI DSS but this is often the simpler part of handling Requirement 10. The aspect of Requirement 10 which often concerns PCI Merchants the most is the extra workload they expect by now being responsible for analyzing and understanding a potentially huge volume of logs. There is often a 'out of sight, out of mind' philosophy, or a 'if we can't see the logs, then we can't be responsible for reviewing them' mindset, since if logs are made visible and placed on the screen in front of the Merchant, there is no longer any excuse for ignoring them.

Tellingly, although the PCI DSS avoids being prescriptive about how to deliver against the 12 requirements, Requirement 10 specifically details "Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6". In practice it would be an extremely manpower-intensive task to review all event logs in even a small-scale environment and an automated means of analyzing logs is essential.

However, when implemented correctly,this will become so much more than simply a tool to help you cope with the inconvenient burden of the PCI DSS. An intelligent Security Information and Event Management system will be hugely beneficial to all troubleshooting and problem investigation tasks. Such a system will allow potential problems to be identified and fixed before they affect business operations. From a security standpoint, by enabling you to become 'intimate' with the normal workings of your systems, you are then well-placed to spot truly unusual and potentially significant security incidents.