Editor’s Note: In this first of a four part series of posts called the “Hitchhiker’s Guide to PCI DSS 2.0 Scoping,” Steve Levinson outlines a methodology for scoping of cardholder data environment and for cardholder data discovery for Payment Card Industry (“PCI”) assessments. This series presents valuable information for companies preparing for PCI DSS version 2.0 assessment. The current post outlines an assessment methodology. Future posts will present cardholder data discovery strategies, cardholder data discovery sampling strategies, and remediation guidelines for addressing issues with cardholder data.
The Payment Card Industry (PCI) Data Security Standard (DSS) released the most recent version of the standard, version 2.0, in October 2010. Most of the changes within this version of the standard are fairly minor. The biggest change in this version is the requirement for assessed entities to have procedures and documentation in place to demonstrate where cardholder data is located – as well as where it is not located. There is certain information you need to know to develop your cardholder data discovery methodology to preparefor your DSS version 2.0 assessment. We strongly recommend that you do this legwork before your actual PCI assessment. If you have a collaborative relationship with your QSA (PCI Qualified Security Assessor), use them as a sounding board throughout the process.
In the past, most PCI assessments included a review of the known cardholder data flows. This was akin to following the “bouncing red dot” to understand the data flows, the protocols used, the repositories, and how cardholder data passed through these systems, networks, applications, and people. It is still critical that you painstakingly provide as much detail as possible about the known cardholder data flows. If you have not thoroughly examined your cardholder data flows, you definitely will want to start here. The PCI Council is not asking that companies use cardholder data discovery tools to detect this information throughout the entire enterprise (at a potentially enormous cost). But, companies are required to do something to demonstrate where there is no cardholder data. It isn’t enough to understand where you believe your cardholder data should be. You will also be expected to demonstrate that you know where it could not be.
A Methodology for Cardholder Data Discovery
Although cardholder data flows and ecosystems vary widely from company to company, the general cardholder data discovery methodology described below should provide a common foundation for most companies:
In-scope entities are systems, applications, databases, and people with access to cardholder data. As you have closely documented cardholder data flows, you will need to next determine the probability that unencrypted cardholder data could reside in corresponding databases, server file shares, hard drives, point of sale systems, or anywhere else. Types of files to consider include the obvious ones, such as POS journal files, POS-created zip files or temp files, spreadsheets used by finance (on hard drives or on file shares), flat files or spreadsheets received from financial institutions/Third Parties, Loss Prevention or Chargeback reports. You should also consider the less obvious files, such as ones produced by marketing (e.g., gift card purchases) and HR systems (e.g., employee credit cards).
There are several means to collecting the information to put these pieces of the puzzle together, including review of data flow diagrams, interviews, penetration testing, and forensic analysis.
- Review data flow diagrams: This exercise is pretty much unchanged from PCI DSS version 1.2. It is one of the cornerstones to help determine which systems, applications, and networks should be considered in scope. From that information, you can begin to determine which people should be considered in scope and can, in turn, be used as a launching point for additional information gathering, such as
- Interviews: Once the known cardholder data flows are documented, you should interview the people who either use the cardholder data, who administer the cardholder data, or who have administrative access to the cardholder data. This will provide you additional insight about how the business uses cardholder data, including how it is used and why it is needed. This is a key opportunity to determine if scope can be reduced if the cardholder data is not really needed – for example you can ask the end-user if he or she would still be able to do their job if they just had access to the last four digits of the PAN. Oftentimes the people who USE cardholder are able to help you find where it is actually stored, and sometimes in a surprising way.
- Penetration testing: Some companies include penetration testing in their methodology to demonstrate that there are no covert channels, application weaknesses, network architectural flaws, or other means to demonstrate that cardholder data is properly protected.
- Forensics analysis: Forensics analysis plays a role in defining the scope by allowing you to take a closer look at “what is under the hood”. Some companies will perform this testing on their applications to demonstrate that there is no logical means of cardholder data leaking to a system, application, or log file.