Executive Summary

This paper titled Hitchhiker’s Guide to PCI DSS 2.0 outlines a methodology for scoping of the

cardholder data environment and for cardholder data discovery for Payment Card Industry (“PCI”)

assessments. We present valuable information for companies preparing for PCI DSS version 2.0

assessment including cardholder data discovery strategies, cardholder data discovery sampling

strategies, and remediation guidelines for addressing issues with cardholder data.

hitchhiker’s guide to payment card industry data security standard (PCI DSS) 2.0

hitchhiker’s guide to payment card industry data security standard (PCI DSS) 2.0 _________________________________________________________________ 2

“Where is My Cardholder Data Not?” 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 prepare for your DSS version 2.0 assessments. 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.

Getting StartedIn 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 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). However, 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 DiscoveryAlthough 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:

• Identify in scope entities and determine if there is cardholder data present: 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), and 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 which can then be used as a launching point for additional information gathering.

• 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.

Cardholder Data Discovery Strategy As discussed above, companies do not necessarily need to perform cardholder data discovery scans across their entire environment. It is more important to chisel away the portions of your environment that are undoubtedly out of scope (i.e., do not store, process, or transmit cardholder data, nor are attached to these systems). For some companies, a large percentage of their environment may be considered out of (PCI) scope because the systems, applications, and people have absolutely no means of accessing cardholder data. Companies should thoroughly document each of these entities or groups of entities and prove how there is no logical means for these entities to access cardholder data. If you are able to provide detailed descriptions that de-scope portions of your environment, you may have less of a burden of proof when it comes to cardholder data discovery exercises and tools. You should also build the following into your strategy:

• Determine changes over time: As you go through this exercise, you should also do your best to determine what changes have taken place over time. If your network architecture and systems have remained fairly static, you may not need to be too concerned about systems that have been recently de-scoped. On the other hand, if you just implemented network segmentation a few months ago, it is possible that systems now out of scope were in scope back then, and therefore they may have cardholder data on them.

• Address the Null Hypothesis: Once you have corralled the possible systems, databases, applications, and people, you will need to develop a methodology to fail to disprove the null hypothesis. The null hypothesis is: “There’s no cardholder data here.” To fail to disprove this is to demonstrate that you have performed your due diligence to flip over the stones to show that you were unable to find any cardholder data.

hitchhiker’s guide to payment card industry data security standard (PCI DSS) 2.0 _________________________________________________________________ 3

• Determine the Periodicity: In building out your cardholder data discovery methodology, you will need to determine the periodicity in which you search for unencrypted cardholder data. In some instances, you may run one discovery scan, and assuming that no data is found and that you have adequate controls to prevent cardholder data from appearing on that device, system, or application. In other instances, more frequent scans may be required. There is no set rule for the periodicity of CHD discovery scans – it will vary from network to network or entity to entity, but make sure that you’ve included this in your methodology.

A Guide to Data Discovery Tool SelectionThere is no silver bullet to defining your scoping methodology, but there are many possible solutions available to address your cardholder data discovery needs. While AT&T Consulting is vendor neutral, we have seen a variety of tools help many of our clients with their discovery process for databases, spreadsheets, and flat files by using open source tools, commercial off-the-shelf tools (COTS), forensic analyzers, and outsourced cardholder data discovery solution providers. No one-size-fits-all approach exists, but a thorough examination can go a long way in helping you meet the spirit of the PCI standard.

Open Source ToolsThese tools will potentially save you money, but you will need to have some degree of in-house expertise to run and/or fine-tune these tools. Examples are Spiderlabs, Nessus, and custom scripts.

COTS ToolsIf you are already using one of these providers’ products, there may be synergies in selecting their cardholder data discovery solution. Many of our clients have implemented Symantec’s Vontu, RSA’s Tablus, Spyglass, and Websense.

MainframesAlthough they have been around for some time and have been perceived as just big and scary does not mean they don’t have large potential repositories of cardholder data. We’ve seen clients implement Xbridge as well as write custom scripts.

DatabasesThere are times when companies are not fully aware of the content of their databases. (some companies write their own REGX discovery scripts while others use commercial database discovery tools).

Forensics AnalyzersAlthough some consider this as these tools do a lot more than just cardholder data discovery (i.e., enCase).

Outsourced Cardholder Data Discovery Solution Providers: There are reputable third parties who can perform your cardholder data discovery scans – either on a one-time basis or as a service. These providers include: forgenix FScout, Ensure Networks, iScan, and some of the QSA companies.

Regardless of which tool(s) you implement, the outcome that you should expect is that cardholder data discovery is an imperfect process. Your tool will invariably stumble upon heaps of false-positive findings (data that appears to be cardholder data, but is not). You must be prepared to address these false positive findings and learn where they should be ferreted out and where they are valid. This is often a time-consuming exercise, especially the first time you use the tools.

Sampling StrategyThere are many instances where we have worked with retail clients to determine a sampling approach to cardholder data discovery at their retail locations. For those companies who maintain their retail systems on a consistent basis, it is possible to create a sampling methodology to perform cardholder data discovery. Some critical factors to consider for this approach include the following:

• All POS systems must adhere strictly to a build standard. If a significant variance is discovered, it may turn out that all systems must undergo cardholder data discovery analyses.

• It should go without saying that all POS systems should be implemented and maintained in a PCI-compliant manner. Just because a payment application is certified as PA-DSS compliant does not mean that system has been implemented properly.

• Make sure you understand your payment application. If it was provided by a third party or payment application provider, find out if they have any information about whether the payment application is capable of dumping cardholder data – for example, to a log file. If the application has been developed in-house, work with your payment application developers to understand this. If there is no logical way for a payment application to output cardholder data into a hard drive or a log file, the probability of finding cardholder data there is greatly diminished. If there is a logical way for your payment application to dump cardholder data, then make sure you monitor the process(es) that would cause this event to take place and the destinations where the cardholder data would potentially land.

• In the event that any cardholder data is discovered, companies should create a remediation strategy that applies to all appropriate POS systems, since it is possible that cardholder data appeared on other systems.

• In the event that any cardholder data is discovered, companies should perform a root cause analysis to determine how the cardholder data appeared there so that action can be taken to prevent a recurrence.

• In the event that any cardholder data is discovered, companies should run additional cardholder data discovery scans on a new set of systems to ensure that remediation was effective across the board.

• Companies should change their sample set for each discovery scan. This will allow for more systems to be scanned over time.

• While cardholder data discovery tools are not going to find stores of encrypted cardholder data, you should remain vigilant for any unauthorized or undocumented repositories of encrypted cardholder data (even this is easier said than done).

Please keep in mind that different QSAs may interpret this PCI requirement differently. Companies to be assessed should collaborate with their QSA prior to or early in their PCI assessment to determine that QSA’s interpretation of sampling for cardholder data scans. It will be up to the merchant to be able to demonstrate a sound approach to their QSA regarding sampling of POS systems for cardholder data.

hitchhiker’s guide to payment card industry data security standard (PCI DSS) 2.0 _________________________________________________________________ 4

For more information contact an AT&T Representative or click here.

Remediation Strategy“Cardholder Data Discovery Remediation – What If You Find Stuff?”The purpose of cardholder data discovery is to systematically search systems for cardholder data. If you do happen to find unencrypted cardholder data, you will want to ensure you’ve created a remediation plan to address it. Your remediation plan should be included within your overall cardholder data discovery methodology, and it should address the following:

• Determine how the unencrypted cardholder got there (root cause analysis).

• If there are multiple findings, determine if there is a pattern.

• Determine if anyone has a need for the cardholder data.

• Determine if there are any similar channels where cardholder data may have leaked (e.g., users with similar privileges and/or job functions, or users with similar shared drives) and consider running a subsequent cardholder data discovery scan.

• Determine what can be done to prevent (preferably) or to monitor for this type of data leakage in the future and implement these controls accordingly.

• Perform a secure delete of the unencrypted cardholder data if there is no business need for it. If there is a business need for the unencrypted cardholder data, ensure that you have compensating controls in place to adequately protect it.

Lessons LearnedThe following section contains some lessons learned based on dozens of PCI assessments and client interaction over the past year.

Avoid Guilt by AssociationRemember, in most cases your cardholder data discovery application and systems should be considered to be in-scope, as they either may contain actual cardholder data (which is found during the discovery process) including ‘guilt by association’ systems that are attached to systems that store, process, or transmit cardholder data. Make sure that you infuse the appropriate security controls on these systems (access controls, logging, etc.) to ensure that they don’t create covert channels to cardholder data.

Create an Audit TrailSince your cardholder data discovery methodology will most likely include the use of tools or processes to perform cardholder data discovery, you will need to create some type of audit trail to demonstrate that you have indeed been performing adequate cardholder data discovery searches and scans. You should provide some degree of evidence to your QSA during your PCI assessment, similar to how you would demonstrate, for example, how you perform your quarterly internal vulnerability scans. It is important to create tangible evidence and not to expect that your QSA should accept this evidence based only on interviews or word of mouth.

Implement DLP ToolsThe terms “cardholder data discovery” and “data leakage prevention” (DLP) often are used synonymously when indeed they are different functions. Cardholder data discovery is the act of using a methodology or tool to search for cardholder data at rest, whereas DLP focuses more on cardholder data in transit, leaking to unauthorized/unexpected places. DLP can play a pivotal role in building a sustainable program to prevent cardholder data from appearing in surprising places. How does this work? After you perform an initial discovery scan to verify that there is no unencrypted cardholder data in a particular location, you may then be able to implement DLP tools to ensure that going forward no cardholder data makes it to that location, perhaps even doing away with the need for subsequent cardholder data searches on that particular host/system.

While tools are an important building block of any robust security or governance program, companies should not blindly rely on them. It is critical to understand and to document your cardholder data flows, and to work closely with the business and the administrators (network, systems, and applications) to determine any potential inherent weaknesses so that when it makes sense, you can use the tools at the right times and in the right places.

ConclusionUnderstanding and complying with the PCI Data Security standard (PCI DSS) can be a daunting task, especially if your organization has limited time and resources. Organizations are often blindsided by the changes in the standards, new payment technologies, and emerging business context. Many organizations still narrowly focus on the annual compliance assessment rather than adopting a programmatic approach to compliance, and hence are subject to falling out of PCI compliance. This document should help provide your organization with the building blocks to create a sustainable cardholder data scoping methodology.

08/02/12 AB-2486

© 2012 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual Property. The information in this document is provided by AT&T for informational purposes only. AT&T does not warrant the accuracy or completeness of the information or commit to issue updates or corrections to the information. AT&T is not responsible for any damages resulting from use of or reliance on the information.