hitchhikers guide to

payment card industry

data security standard
(PCI DSS) 2.0

Executive Summary
This paper titled Hitchhikers 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.

hitchhikers 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 Started
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 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 isnt 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:
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: Theres 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.

hitchhikers 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 youve included this in your methodology.

A Guide to Data Discovery Tool Selection

There 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 Tools
These 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 Tools
If 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 Symantecs Vontu, RSAs Tablus, Spyglass,
and Websense.
Mainframes
Although they have been around for some time and have been
perceived as just big and scary does not mean they dont have large
potential repositories of cardholder data. Weve seen clients implement
Xbridge as well as write custom scripts.

Sampling Strategy
There 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.

Databases
There 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).

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.

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

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

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.

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

hitchhikers guide to payment card industry data security standard (PCI DSS) 2.0__________________________________________________________________ 4

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 youve 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 Learned
The following section contains some lessons learned based on dozens
of PCI assessments and client interaction over the past year.
Avoid Guilt by Association
Remember, 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 dont create covert
channels to cardholder data.

Create an Audit Trail

Since 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 Tools
The 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.

Conclusion
Understanding 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.

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

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.