PCI DSS compliance: You can't just check the boxes
Some organizations fail to recognize the complexity of 10.6, thinking that PCI DSS compliance is just another checkbox or project to be completed and forgotten. Recent breaches at organizations that were certified as PCI DSS compliant, however, continue to prove that compliance doesn't completely eliminate the risk of a data breach.
Last year, a large security services provider published a research note covering 500 data breaches over four years. Among the findings, the authors shared that in more than 80 percent of the breaches, evidence of the attack was apparent in the log data.
If well-executed log management can significantly reduce the risk of a breach or the length of the breach, why don't more organizations strictly adhere to the log management requirements of PCI DSS? The simple explanation is that becoming compliant to PCI DSS section 10.6 is a process! It is no small feat to sift through millions, perhaps billions, of log transactions or terabytes worth of log data each day. It's arduous, time-consuming and can become quite expensive.
Let me highlight a few best practices that will help you effectively define the scope of what needs to be logged and monitored at a high level, learn how to further refine the scope by following the upstream and downstream credit transaction flow, and clearly identify the system components that need to have their logs reviewed on a daily basis.
Keep in mind that this general approach can be used successfully for any compliance regulation and/or audit findings at any company that deals with periodic audit logs or event data reviews. For example, you can substitute the credit transaction flow specific to PCI DSS compliance for financial statement-related data and processes in the case of Sarbanes-Oxley compliance. The rest of the approach will remain the same.
Diagram it first
It often helps to look at a high-level picture of something and then work down into the details. The person or group in charge of PCI compliance should have a diagram at the department- or business-unit level that depicts the cardholder data environment (CDE). The CDE can be described as part of the network that processes, stores or transacts cardholder data or sensitive authentication data. Cardholder data consists of information contained within the full magnetic stripe of a credit card or the primary account number (PAN) plus either the cardholder name, expiration date or service code.
If such a diagram does not exist, one needs to be created. This diagram represents the potential overall scope for PCI remediation and, specifically, what system components need to have their audit logs reviewed for suspicious activity as described in PCI DSS section 10.2.
Define the scope
Now that the scope parameters are set, let's review how to tackle items that fall within them. It is important to note that when a company completes this scoping exercise, there will be a desire to eliminate some cardholder data from the company network rather than try to secure all of it. In so doing, the system component scope for daily log review will likely be decreased, which will make the job of becoming compliant a bit easier.
The key to defining the scope of what the CDE consists of is to ask a seemingly benign question: What are all of the system components that process, transmit or store cardholder data? System components can be defined as all of the applications, operating systems, databases and devices performing security functions such as intrusion detection systems (IDSs), firewalls and authentication, authorization and accounting protocol (AAA) servers included in or connected to the cardholder data environment.
Based on the answer to the question, take the high-level CDE flow diagram and fill in more details to depict what each of the pieces consists of in terms of system components.
The next step is to take that set of information and follow the flow of cardholder data upstream and downstream from each system component in this iteration of the CDE flow diagram.
Let's say that application A sends data to applications B and C. Applications B and C happen to be within our CDE flow diagram already. But Susan from the processing department mentioned that application A actually receives some of its cardholder data from application Z. Application Z was not on the original CDE flow diagram. It now needs to be added to the scope.
As you can see, wading upstream to find additional in-scope system components can be an onerous task, but it yields a definitive set of results even as it muddies the waters along the way.
Once there is a finalized CDE flow diagram, those various system components can be broken down into identifiers such as host names, IP addresses, log file locations and more. This then enables the log files to be identified and prioritized for collection and storage in a centralized location, where they will be accessed so your team can perform the daily review as required for PCI DSS section 10.6.
Brian Eberhardy is a senior consulting engineer for SenSage. At SenSage, he manages client relationships and the planning and implementation of security information management (SIM) and event data warehouse solutions and processes for medium and large enterprises.