PCI DSS logging – Collect server and firewall audit trails for PCI DSS requirement 10

PCI DSS requirement 10 calls for a full audit trail of all activities for all devices and users, and specifically requires that all event and audit logs are centrally collected and securely backed up. The thinking here is twofold.

First, as a proactive security measure, the PCI DSS requires all logs to be checked daily (yes – you read it correctly – view ALL logs DAILY – we’ll get back to this potentially overwhelming burden later …) requires the security team to be more intimate with the daily ‘business as usual’ operation of the network. In this way, a real security threat is more easily detected by unusual events and activity patterns.

The second motivation for logging all activities is to provide a ‘black box’ recorded audit trail, so that if a cyber crime is committed, a forensic analysis can be made of the activity surrounding the security incident. At best, the perpetrator and the extent of his errors can be identified and remedied. At worst, lessons can be learned from the attack to improve processes and / or technology security measures. Of course, if you are a PCI Merchant reading this, your main driver is that this is a mandatory PCI DSS requirement – so we need to get started!

Which devices are covered by PCI requirement 10? The same answer as what devices fall within the scope of the PCI DSS as a whole – anything to do with dealing with or accessing card data is within the scope and we therefore need to establish an audit trail of each. 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 take them in turn –

How do I get PCI event logs from Firewalls? the exact command set varies by manufacturer and firewall version, but you must enable logging via the firewall web interface or command line. To take a typical example – a Cisco ASA – the CLI command sequence is logging into no log console as follows no logging logging abcd (where abcd is the address of your syslog server) logging trap informative This ensures that all ‘Informative Levels and above messages are forwarded to the syslog server and ensure that all logon and logoff events are logged.

How do I get PCI audit trails from Windows servers and EPoS / Tills? – A few more steps are required for Windows servers and PCs / EPoS devices. First of all, you need to ensure that logon and logout events, privilege usage, policy change and, depending on your application and how card data is handled, object access. Use the local security policy You may also want to enable system event logging if you want to use your SIEM system to help troubleshoot and prevent system problems, e.g. a failed disk can be prevented before the full error occurs by detecting disk errors. Usually we need success and failure to be registered for any event –

  • Account Log-In Events – Success and Failure
  • Account Management Events- Success and failure
  • Directory Service Access Events- Error
  • Logon Events – Success and Failure
  • Object access events – Success and failure
  • Policy changes – success and failure
  • Privilege Use Events- Failure
  • Process tracking – No control
  • System Events – Success and Failure

* Directory Service Access Events only available on a domain controller

** Object access – used in conjunction with folder and file checker. Auditing Failures reveals attempted access to forbidden protected objects that could be a security breach attempt. Auditing Success is used to provide an Audit Trail of all access to secured data, such as card details in a settlement / transaction file / folder.

*** Process Tracking – not recommended as it will generate a large number of events. It is better to use a specialized whitelisting / blacklisting technology l

**** System Events – Not required for PCI DSS compliance, but often used to provide additional ‘added value’ from a PCI DSS initiative, raising early warning signs of hardware issues and preventing system failure. Once events are checked, they should be returned to your central syslog server. A Windows Syslog agent program automatically binds to the Windows event logs and dispatches all events via syslog. The added benefit of an agent like this is that events can be formatted in 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 that it is backed up before there is an opportunity to clear the local server event log.

Unix / Linux servers– Enable logging with 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 the details of the syslog server.

For example, add the following line to the /etc/syslog.conf file

*. * @ (a.b.c.d)

Or if you are using Solaris or another 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 intended syslog server.

If you need to collect logs from a third-party application, eg Oracle, you may need to use a specialized Unix Syslog agent that allows third-party log files to be forwarded via syslog.

Other network devices PCI DSS routers and switches must also be configured to send events via syslog. As described previously for firewalls, syslog is an almost universally supported feature for all network devices and devices. In the rare case that syslog is not supported, SNMP traps can be used, provided that the syslog server used can receive and interpret SNMP traps.

PCI DSS requirement 10.6 “View logs for all system components at least daily” We have now discussed how to get the correct logs of all devices within the scope of the PCI DSS, but this is often the simpler part of handling Requirement 10. The aspect of Requirement 10 that often concerns PCI vendors the most, the additional workload they expect from now is responsible for analyzing and understanding a potentially massive volume of logs. There is often an ‘out of sight, out of mind’ philosophy, or an ‘if we can’t see the logs, then we can’t be responsible for revising its mindset, because if logs are made visible and on the screen for the Merchant, there is no more excuse to ignore them.

While PCI PCI DSS does not prescribe how to meet the 12 requirements, requirement 10 specifically specifies “Log harvesting, parsing and alerting tools can be used to meet requirement 10.6”. In practice, it would be a very labor-intensive task to view all event logs, even in a small-scale environment, and an automated way of analyzing logs is essential.

However, when implemented correctly, it becomes so much more than just a tool to help you deal with the burden of the PCI DSS. An intelligent security information and event management system is extremely useful for all troubleshooting and troubleshooting tasks. With such a system, potential problems can be identified and resolved before they affect business operations. From a security perspective, by enabling you to become “intimate” with the normal operation of your systems, you are then well placed to discover truly unusual and potentially significant security incidents.

For more information, visit http://www.newnettechnologies.com

All material is copyright New Net Technologies Ltd.