Introduction
The PCI DSS Requirement 10 calls for a full audit trail of all activity for all devices and users, specifically requiring 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 requirement that all logs are reviewed on a daily basis (yes – you did read that correctly – 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 cybercrime 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 procedures 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 therefore 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 –
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 ensure all ‘Informational’ level and above messages are forwarded to the syslog server and guarantee all logons/logoffs are captured.
Windows Servers – There are a few more steps required for Windows Servers and PCs/EPoS devices. First of all it is necessary to ensure that logons, logoffs, privilege use, policy change and depending on your application and how card data is handled, object access. 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 pre-empted 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 provide an Audit Trail of all access to secured date, for example, 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 such as NNT Remote Angel
**** System Events – Not required for PCI DSS compliance but often used to provided additional ‘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. An agent program like the NNT Log Tracker Agent will automatically bind into the Windows Event logs and forward all events via syslog. The additional 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 component 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 forward 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 additional workload they anticipate by now being responsible for analyzing and understanding a potentially huge volume of logs. There is often an ‘out of sight, out of mind’ philosophy, an ‘if we can’t see the logs, then we can’t be responsible for reviewing them’ mindset, whereas 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, implemented correctly, rather than being 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. 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.
