PCI DSS Logging Requirements

July 8, 2014 | Branden Williams
X

Get the latest security news in your inbox.

Subscribe via Email

No thanks. Close this now.

When it comes to PCI DSS Logging Requirements, sometimes the most challenging requirements to meet are the ones that can be the easiest technically to achieve. In dealing with logging, every single system around has the capability to meet PCI DSS, but managing those logs and ensuring they are continually being generated can be challenging.

The common problem that companies typically face when they tackle requirements for PCI logging is trying to find the right balance of logs to serve their needs—be it PCI DSS or otherwise. In the past, most companies suffered from under-logging, meaning they did not log enough actions to be useful (or to meet compliance requirements.) Today we’re seeing companies start to suffer from over-logging, caused by the promise of big data analytics and cheap storage. PCI DSS requires that all systems use some kind of NTP server (10.4) to synchronize time across the enterprise, which makes analyzing complex events possible with a consistent timeline. Both can cause operational issues, but under-logging can cause issues with PCI DSS.

To avoid under-logging, companies must ensure they comply with all of the areas highlighted under Requirement 10: Track and monitor all access to network resources and cardholder data. First and foremost, actions must be logged (attributed) to a particular user or process. It’s great to know that an event occurred, but it becomes almost pointless when you don’t know who or what initiated that event. For PCI DSS, all access must be shared to a unique individual anyway, so just ensure that the user is logged with the action.

Along with the user, there are five other elements that must be logged for each event. The type of event (10.3.2), date and time (10.3.3), success or failure indication (10.3.4), origination of event (10.3.5), and the identity or name of the affected data, system component, or resource (10.3.6).

Now that you are armed with the kinds of information you need to record, it’s time to tie in the critical events that must be logged. The key events are: anytime any user accesses cardholder data (10.2.1), root or administrative user actions (10.2.2), access to audit trails (10.2.3), invalid logical access attempts (10.2.4), usage and changes to authentication mechanisms (10.2.5), clearing, pausing, or cessation of logging (10.2.6), and the creation and deletion of system-level objects (10.2.7).

Logs should be kept secure (10.5) and not be able to be altered or accessed by those without a specific job function. You should review them (10.6), but this can be done through automated tools. Employ the use of a tool to help you analyze the vast amounts of logs you will generate. Don’t forget to keep those logs for at least a year (10.7), and include any analysis those automated tools performed in your log retention process.

Getting these logs to a central place for safe keeping and analysis can be challenging, but doing so will give you value far beyond PCI DSS. If bad guys are in your environment, you will most likely see the evidence in the logs somewhere. Make detection of threats easier by constantly hunting for anomalies in your logs.

Meeting PCI DSS requirements around logging is not terribly complex anymore, but making sense of the mountain of logging data can be. Spend time planning out your infrastructure and ensure you have the right tools to get the job done!

Branden is well known in the industry as a practitioner, consultant, and thought leader. He spent a number of years helping companies solve major security and compliance problems, including building PCI DSS compliance programs for some of the largest retailers around the globe. He recently sat on the PCI Board of Advisors and published the third edition of his book, PCI Compliance (Syngress, 2012) in August. Branden routinely speaks with organizations big and small with various levels of regulation to help them reduce their overall risk footprint and build safer and more efficient IT functions.

A review of the book on PCI written by Branden and Anton Chuvakin is here.

LEARN MORE HERE

Branden Williams

About the Author: Branden Williams, PCI Expert and Author

Read more posts from Branden Williams ›

‹ BACK TO ALL BLOGS

Watch a Demo ›
Get Price Free Trial