Five Challenges to Continuous

PCI DSS Compliance

WHITE PAPER
Executive Summary

As the Payment Card Industry Data Security Standard (PCI Lastly, the white paper discusses how the Tripwire VIA™
DSS, or PCI) becomes more widely adopted in both the suite of IT security and compliance automation solutions
United States and Europe, organizations face five major help organizations get and maintain continuous PCI compli-
challenges when navigating the PCI compliance landscape: ance so you can take control of security and compliance
• Misunderstanding what the term “PCI compliance” means of your IT infrastructure. Tripwire VIA solutions include
in a given context; Tripwire® Enterprise for configuration control and Tripwire®
Log Center for log and security event management. And
• Treating PCI compliance as an audit process rather than a
Tripwire Customer Services can help you quickly maximize
private industry standard;
the value of your Tripwire technology implementation.
• Scoping PCI compliance too broadly;
With Tripwire, get visibility across the entire IT infrastruc-
• Treating PCI compliance as a single-point-in-time, rather ture, intelligence to enable better and faster decisions, and
than ongoing activity; and automation that reduces manual, repetitive tasks.
• Failing to use automated tools to generate evidence of
continuous compliance.
This white paper discusses these challenges in-depth, along
with their implications. It also provides a plan of action
that organizations subject to PCI can take to address com-
pliance needs.

2 | WHITE PAPER | Five Challenges to Continuous PCI DSS Compliance

Introduction
For a standard that has only formally existed for about five
years, the Payment Card Industry Data Security Standard
(PCI DSS, or PCI) is making astonishingly rapid progress. In
the United States, depending on whose statistics you read,
anywhere from 50–80 percent of large retail companies are
validated as compliant; even second tier organizations are
roughly estimated around the 50 percent mark in terms
of adoption. PCI is making headway in Europe as well,
although adoption is not uniform across the continent, with
the United Kingdom exhibiting the highest levels of PCI
compliance and awareness.
In fact, PCI has attained such wide adoption that many
consider it a de-facto standard of due care in the retail
industry. Although a private industry rather than legal
standard, many organizations treat PCI as a regulatory
requirement—an approach that frequently creates an
unnecessary burden on IT. Based on well-established securi-
ty best practices, such as ISO17799, PCI is not a compliance
program, but rather a technical best practices standard for
the protection of sensitive data, not just credit card data.
This white paper will examine five major challenges
organizations face when navigating the PCI compliance
landscape—issues pertaining to the entire PCI compliance
lifecycle, including pre- and post-compliance challenges,
with a focus on clarifying certain common but crucial mis-
understandings of the PCI compliance process.
CHALLENGE #1: LACK OF ORGANIZATIONAL
UNDERSTANDING AND COMMITMENT
The lack of clarity regarding the term “PCI compliance”
is one fundamental challenge. In fact, the term can mean
one of several things, depending on the context in which
it is used:
1. Satisfying the requirements listed in the PCI DSS techni-
cal standard itself. This is the most accurate—but ironi-
cally the least utilized—definition.
2. Undergoing a successful external examination or assess-
ment by a third party, called a Qualified Security Assessor
(QSA), that has been certified by the PCI Standards
Council. The PCI Standards Council is a body created
specifically to maintain the technical standard. This is a
3 | WHITE PAPER | Five Challenges to Continuous PCI DSS Compliance
typical use of the term when discussing PCI with retail
executives, although it is probably the least accurate.
3. Satisfying the registration requirements of each of the
major card brands—chiefly VISA, MasterCard and AMEX—
by submitting various forms or other necessary informa-
tion according to each association’s rules. This use of the
term is the most common, even though the related pro-
cess has little to do with the actual PCI.
Unfortunately, inconsistent use of “PCI compliance” often
leads to significant confusion and frustration. For example,
an organization may satisfy all PCI controls yet not be
registered with a card association. As a result, that card
association does not consider the organization to be in com-
pliance—even when another association has accepted and
validated the registration. When discussing PCI compliance
with IT, an internal auditor, an assessor, an acquiring bank,
or an association, you must keep in mind the context for
the discussion.
The following example demonstrates why context is
important. Often third-party service providers serve retail-
ers, but have no direct relationship with any of the card
brands. The service provider does not handle payments by
credit card, yet they do transmit or store their retail cli-
ents’ credit card data. In this familiar circumstance, the
service provider organization, which may well satisfy all
the PCI DSS controls, cannot directly register with the
associations. Such an organization is certainly PCI compli-
ant, but it is not Cardholder Information Security Program
(CISP), Site Data Protection Program (SDP) or Data Security
Operating Policy (DSOP) compliant. Unfortunately, most
potential retail clients cannot make this distinction, and
therefore consider the service provider organization non-PCI
compliant—an unfortunate assumption that may lead to
significant loss of potential revenue for the service provider.
Worse yet, the service provider in the above scenario
cannot resolve the issue without working with one of their
merchant client’s acquiring bank to sponsor the service
provider’s registration. However, the service provider and
the acquiring bank or card association have no business
relationship, so the bank will not want to accept the related
liability. Ironically, the retail client in question will also be
considered out of compliance due to PCI requirement 12.8.
 This requirement states that if the merchant shares card-
holder data with a service provider, it must implement and
maintain policies and procedures to manage that service
provider, which includes ensuring the service provider is PCI
compliant. Until this process is complete, the merchant is
subject to potential fines and censures—a curious chicken-
and-egg scenario that could be challenging, especially for
smaller third party service providers that are attempting to
gain market share.
MasterCard has in some cases tacitly worked around
this issue in the past couple of years by accepting direct
registrations through submissions from certain QSAs. In
contrast, VISA has insisted on the formal process, resulting
in cases where MasterCard’s list of compliant service provid-
ers includes organizations not on VISA’s list. Fortunately,
both associations recently have begun pushing large acquir-
ing banks to handle these registrations when they learn of
these service providers. Hopefully this added pressure will
alleviate this issue.
CHALLENGE #2: PCI AS AN AUDIT PROCESS
A separate issue facing organizations subject to PCI com-
pliance results from the tendency toward treating PCI
compliance as an audit process. Although a PCI assessment
resembles a regulatory audit to some degree, organizations
should not treat it as such for several reasons:
• First, because PCI is not a law, but rather a private indus-
try standard, the level of risk associated with PCI compli-
ance differs from meeting, for example, a financial report-
ing rule in a regulation.
• Second, PCI assessments function more as a “spot-check”
than an actual full-blown record examination, with no
account for a system of record or distinction between key
and other controls. In fact, PCI is entirely binary in two
senses: all controls have equal weight, and they must all
be satisfied in order to be compliant. While compensating
controls can be listed and approved, there is no “percent-
age compliance” threshold that can be crossed; you’re
either compliant, or you are not.
In one early case, an internal auditor at one association
rejected a large organization’s entire submission when the
auditor noticed that the organization’s data destruction
4 | WHITE PAPER | Five Challenges to Continuous PCI DSS Compliance
policy only stated that old hard copy with cardholder
data would be “shredded” rather than “cross-shredded.”
Hopefully such cases no longer occur, but the example
does demonstrate the impact of having equal weight and
binary compliance.
• Third, assessors do not have a rigid auditing standard
they must follow and by which they are judged; each can
approach the evaluation process differently, as long as
they satisfy the specific technical test criteria defined
within the standard. This lack of uniform evaluation
likely contributes significantly to the common belief that
any two PCI QSAs will likely reach different conclusions
when assessing the same organization. In an attempt
to remedy this issue, a detailed “scoring chart” that a
QSA must follow when assessing compliance was recently
released. Unfortunately, the chart does little to solve the
underlying issue, as it merely provides for the necessary
minimum evidence to be checked rather than requiring
a comprehensive audit or a centralized system of record.
Often, merchants “put their best foot forward,” provid-
ing a QSA with the systems and evidence they would like
examined rather than the QSA assessing a true random
sample. And with no legal foundation and significant
pressure to drive down costs between competing QSA’s, a
lack of significant competition around cost, this approach
frequently works—especially because the QSA’s work is
made easier and it eliminates any liability the QSA might
otherwise carry.
• Last, because QSAs usually work as consultants rather
than independent auditors, they often want to assess
organizations while also helping them become compliant.
This situation creates a powerful, inherent conflict of
interest and likely impacts assessment results. Worse, from
the client’s perspective, assessors end up with too much
power; they can end up running the show and decreeing
sets of their preferred solutions that would “guarantee
compliance,” hinting that the merchant had better do
what they say—or fail.
These issues distract from the simple fact that the PCI is
an extremely well-developed standard for protecting sensi-
tive data, although it’s important to note that the standard
assumes that a data classification effort has taken place and
that “cardholder data” has been defined as “sensitive.” As
such, PCI provides organizations a foundation for developing
an enterprise data security strategy, and one that is much
easier to initially adopt than a major framework such as
COBIT, a standard such as ISO17799, or a regulation such as
the Data Protection Act (DPA).
Many organizations now possess electronic data assets
well beyond private consumer information. With this tre-
mendous volume of data assets, treating PCI as a blueprint
for protecting those assets makes perfect sense, as it allows
the organization to capitalize on PCI-related investments
elsewhere. For example, an organization could extend most
PCI controls to its systems out of scope for PCI. By doing
so, the organization standardizes its security efforts and
reduces the overall cost of protecting additional systems. In
other words, if you have to do something anyway, and it’s
beneficial, why not extend those benefits everywhere? In
one instance, a large fashion retailer reduced the number
of key controls to implement for SOX by over 70 percent by
extending PCI controls to their financial system.
In some cases PCI compliance can even drive bottom-
line benefits. Returning to the third-party service provider
example above, merchants might be more willing to sign on
the dotted line with a service provider that had voluntarily
complied with PCI and had undergone a formal assessment
from a well-recognized QSA, even when the merchant is not
forced to do so by the card brands. For the service provider,
this ability to execute faster and reduce the sales cycle is
a tremendous benefit. It is easy to conceive of many such
scenarios; for example, a hosting provider with a segregated
PCI compliant environment within their data center. For one
outsourced e-commerce service provider, the ability to offer
a “PCI certified” environment translated to a significant
reduction in the sales cycle.
CHALLENGE #3: SCOPING COMPLIANCE TOO BROADLY
Not surprisingly, an organization can get overzealous about
PCI. Put an internal auditor on the task of becoming com-
pliant and you will quickly be inundated with forms, tests,
checks, requests for evidence, and spreadsheets with tiny
print listing missing controls—a far greater scope for PCI
than even the writers of the standard intended. This is a
5 | WHITE PAPER | Five Challenges to Continuous PCI DSS Compliance
natural result of such improper delegation; as discussed
earlier, PCI audits are anything but a formal, uniform audit
process. Also, many compliance officers are former auditors,
based on the thinking that to best address compliance one
should put an auditor in charge.
Instead, one should approach PCI compliance with two
intertwined goals in mind: reduction of risk and scope.
When discussing reduction of scope, it’s natural to consider
the word “scope” as referring to compliance. For PCI, scope
refers instead to “sensitive data.” In relationship to risk,
the less sensitive data an organization maintains, the lower
the organization’s risk associated with that data.
This principle applies, of course, to all kinds of sensitive
data. Corporations generally focus on the sensitivity of cor-
porate records such as financial results or legal agreements,
and understand that protecting those records effectively
begins with limiting their distribution. Corporate managers
instinctively understand the concept of data classification
when it comes to these kinds of records; some data is really
sensitive and we want to keep it safe. They understand that
keeping data safe involves ensuring it isn’t left carelessly on
someone’s desk, emailed to large distribution lists, or cop-
ied over to file systems that everyone in the company can
access. For these individuals, this important understanding
of sensitive data already exists; to drive home the concept
of reduction of scope they only need to apply that same
mindset to PCI “cardholder data.”
In most retail organizations that attempt to comply with
PCI, cardholder data initially seems to be everywhere. It’s
on the point-of-sale and merchandizing systems, financial
reporting systems, accounting excel spreadsheets, loss pre-
vention systems and investigation records, files with paper
records, receipts, emails, laptops… the list is endless. Sadly,
the question these organizations usually ask first is “How
do we comply with PCI for all this?” Instead, they should be
asking “Where can we eliminate the use of such data?”
By eliminating credit card account numbers from every
storage mechanism where these numbers should not reside,
the organization gains several major benefits. The first is
a dramatic reduction in compliance scope and associated
liability and risk. Ideally, actual card numbers should reside
only in one central system, such as the merchandizing
system (consider it the “PCI system of record”). All other
functions, including sales audit, loss prevention, and so on,
that may require the occasional card number can be driven
largely by the use of alternative mechanisms, such as utiliz-
ing cryptographic hashes instead of actual account numbers
for transaction searches. Furthermore, the benefits of going
through the scope reduction exercise can be even greater if
the principle is then carried over to other forms of sensitive
data. Ultimately this exercise in reducing scope can make
the entire company much better at handling its electronic
data assets of all kinds. In one case, proper scoping resulted
in a revised budget of $400K instead of over $2M, and a
reduction of three-fourths in the time needed to attain
compliance.
CHALLENGE #4: THE FALLACY OF POINT-IN-TIME
COMPLIANCE
Another self-defeating but prevalent approach is that of
“least-effort compliance.” An organization that views PCI
compliance as simply something the organization must do,
without understanding how it otherwise contributes to the
business, will naturally do the minimum necessary to attain
compliance.
This approach poses a number of significant risks.
Because a PCI assessment is very limited in nature, it is
easy to present an assessor with targeted evidence to
ensure compliance. Often, and especially in cases where the
assessor also serves as the consultant on how to pass the
assessment, it is extremely hard to avoid a form of collu-
sion between the client and the assessor that results in a
tendency to ignore, make exceptions for, or explain away
non-compliant elements.
The nature of PCI compliance as relying on an annual,
point-in-time assessment also contributes to the “illusion
of compliance” problem. PCI compliance, except in certain
narrow areas such as quarterly scanning, looks at the here-
and-now. Unlike a full audit, there is no actual requirement
to prove that all controls have been in place for an entire
year, but rather that they are in place when sampled during
the assessment. Even failed quarterly scans can generally be
explained away if the most recent scan before an assessment
shows a passing result. Another issue is that an organiza-
tion often falls out of compliance in areas that had already
6 | WHITE PAPER | Five Challenges to Continuous PCI DSS Compliance
been sampled and passed while other areas are in the pro-
cess of being assessed. This situation results in the curious
conundrum of the organization becoming non-compliant at
the time of being validated by the assessor.
Many organizations thus end up subscribing to the view
that the assessment is something that they need to pass
annually. Over time, these organizations become highly
trained in producing the correct set of evidence to get
validated for compliance, regardless of their actual PCI com-
pliance posture.
CHALLENGE #5: FAILURE TO AUTOMATE
All of these issues are non-material until a breach occurs.
That, however, is when the entire game changes. Following
a breach, the card association will send its own assessor,
usually paid for by the merchant, but this time with the
unspoken goal of disproving compliance at the time of
breach. And for the first time the assessor will assume the
role of auditor, not only checking for compliance based on a
current sample of evidence, but examining it over the entire
duration of time leading up to and following the breach.
It is easy to imagine that they will find numerous controls
that may not have been in compliance at one point or
another, or simply not find any supporting evidence at all.
Since PCI compliance is binary, the conclusion would be
that the organization had not been compliant at the time
of the breach, regardless of whether their compliance had
been validated by an external assessor beforehand. This
conclusion opens the door to a number of liabilities, includ-
ing fines and other sanctions, depending on how far the
association feels they can go with the particular entity in
question.
An excellent way to avoid much of this problem is the use
of automated evidence collection tools. Not only do such
tools normally have significant operational benefits—includ-
ing early detection of breaches, a major factor in limiting
risk—but they can prove that the organization had continu-
ous compliance, rather than point-in-time compliance, as
assessments do. The organization’s bargaining position when
dealing with the association is therefore greatly improved,
and avoiding a half million-dollar fine is enough to easily
justify the cost of several such tools, though breaches often
lead to more than a single fine.
Since PCI is very detailed in terms of required technical
and operational controls, it is virtually impossible to remain
compliant without such tools. But most of these tools also
bring side benefits, such as catching unauthorized changes,
detecting reliability and performance issues, or simply indi-
cating suboptimal configurations in operational systems.
Note that compliance in and of itself can’t stop a breach
from happening, although having security controls in place
will certainly reduce the breach to detection gap from
week and months to minutes and hours. That is powerful.
Unfortunately, the old security adage that “the only safe
system in a network is one that is not connected” still holds
true. However, PCI compliance, because it is essentially a set
of security best practices, can contribute significantly to the
organization’s overall security posture.
What you should do
From the discussion to this point, you can draw several useful
conclusions and begin to form a compliance plan of action:
1. PCI as a best practice. Where they make sense, plan to
expand relevant PCI controls to other areas of the organi-
zation; this will help with other compliance programs.
2. Scoping before compliance. Identify all cardholder data
flows and storage systems before looking at the PCI DSS,
and then eliminate as many of them as possible.
3. Controlling the compliance process. Avoid hiring your
auditor to assess and consult on how to pass their audit.
Instead, rely on proven PCI expertise to help you work
through the compliance process. Similarly, try to avoid
putting an auditor in charge of PCI compliance, unless
they have significant and specific PCI expertise.
4. PCI is ongoing. Do not fall into the “annual check-
point” mindset, but treat PCI compliance as a continuous
process.
5. Automation and centralization. Plan to invest in both
automation and centralization, with an eye towards col-
lection and review of evidence. This investment will pro-
vide the best coverage following a breach, but will also
provide significant operational benefits.
How Tripwire Helps
Tripwire IT security and compliance automation solu-
tions go beyond directly addressing requirements like PCI
Requirements 10.5 and 11.5. In fact, assessors recognize
that when the Tripwire VIA™ suite is in use, they can
assume that the organization being audited has already sat-
isfied specific PCI assessment criteria. In addition, Tripwire
solutions automate mission-critical operational and analysis
tasks around system changes, while providing strong proof
of compliance for auditors and legal discovery.
To date, Tripwire has helped over 7000 organizations
worldwide meet compliance requirements and secure their IT
infrastructure with industry leading IT security and compli-
ance automation solutions. These solutions include Tripwire
Enterprise for configuration control and Tripwire Log Center
for log and event management. Tripwire Enterprise delivers
proven file integrity monitoring, compliance policy man-
agement, real-time intelligent assessment of change with
Change IQ capabilities, and one-touch access to remediation
guidance to meet the PCI DSS configuration and change
process controls. Tripwire Log Center, an all-in-one log and
event management solution meets the log management
requirements of the PCI DSS and through it’s built-in inte-
gration with Tripwire Enterprise further enhances security
with security event data on changes flagged for review by
Tripwire Enterprise.
Together, Tripwire Enterprise and Tripwire Log Center pro-
vide a broad solution for ensuring PCI DSS compliance and
reducing an organization’s security risk.

7 | WHITE PAPER | Five Challenges to Continuous PCI DSS Compliance

 ABOUT TRIPWIRE
Tripwire is a leading global provider of IT security and compliance automation solutions that help businesses and
government agencies take control of their entire IT infrastructure. Thousands of customers rely on Tripwire’s integrated
solutions to help protect sensitive data, prove compliance and prevent outages. Tripwire® VIA™, the comprehensive
suite of industry-leading file integrity, policy compliance and log and security event management solutions, is the way
organizations can proactively achieve continuous compliance, mitigate risk and improve operational control through
Visibility, Intelligence and Automation. Learn more at www.tripwire.com and @TripwireInc on Twitter.

©2010 Tripwire, Inc. | Tripwire is a registered trademark of Tripwire, Inc. All other product and company names are property of their respective owners. All rights reserved. | WPFPC1b