PCI DSS 3.0 Doubles Down on Log Management

Sidenote: We’re hosting a PCI DSS Q&A webinar on September 24, 2014 and would love for you to join us. Registration is open now.

Now … on to PCI DSS 3.0 and log management.

While the specs for PCI DSS 3.0 have been available for some time, technically the deadline to comply is December 31, 2014. Before December 31, you can still be compliant with PCI  DSS version 2. With the end of year deadline approaching, this is a good time to refresh our memories on what PCI DSS 3.0 means for log management.

Log management has of course been part of the PCI specification for some time. Unfortunately for many merchants though, it meant only that they had to keep logs and rotate them (eventually).  In some instances, there really wasn’t even anyone monitoring them. For many, logs have been viewed of as more of a forensics tool to be used after the fact in breach investigations than as a proactive security lever.

With version 3.0, PCI DSS has put a bit of a bite into log management. Overall PCI version 3.0 seeks to move PCI compliance away from a once a year audit to a “business as usual” posture. Changes in version 3 fall into three categories – clarifications, additional guidance and evolving requirements.  Most of what is new in version 3.0 falls into the clarification category.  While the 12 areas of the PCI remain the same, the PCI Council has modified or added sub-categories to most of the 12 requirements.

PCI regulations regarding log management are for the most part in section 10 of the regulations. In PCI version 3 the big changes in section 10 are:

  • Modification of 10.2.5 to require logging of changes, additions or deletions to root access or administrative access besides identification and authentication mechanisms. The reason for this is that changes to root or administrative access can provide visibility of bypassing or impersonating valid accounts.
  • Revision to 10.2.6 extends the requirement to track the initialization of logging mechanisms to include the pausing or stopping of the logging mechanism as well. Malicious users often turn off logging. Pausing or stopping of logging can indicate malicious activity.
  • The review of logs per 10.6 has been part of PCI DSS for some time. However in version 3.0, the PCI  Council significantly strengthened the requirement to provide more clarity on what events need to be reviewed daily and which ones can be reviewed periodically based on risk assessments. 10.6.3 requires that exceptions and anomalies identified during review be noted.
  • While the one year log retention period as defined in 10.7, has not changed. In the guidance column, the council states their explanation for the requirement. When dealing with breaches that sometimes takes months to discover the requirement to keep logs for one year seems reasonable.

Other areas of the PCI that deal with logs and have some changes in PCI 3.0 include:

  • Section 3.4 regarding protection of cardholder data requires that Primary Account Numbers (PAN) which can be contained in logs to be rendered unreadable. This could be accomplished with encryption, masking, etc.
  • Section 5.2 requires that anti-virus software generate logs.
  • Section 6.6, deals with WAF logs, which of course is very important especially to AlertLogic WAF customers.

AlertLogic has a whole section detailing AlertLogic and PCI compliance on our website. December 31st will be here before you know it. Don’t get caught behind the compliance 8 ball. Make sure your log management is up to spec with PCI 3.0. And again if you have questions or comments on log management or anything else PCI DSS 3.0 related, please join our webinar on September 24, 2014.