S E A R C H S E C U R I T Y.

C O M

technical
guide on
PCI DSS:
NEXT-GENERATION
DATA SECURITY,
STORAGE and
INTEGRITY
contents
5 PCI DSS compliance requirements: Ensuring data integrity

8 The future of PCI DSS encryption requirements? Tokenization for PCI

13 Ease credit card risks: POS encryption and data tokenization for PCI

16 Assessment success: PCI DSS standards and secure data storage

20 Wireless network guidelines for PCI DSS compliance

Find the cybercriminal.
(Never mind. ArcSight Logger already did.)

Just downloaded the customer

database onto a thumb drive.

Stop cybercriminals, enforce compliance and protect

your company’s data with ArcSight Logger.

Learn more at www.arcsight.com/logger.

© 2010 ArcSight. All rights reserved.
 | TEC H N I CAL G U I D E O N P C I DSS

insight
PCI DSS
The Payment Card Industry Data Security Standard is the most
prescriptive information security standard, forcing organizations
to take a close look at updates and how it impacts current processes
and technology investments.
SEARCHSECURITY.COM presents a comprehensive guide to PCI DSS. Our
experts cover all the angles in order to help your efforts in meeting
compliance with the credit card industry’s data security standard.

contents
5 PCI DSS compliance requirements: Ensuring data integrity
DATA PROTECTION Data integrity is a crucial part of PCI DSS compliance and
ensuring that data is whole and accurate must be a priority. BY DAVID MORTMAN

8 The future of PCI DSS encryption requirements?

Tokenization for PCI
TOKENIZATION What are the benefits of tokenization and is it right for your
organization? BY RANDALL GAMBY

13 Ease credit card risks: POS encryption and data tokenization for PCI
ENCRYPTION Here’s what you need to consider before using tokenization and
transaction encryption to protect cardholder data. BY JOHN KINDERVAG

16 Assessment success: PCI DSS standards and secure data storage

STORAGE SECURITY PCI DSS standards for secure data storage are specific and
detailed, but there are two key steps that can significantly reduce the pain of an
assessment. BY ANTON CHUVAKIN

20 Wireless network guidelines for PCI DSS compliance

WLAN SECURITY Does the PCI Security Standards Council’s additional
guidance for WLANs make the compliance process easier? BY BEN ROTHKE

27 VENDOR RESOURCES

3 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

Ac h i e ve Co m p l i a n ce. S e c u r e l y.
Imperva, the Data Security
leader, enables a complete
security lifecycle to provide
visibility and control for
business databases and the
applications that use them.
Protecting the Data That Drives Business®
Imperva SecureSphere solutions enable medium enterprises
to achieve regulatory compliance. SecureSphere’s unmatched
Data Security capabilites include:
» Automated and accurate Web application security
» ICSA-certified Web application firewall for PCI DSS section 6.6
» Database vulnerability assessments and risk scoring
» Pre-defined SOX, PCI, HIPAA reports streamline compliance initiatives
» Proven and trusted enterprise-class security at a reasonable price
Visit Our Free PCI Informational Resource Site
Concerned about ensuring your organization is compliant with the Payment Card Industry
(PCI) Data Security Standard (DSS)? The DSS lists 12 high-level requirements; Imperva
SecureSphere can immediately help you address 8 of these 12 PCI requirements. Imperva
has a proven track record assisting merchants and service providers.
Learn more by visiting the Imperva PCI resource site: www.imperva.com/PCI
Toll Free (U.S. only): 1-866-926-4678 or +1-650-345-9000
www.imperva.com
© Copyright 2010, Imperva All rights reserved. Imperva, SecureSphere, and Protecting the Data That Drives
Business are registered trademarks of Imperva.
 | P CI DSS

DATA P R O T E C T I O N

PCI DSS Compliance

Requirements: Ensuring
Data Integrity
Data integrity is a crucial part of PCI DSS compliance
and ensuring that data is whole and accurate

i
must be a priority. BY DAVI D MORTMAN
IN ALL THE FUSS surrounding the need for enterprises to prevent data leaks and data
theft, how can an organization be sure the data it’s working so hard to protect is truly
all of the data that needs to be protected? Data integrity is a crucial part of Payment
Card Industry Data Security Standard (PCI DSS) compliance (not to mention a com-
pany’s ability to function), so ensuring that data is whole and accurate must be a priority
within security and compliance teams.
Knowing which data to protect, however, can be tricky.
Generally, compliance regulations are quite clear on what kinds of data companies
need to protect (cardholder data, personally identifiable information (PII), personal
health information (PHI) etc.). That’s the easy part. Things get tricky when you need
to figure out where the compliance-related data is within your organization to appro-
TABLE OF CONTENTS
priately track and protect it.
So before you even start to worry about PCI, it’s necessary to understand how and
where the important data flows within the company. Despite what DLP vendors might
DATA PROTECTION
say, this is not strictly a technology problem, but a process and personnel issue as well.
You’ll need to interview people in every business unit, because you will find they are
TOKENIZATION
using data in ways that you couldn’t possibly imagine and have perceived business needs
you may not have considered. These interviews will undoubtedly spur more interviews,
and eventually you’ll have a pretty good idea where the data that you have to protect is
ENCRYPTION and whether you are, in fact, protecting the right data after all.
With regard to PCI DSS, while in some sense the overall program is all about data
integrity, a deeper dive will discover that none of the 12 PCI requirements strictly fall
STORAGE SECURITY under the rubric of data integrity. That being said, while all 12 are important, when
looking specifically at data integrity issues, there are some specific requirements that
can help lead to having data integrity.
WLAN SECURITY Most notably, look to the requirements around protecting cardholder data (which
consists of Requirement 3, protecting stored cardholder data, and Requirement 4,
encrypting transmission of cardholder data across open, public networks) and the
SPONSOR RESOURCES implementation of strong access control measures (which consists of Requirement 7,
restricting access on a need to know basis, Requirement 8, that users must have unique

5 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

user IDs, and Requirement 9, restricting physical access to cardholder data). Require-
ment 8 leads directly to Requirement 10, which mandates regular monitoring of access
to all cardholder data and network resources. Finally, there’s Requirement 6, which
mandates the development and maintenance of secure systems and applications. So, all
in all, more than half of the requirements directly and obviously address data integrity
issues.
As for best (or at least common) practices, what can be done to maintain the
integrity of enterprise data? For starters, encrypt the data both at rest and when trans-
mitting it across the network. Though this isn’t a requirement of PCI DSS, I highly
recommend that data be transmitted over SSL, even within an organization’s own
private networks. It doesn’t add much (if any) complexity and can really help maintain
integrity by ensuring that data can’t be pilfered or tampered with.
Next (or even better yet, in parallel), set up logging and auditing of applications and
networks so the organization can know who is accessing its data, when it is altered, and,
perhaps more importantly, where that data is going. This should include some sort of
ability to perform network analysis. Though not part of the PCI DSS standard, logging
and auditing will become necessary if all data is encrypted; these also offer the bonus of
quickly identifying when sensitive data traverses new or different paths on the network,
which could potentially be a breach in progress. From what little we’ve heard about the
recent Heartland Payment Systems Inc. breach, this sort of logging and auditing tech-
nology would have likely identified the issue much sooner, sparing the company some
serious fallout.
Similarly, by building and maintaining secure systems and applications, you can
have a much higher comfort level that the data you have in those systems is the data you
think you have, and that only those who have appropriate access and authorization have
TABLE OF CONTENTS been able to alter it.
As an added bonus, by following these types of processes (encryption, logging,
auditing, secure applications, etc.) you gain not only compliance with PCI DSS, but
DATA PROTECTION also with other regulations such as Sarbanes-Oxley (SOX).
For other suggestions, there are many more detailed PCI DSS descriptions available
online. Examples include general information on PCI DSS, creating a prioritized
TOKENIZATION approach to PCI DSS, guidelines for PCI DSS compliance for wireless networks and
understanding the intent of the PCI DSS requirements. These will give you a great
baseline from which to start dealing with data integrity, as well as some ideas on where
ENCRYPTION
to go from there.w

As CSO-in-Residence, David Mortman is responsible for Echelon One’s research and analysis
STORAGE SECURITY program. Formerly the Chief Information Security Officer for Siebel Systems, Inc., David and his
team were responsible for Siebel’s worldwide IT security infrastructure, both internal and external.
He also worked closely with Siebel’s product groups and the company’s physical security team and
WLAN SECURITY led up Siebel’s product security and privacy efforts. A CISSP, Mr. Mortman sits on a variety of
advisory boards including Qualys and Applied Identity and Reflective, amongst others. He holds
a BS in Chemistry from the University of Chicago.
SPONSOR RESOURCES

6 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 W H AT ’ S t h e B U S I N E S S P RO B L E M ?

CUSTOMER DATA
CUSTOMER DATA
K
S
I
R

R I S I N G R I S K TO C U S TO M E R D ATA

the QWEST SOLUTION: The more data you collect from your customers, the more

you have to lose. With Qwest’s advanced suite of security solutions, you can protect

sensitive customer information and keep it from falling into the wrong hands. All while

maintaining industry security standards. Solve more problems at qwestsolutions.com.

Copyright © 2010 Qwest. All Rights Reserved.

 | P CI DSS

T O K E N I Z AT I O N

The Future of PCI DSS

Encryption Requirements?
Tokenization for PCI
What are the benefits of tokenization and is it right
for your organization? BY RAN DALL GAM BY

i
IMAGINE A TELEVISION COMMERCIAL: A person comes on the screen and says,
“Hi, my name is Bob Jones. My Visa number is 4567 8903 2890 4598 and the expira-
tion date is 12/12.” Frightening, huh? Now imagine he goes on to say, “I should also
mention that these numbers are only valid if you are a processor or issuer because
they’ve been tokenized, so good luck using them!”
These two sentences sum up why tokenization is invaluable to any organization
handling credit card data and looking to achieve PCI DSS encryption requirements
Tokenization allows information to be reformatted in a fashion that renders it useless
to outsiders—thus reducing the risk of unauthorized access to, or breaches of, the
TABLE OF CONTENTS
information—while still allowing organizations, their business partners and their
underlying applications to use this sensitive information to process transactions in
a format they expect, with little modification to business workflows. In fact, in the
DATA PROTECTION
not-too-distant future, it may even replace encryption as the preferred method to
protect credit card data.
However, before we explore the topic of Today’s business flows
TOKENIZATION
tokenizing information further, let us discuss for processing information
why its counterpoint—encryption—has had
issues, and thus, why modifications are need-
may require a large
ENCRYPTION number of systems to
ed to deploy encryption technologies and
meet PCI encryption requirements. work in lockstep with
STORAGE SECURITY each other.
Encryption for applications
Today’s business flows for processing information may require a large number of systems
WLAN SECURITY to work in lockstep with each other. With encryption, each application must be modified
to decrypt incoming information and then encrypt outgoing results. Modifications to
these systems require creating new modules, writing new scripts, testing, and in some
SPONSOR RESOURCES cases, updating to newer systems that can take advantage of encryption technologies,
even if the in-line applications only pass along the information for processing.

8 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

Information Flow
ENCRYPTION FLOW
Encrypt (E)
Decrypt (D)
Process (P)
Data entry—system1 (E)—(D) system 2 (E)—(D) system 3 (E)—(D) system 4 (E)—(D)
system 5 (E) - (D) system 6 (P)

TOKENIZATION FLOW
Tokenize (T)
Request Data from Tokenization Server (or algorithms are known) (R)
Process (P)
Data entry—system 1 (T)—system 2—system 3—system 4—system 5 - system 6 (R) (P)

Encryption keys and standards

In order to encrypt and decrypt information, a software key—whether symmetric
or asymmetric—must be used. These keys have to be issued, revoked and eventually,
expired. Since manually managing large numbers of encryption keys can be cumber-
some, enterprises need to deploy a key management system to ensure that production
workflows don’t stop due to a system’s encryption key becoming invalid.
There are many standards for encryption—e.g. IBE, PKI, PGP, and openPGP—so
enterprises must select a common set of encryption standards for both themselves
and their partners to ensure interoperability.
TABLE OF CONTENTS

Tokenization for PCI DSS compliance, data protection

The Payment Card Industry Data Security Standard (PCI DSS) encryption require-
DATA PROTECTION
ments mandate that credit card data be protected during processing and processes
must be modified to include these changes.
TOKENIZATION Because it’s difficult, and modifications are costly, encryption still struggles to
get a foothold in many organizations. This has led organizations that have tried to
deploy encryption to start looking at tokenization for PCI DSS compliance and data
ENCRYPTION protection.
With tokenization, the idea is not to encrypt the data, but to use known algorithms
to render key components of the data useless to outsiders while still retaining the
STORAGE SECURITY data’s value and format for processing. For example, if a birth date is 1/1/1989, tok-
enization can apply an algorithm to increment the month by 1, the date by 10 and
decrease the year by fifteen (with wrap around for month/day when the results are
WLAN SECURITY invalid). This results in the birth date becoming 2/10/1975. Unlike encryption, where
the results may look like “#$%^%$$@#” as the workflow passes this information for
processing, applications in the processing path can confirm the fields contain valid
SPONSOR RESOURCES values (to ensure the record hasn’t been corrupted during transmission) and pass the
information on to the application that will eventually reverse the tokenization and

9 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

Tokenization at Work
process the information.
Production Data Test Data
When an application receives
Given name James Bob
tokenized data it needs to process,
Surname Smith Jones
there are two choices: It can either
Account No. 5009 9087 8793 5642 4567 8903 2890 4598
have the tokenization algorithms
Exp. Date 3/11 12/12
added to its code to reverse the
CCV2 567 342
process or, more commonly, con-
Birth date 3/12/78 3/12/67
tact a secured corporate token
server that tokenizes information
on a large scale and maintains the
original information values; no key management required. In this case the application
sends predetermined tokenized data elements through secure communications channels
to the token server and receives the original information in return. While encryption
may seem like it takes a similar level of effort, when comparing the workflow of
a number of systems that pass sensitive data to the number of systems that must
process this data, one finds that tokenization is much more efficient.
As you can see from the workflows above, each system must be modified for
encryption, while only the initial entry system and processor must be modified for
tokenization. If dozens or hundreds of systems are involved in the workflow, an
organization can realize substantial savings using tokenization over encryption.
Tokenization also provides a number of ways to protect information. These
include:
• Object replacement: This is a direct replacement of some or all of the data in the
data set with similar data types (usually from tables), i.e. given name, surname, street
name, city, state, etc. so the name ‘Joe’ might become ‘John’ and ‘Smith’ becomes
TABLE OF CONTENTS ‘Jones.’
• Character replacement: This is a replacement of some or all of the data in the
data set using known reversible algorithms, i.e. primary account number (PAN),
DATA PROTECTION CCV, etc.
• Masking: This is the replacement of some or all of the data in the data set with
a single character. For example: 5009 9087 8793 5642 (original credit card number);
TOKENIZATION xxxx xxxx xxxx 5642 (masked credit card number).
• Randomizers: This is the replacement of some or all of the data in the data set
with ranges of similar data types, i.e. “increase exp. date month between 2-6 months”
ENCRYPTION
or “modify birth date year by decreasing between 10-15 years.”
Keep these things in mind when deciding which method to use to protect sensitive
information: Does the tokenization process for the information need to be reversed
STORAGE SECURITY
for processing? What rules are needed to ensure the information remains valid?
When it comes to processing, data sets that have been tokenized by object and
character replacement, and in some cases, masking—in conjunction with other data
WLAN SECURITY
set elements—can be reversed. However, randomized data cannot be reversed with-
out a tokenization server, which maintains a mapping between the original data and
the tokenized output. Also, one must be careful of the rules used, especially for devel-
SPONSOR RESOURCES
opment or testing activities.

10 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

Instead of using production data in development or testing environments, tokeniza-

tion protections can be used to rapidly create unique production data that simulates
production data sets but has been modified to protect the sensitive information. This
not only reduces the level of security required to protect non-production environments,
but it also eliminates the risk of insider loss of sensitive information from these systems.
But, as mentioned in the last paragraph, the rules used shouldn’t invalidate testing the
processing of information. For example, tokenizing a “state” value may invalidate your
test workflow if the maximum credit interest charged varies by state. An example of
tokenized production data to similar test data is shown.
In this case, tokenization random algorithms were used to ensure the data can
never be tracked back to production data.

Tokenization issues: Security standards adoption

TABLE OF CONTENTS
DATA PROTECTION
So why isn’t tokenization more widespread? The main issue with tokenization is security
standards adoption. For example, the current version of the Payment Card Industry Data
Security Standard (PCI DSS) only formally recognizes encryption technologies for pro-
tecting credit card transactions. While the Security Standards Council (SSC) for PCI
DSS has recognized the value of tokenization—and is studying its capabilities—it has
yet to put it in the PCI DSS as an acceptable substitution for encryption. This means
that organizations that must comply with PCI DSS, and similar standards requiring
the protection of information in storage or transit, must look at the value
of tokenization and whether it increases the security of their processing and storage
architectures.
Tokenization will be the way of the future for protecting credit card and other
sensitive data; the question is: Has the future arrived for you?w
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company
who has worked in the security industry for more than 20 years. He specializes in security/identity
management strategies, methodologies and architectures.

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

SPONSOR RESOURCES

11 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

E N C RYP TI O N

Ease Credit Card Risks:

POS Encryption and
Data tokenization for PCI
Here’s what you need to consider before using tokenization

p
and transaction encryption to protect cardholder data.
BY JOH N KI N DE RVAG

PRETTY SOON, your credit card information will be worthless, and that’s a good
thing. Credit card security is moving away from creating barriers against theft of
cardholder data and moving toward making cardholder data impossible to translate
into money. By abstracting the data in such a way that the true cardholder data can-
not easily—or perhaps ever—be derived from it, it’s possible to replace the cardholder
data values with abstracted values that only have meaning within the specific context
of an individual transaction, which is potentially a much more effective way to protect
cardholder data and mitigate credit card risks.
At the forefront of this utopian vision to protect cardholder data are two interre-
lated, yet independent, technologies:
TABLE OF CONTENTS
1. Tokenization - the process of extracting valuable data, such as a credit card
number, and abstracting that data set to become another numerical value that
cannot be monetized.
DATA PROTECTION
2. Transaction Encryption - the process of encrypting cardholder data from the
moment it enters any system, such as a POS terminal or an eCommerce website, and
TOKENIZATION
transporting this encrypted value to its destination before it is decrypted for transac-
tional purposes. This makes it impossible for cybercriminals to access cardholder data
in a form that is usable to them in open markets.
ENCRYPTION
From a merchant perspective, the goal of tokenization and transaction encryption
is to effectively protect cardholder data by eliminating it from merchant environments,
STORAGE SECURITY reducing the obligation that the merchant has to comply with the Payment Card Industry
Data Security Standard (PCI DSS). Although they are still in early stages, many mer-
chants wish to adopt these technologies now. In fact, recent research from Forrester
WLAN SECURITY Research Inc. indicates that merchants’ appetite for adopting tokenization is outpacing
the industry’s ability to provide a mature and industry-accepted tokenization product.
Abstracting and encrypting cardholder data are powerful security practices that have
SPONSOR RESOURCES the potential to transform the payment industry and benefit all stakeholders in the trans-
action chain. However, both technologies are immature and there are several steps organ-

13 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

izations should take when evaluating tokenization or transaction encryption products.

Forrester recommends that security and risk professionals take the following steps:
1. Take it slow. Security and risk professionals who are considering adopting tok-
enization need to make certain their chosen provider is contractually obligated to
respond to changes in the payment ecosystem that may have an impact on their pro-
posed product. Each vendor implements tokenization differently. It is possible that a
particular implementation may be shown to be problematic or insecure in the future as
a system is vetted by research and real world
attacks. This has happened in other areas It is possible that a
of security, such as the discovery that wireless particular implementation
protocols such as WEP and LEAP were insecure. may be shown to be
The card brands and the PCI Security Standards
Council (SSC) have not fully weighed in on this problematic or insecure
issue yet, so be aware that any technological in the future as a system
product currently extant is merely a guess as is vetted by research and
to the proper way to implement tokenization.
Currently, companies adopting these types
real world attacks.
of technologies are buying a highly customized product. Over time, the market will
weigh in and stabilize costs, but early adopters should expect to pay a premium.
Expect acquiring side entities to implement transaction encryption and tokenization
quickly, as the short-term costs will be inconsequential compared to the reduced risk
of a data breach and the immediate value to their customers.
2. Review how data is captured in a tokenized system. It’s important to understand
the two different ways in which credit cards are used by merchants’ card-present and
card-not-present transactions. Each type of transaction will need a specialized prod-
TABLE OF CONTENTS uct in order to take advantage of tokenization technology. While card-present transac-
tions will be the primary use case for tokenization, card-not-present transactions (i.e.
online or over the phone) can also be secured by tokenization.
DATA PROTECTION PCI DSS scope reduction may well rest on how the cardholder data is captured
and encrypted by a PIN entry device (PED) in a card-present transaction. Make cer-
tain that the cardholder data never passes from a PED to any other system in an unen-
TOKENIZATION crypted form. Since the overseers of PCI and credit card security have not weighed in
on this yet, play it safe and upgrade your swipe devices to ones that are cryptographi-
cally enabled and encrypt the cardholder data in hardware at the PED.
ENCRYPTION 3. Find ways to extend the value of tokenization and transaction encryption. Although
most companies are considering adopting tokenization or transaction encryption for
PCI DSS compliance purposes, remember that other data may benefit from these
STORAGE SECURITY technologies. If you deploy one of these technologies in-house, you may be able to
tokenize other sensitive data, such as personally identifiable information (PII), or
protected health information (PHI). An investment in tokenizing cardholder data
WLAN SECURITY can therefore be extended to almost any other type of regulated data, easing your
compliance burden overall.w

SPONSOR RESOURCES John Kindervag is a senior analyst at Forrester Research, where he serves security and risk
professionals.

14 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

Malware Protection
Data Protection
Business Productivity
IT Efficiency
Compliance
Hospital food

w or ry l e s s . a c c o m pl i sh m or e . w w w. s opho s . c o m
 | P CI DSS

S T O R AG E S E C U R I T Y

Assessment Success:
PCI DSS Standards
and Secure Data Storage
PCI DSS standards for secure data storage are specific and
detailed, but there are two key steps that can significantly

t
reduce the pain of an assessment. BY ANTON CH UVAKI N

Weaknesses in payment card data security practices present one of the top reasons
why enterprises fail Payment Card Industry Data Security Standard (PCI DSS) assess-
ments. Often prohibited data, such as CVV2 account security codes or personal iden-
tification numbers (PINs), is retained (which is strictly forbidden by PCI DSS) or
primary account numbers (PANs) are stored without adequate safeguards. Compared
to simpler—which is not to say simple—network security practices, PCI DSS stan-
dards for secure data storage present a challenging
problem for many merchants.
People not familiar with payment security People not familiar with
often spout generalities—like “use encryption”— payment security often
TABLE OF CONTENTS
without thinking about the extreme complexity spout generalities—like
of a globally distributed payment environment.
At the same time, QSAs report stories of
“use encryption”—without
DATA PROTECTION
discovering huge data dumps of unencrypted thinking about the extreme
cardholder data stored right on a merchant’s complexity of a globally
TOKENIZATION
Web server, visible to the whole world. distributed payment
We will share some tactical advice to help
organizations simplify the assessment process environment.
ENCRYPTION by streamlining their data storage practices and reducing PCI DSS assessment scope.
First, it is a common misconception that PCI DSS is about payment data security;
in reality, it is about reducing the risk of payment card transactions. The subtle differ-
STORAGE SECURITY ence here is that you actually can reduce the risk of transactions without implementing
a complex data security lifecycle or purchasing expensive tools that come with extensive
management overheads.
WLAN SECURITY Thus the answer is often not to encrypt the data, but to delete the data. Visa recom-
mends this very approach in its famous ongoing campaign: Drop the Data. In our
book, The PCI DSS Compliance Book, Branden Williams and myself start the chapter
SPONSOR RESOURCES on data security with: “Before we even start our discussion of data protection methods,
we need to remind the reader that ‘the only good data is dead data.’ Humor aside,

16 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

dropping, deleting, not storing and otherwise not touching the data is the best single
trick to make your PCI DSS compliance easier, as well as to make the transaction less
risky, reduce your liability, chance of fines and breach notification losses.”
The logic behind data destruction is simple: Today’s security technology is com-
plex and often requires maintenance (such as daily log review or security monitor-
ing), as well as use of inherently unreliable technologies (signature-based antivirus,
which only catches a modest percentage of attacks). As a result, expending efforts to
protect the data—and still failing—is an inferior strategy compared to making sure
data does not enter the environment. Clearly, this does not work with company intel-
lectual property (IP) and other secrets, but can be aimed for with payment data. After
all, we all accept that banks are better equipped for storing large amounts of data and
we don’t store millions in our place of business. Similarly, not having the card data
should become as obvious in the future.
But deleting data is only the beginning. Another key strategy to make your PCI
DSS assessment go more smoothly is to reduce scope. Given that complexity of PCI
assessments is directly proportionate to the scope—the PCI term for the size of card-
holder data environment and in turn the
number of systems that must be included Another key strategy to make
in an assessment—reducing that scope your PCI DSS assessment go
has an immediate impact on the assess- more smoothly is to reduce
ment process. Why? Having a QSA look
at 10,000 systems in a cardholder envi-
scope.
ronment, which can happen if an enterprise network is flat and cardholder data is not
segmented from the rest of the network, vs. only 10 systems, makes a huge difference in
the likelihood of success during an assessment.
So before the assessment—be it via QSA on-site assessment or SAQ self-assess-
ment—I highly recommend the following approach:
TABLE OF CONTENTS • Estimate the scope of your PCI assessment by counting all systems that trans-
mit, store or process cardholder data. As a reminder, even network devices that pass
unencrypted card traffic are in scope; not just transaction servers and gateways.
DATA PROTECTION • Try to predict where the unauthorized storage of cardholder data may take
place in your organization. Common data storage locations that are often forgotten
are developer environments or servers belonging to other business units, like the
TOKENIZATION marketing department. Scope creep is indeed dangerous if every developer workstation
becomes “in scope” due to using real card data for system testing (by the way, this
practice is explicitly forbidden in PCI DSS).
ENCRYPTION
• Next, with your scope and hand, rank the systems by the amount of sensitive data.
• Go down the list and try to understand how your business processes can be
changed to avoid storing the data – or at least how to run a business by storing less
STORAGE SECURITY
of it. This is the most critical step; any data that can be deleted (or never stored in the
first place) will serve to reduce scope and, in turn, make the assessment process easier.
• Then, look at the data that can’t be deleted and check if you can store it for a
WLAN SECURITY
shorter period. This reduces the risk of compromise against historical data.
• Consider using modern approaches to data protection, such as tokenization,
SPONSOR RESOURCES
which can help avoid storing the data in favor of a harmless token instead.
• Finally, examine the step-by-step payment process to determine whether any part

17 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

of it can be outsourced to a secure payment provider; such a relationship can help reduce
risk as well as PCI assessment scope. The reality is that information security will never be
a core competency for most merchants. Thus, structuring a relationship with a service
provider is simpler than analyzing applications for cross-site scripting or writing correla-
tion rules for a security information and event management (SIEM) product.

Only after going through the above steps should you think about using various
additional technical safeguards, such as strong access controls, encryption, etc., to
protect the remaining data. It is likely that your environment will use a combination
of strong access controls and data encryption. The encryption choices are: disk
encryption, file encryption (for flat-file data storage) and database encryption (for
databases of cardholder data). The latter can be further divided into multiple
approaches to encrypt the records in a database.
A common maxim in information technology states, “encryption is easy, key
management is hard.” That is why the PCI DSS document dedicates so much space to
key management. Specifically, Requirement 3.5 (“Protect cryptographic keys used for
encryption of cardholder data against both disclosure and misuse”) and 3.6 (“Fully
document and implement all key-management processes and procedures for crypto-
graphic keys used for encryption of cardholder data”) focus primarily on this area.
Both of these requirements have multiple sub requirements, such as 3.5.2 (“Store
cryptographic keys securely in the fewest possible locations and forms”) and 3.6.6
(“Split knowledge and establishment of dual control of cryptographic keys”).
Be sure to also avoid common encryption mistakes, such as those mentioned in
my related technical paper, “Five Mistakes of Encryption”, such as storing encryption
keys in the same database as the encrypted data, or using hard-coded fixed passwords
embedded in program code.
TABLE OF CONTENTS While thinking of simplifying PCI assessment scope and reducing the risk to pay-
ment card transactions, focus first on eliminating the data and thus reducing the
scope; safeguards and protections should come later.
DATA PROTECTION Specifically, leave more complex security safeguards such as data encryption until
the very latest time. While some people are concerned with outsourcing, for many
merchants outsourcing to a secure payment provider gives assurance to the merchant
TOKENIZATION and their customers that the data will be better protected from attackers. At the very
least, investigate recent approaches for “killing the data” such as tokenization.w

ENCRYPTION Anton Chuvakin is a recognized security expert in the field of log management and PCI DSS
compliance.

STORAGE SECURITY

WLAN SECURITY

SPONSOR RESOURCES

18 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

WLAN SECU R ITY

Wireless Network Guidelines

for PCI DSS Compliance
Does the PCI Security Standards Council’s additional
guidance for WLANs make the compliance process easier?
BY B E N ROTH KE

i
IN JULY 2009, the PCI Security Standards Council released its PCI DSS Wireless
Guidelines (.pdf), which provide an excellent set of details on how organizations that
use or seek to implement 802.11 Wi-Fi networks can ensure they comply with the PCI
DSS requirements. While the Payment Card Industry Data Security Standard (DSS)
specification provided the base details, many organizations found they needed more
specifics on how WLANs affect PCI DSS compliance.
The new document provided guidance and installation suggestions in areas such
as how to limit the PCI DSS wireless scope and practical methods for deployment of
secure wireless networks in payment environments. But there is a lot more to wireless
security than what is written in the 33-page document. In this tip, we’ll examine how the
Wi-Fi guidance enables PCI DSS compliance, and some additional best practices
enterprises should put in place to not only pass
a PCI DSS audit, but also better integrate secu- Many organizations
TABLE OF CONTENTS
rity into an existing Wi-Fi network. struggle with the PCI DSS
DATA PROTECTION wireless requirements,
Do the PCI Wi-Fi guidelines help?
If one takes the guidelines’ three chapters and
since the DSS never
methodically applies them to his or her wire- detailed the security
TOKENIZATION
less network, will it then be PCI DSS com- requirements for wireless
plaint? Ostensibly, yes. But adhering to the networks when it was
ENCRYPTION spirit of the mandate—protecting sensitive
electronic payment information—can only be initially released.
ascertained via in-depth analysis of the requirements, and a plan for compliance.
STORAGE SECURITY Many organizations struggle with the PCI DSS wireless requirements, since the DSS
never detailed the security requirements for wireless networks when it was initially
released. This is important as there are many new regulatory data protection require-
WLAN SECURITY ments and standards, of which PCI DSS is one. Beyond the regulations, every organi-
zation wants to ensure its data is secure, and its wireless networks remain protected
from external attacks. To most effectively design their security architectures, network
SPONSOR RESOURCES managers must understand the wireless security features of the networks they are
using, as well as their limitations.

20 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

Since wireless is often an add-on to an existing enterprise network, Chapter 2

addresses the Cardholder Data Environment (CDE). The PCI CDE is the computer
environment wherein cardholder data is transferred, processed or stored, and any
networks or devices directly connected to that environment. Organizations that add
wireless capabilities to a flat network will find out that their entire network is now
likely in scope for PCI DSS compliance.
Even though the PCI DSS is detailed, organizations needed more meticulous details
to help them understand how to apply the DSS to their wireless environments. The
guide provides that guidance and expands on
the practical methods for secure deployment Even though the PCI DSS
of wireless in payment card transaction envi- is detailed, organizations
ronments. needed more meticulous
For instance, Chapter 3 details the specific
wireless requirements for PCI DSS and general
details to help them under-
networking. The guidelines note that an entity stand how to apply the
must comply with the wireless requirements, DSS to their wireless
even if they do not use wireless as part of their
CDE. This is needed as the PCI DSS doesn’t
environments.
state how easy it is for someone to establish a rogue wireless access point on a network.
When a wireless access point is enabled, it will often have an Ethernet connection tied
into some part of the payment network. The wireless access point can then enable an
attacker to bridge the connections and gain access to the payment network.
The guide concludes with Chapter 4. It offers applicable requirements for in-scope
wireless networks, which details each of the specific requirements. Chapter 4 is the
most detailed chapter in the guide and provides the most technical information on
TABLE OF CONTENTS the specifics of securing wireless networks. Key points of the chapter include the
recommendation to disable all unnecessary applications, ports and protocols, to
not advertise organization names in the SSID broadcast, and more.
DATA PROTECTION
Beyond the guidelines
The PCI DSS Wireless Guidelines is a valuable document, but the underlying issue is
TOKENIZATION
that the recommendations written should have been implemented before any wireless
network was deployed. Organizations that are serious about wireless and security
should go beyond the guidelines and take the following steps:
ENCRYPTION
• Architecture—Ensure the wireless security architecture is centrally controlled,
with coordinated access points that are resistant to attack by securely configuring
them and ensuring they are patched.
STORAGE SECURITY
• Network diagrams—These are always valuable, but are even more crucial in a PCI
environment. Ensure your wireless network diagrams detail the locations of any wireless
WLAN SECURITY
devices on the network. Once that is done, validate the network diagram using wireless
scanning tools. You can use free open source tools such as NetStumbler or Kismet, or
more powerful commercial tools such as those offered by Motorola Inc.’s AirDefense
SPONSOR RESOURCES unit or AirMagnet Inc.
• Data mapping—Many organizations seek to guarantee that no cardholder data

21 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

goes over wireless. But the only way to verify that is by mapping the data. By docu-
menting how credit card transaction data flows over the network, you can then
determine if it is going over the wireless network, which would then be in scope
from a PCI perspective.
• Maintaining compliance—The hardest aspect is maintaining PCI compliance, as it
requires constant vigilance. Ensure you have detailed security and compliance man-
agement processes to ensure the wireless networks will remain PCI compliant.w

Ben Rothke CISSP, PCI QSA, is a senior security consultant with BT Professional Services.

TABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

SPONSOR RESOURCES

22 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI DSS

TE C H TA R G E T S E C U R I T Y M E D I A G R O U P

VICE PRESIDENT/GROUP PUBLISHER

Doug Olender

PUBLISHER Josh Garland

EDITORIAL DIRECTOR Michael S. Mimoso DIRECTOR OF PRODUCT MANAGEMENT

Susan Shaver
SEARCHSECURITY.COM
SENIOR SITE EDITOR Eric Parizo DIRECTOR OF MARKETING Nick Dowd

NEWS DIRECTOR Robert Westervelt SALES DIRECTOR Tom Click

ASSISTANT EDITOR Maggie Sullivan CIRCULATION MANAGER Kate Sullivan

ASSOCIATE EDITOR Carolyn Gibney ASSOCIATE PROJECT MANAGER

Allyson Kinch
ASSISTANT EDITOR Greg Smith
PRODUCT MANAGEMENT & MARKETING
ART & DESIGN Corey Strader, Andrew McHugh, Karina
CREATIVE DIRECTOR Maureen Joyce Rousseau

SALES REPRESENTATIVES
Eric Belcher ebelcher@techtarget.com

Patrick Eichmann
peichmann@techtarget.com

Jason Olson jolson@techtarget.com

Jeff Tonello jtonello@techtarget.com

Nikki Wise nwise@techtarget.com

TECHTARGET INC.
CHIEF EXECUTIVE OFFICER Greg Strakosch

PRESIDENT Don Hawk

EXECUTIVE VICE PRESIDENT Kevin Beam

TABLE OF CONTENTS
CHIEF FINANCIAL OFFICER Jeff Wakely

EUROPEAN DISTRIBUTION
Parkway Gordon Phone 44-1491-875-386
DATA PROTECTION www.parkway.co.uk

LIST RENTAL SERVICES

Julie Brown
Phone 781-657-1336 Fax 781-657-1100
TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY “Technical Guide on PCI DSS: Next-Generation Data Security, Storage and Integrity” is
published by TechTarget, 275 Grove Street, Newton, MA 02466 U.S.A.; Toll-Free 888-274-4111;
Phone 617-431-9200; Fax 617-431-9201.
All rights reserved. Entire contents, Copyright © 2010 TechTarget. No part of this publication may be
SPONSOR RESOURCES transmitted or reproduced in any form, or by any means without permission in writing from the publisher,
TechTarget or SearchSecurity.com.

24 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

Building Trust Around The Globe
When you want to establish trusted relationships
with anyone, anywhere on the internet, turn to Thawte.
Securing Web sites around the globe with:
• strong SSL encryption
• expansive browser support
• multi-lingual customer support
• recognized trust seal in 18 languages
Offering outstanding value, Thawte is for those
who know technology. Secure your site today
with a Thawte SSL Certificate.

www.thawte.com

© 2010 Thawte, Inc. All rights reserved. Thawte, the Thawte logo, and other trademarks, service marks, and designs are registered
or unregistered trademarks of Thawte, Inc. and its subsidiaries and affiliates in the United States and in foreign countries. All other
trademarks are property of their respective owners.
Database protection and
compliance made simple.
Guardium, an IBM Company, provides the simplest, most robust solution for
continuously monitoring access to high-value databases and automating compliance
controls for heterogeneous environments – assuring the integrity of trusted information
and enabling enterprises to drive smarter business outcomes.
• Gain 100% visibility and control over your entire DBMS infrastructure.
• Reduce complexity with a single set of cross-DBMS auditing and access control policies.
• Enforce separation of duties and eliminate overhead of native DBMS logs.
• Monitor privileged users, detect insider fraud and prevent cyberattacks.
• Automate vulnerability assessment, data discovery, compliance reporting and sign-offs.

For more information, visit

www.guardium.com/ISM

Copyright © 2010 Guardium, an IBM company. All rights reserved. Information is subject to change without notice. IBM, and
the IBM logo are trademarks of International Business Machines Corporation in the United States, other countries or both.
 | P CI DSS

SPONSOR RESOURCES

ArcSight
See ad page 2

• Providing Ultimate Protection for Cardholder Data

• Achieving PCI Data Security Standard (DSS) Compliance
• Combat Cybercrime, Demonstrate Compliance and Streamline IT Operations

Imperva
See ad page 4

• Imperva
• Web Application Security
• PCI DSS Compliance

Thawte
TABLE OF CONTENTS See ad page 25

• The Value of Authentication: Authentication + Encryption + Certification

DATA PROTECTION Authority = Trust
• Extended Validation SSL Certificates
TOKENIZATION • Understanding SSL Certificates

ENCRYPTION

STORAGE SECURITY Astaro

See ad page 12

WLAN SECURITY • The Dark Side of Cloud Computing

• Driving Profitability Through Information Security
SPONSOR RESOURCES • Reinventing Branch Office Security

27 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS

 | P CI-DSS

SPONSOR RESOURCES

Sophos
See ad page 15

• FREE Compliance for Dummies Book from Sophos

• Download the Sophos PCI Toolkit
• Learn more about PCI Compliance

nCircle
See ad page 19

• Download our Resource Guide: nCircle Resources for PCI

• Sign up for a FREE Certified PCI Scan
• Listen & Watch: Get Audit-Ready - Simplified PCI Compliance and
Agentless File Integrity Monitoring

TABLE OF CONTENTS Correlog

See ad page 23

DATA PROTECTION • PCI and other Compliance Datasheets

• CorreLog Enterprise Log Management Datasheet
TOKENIZATION • CorreLog Change Tracker-Change/Configuration Management Datasheet

ENCRYPTION

STORAGE SECURITY Qwest Communications

See ad page 7

WLAN SECURITY • Data Protection and Your Customers: How Payment Card Industry Compliance
Can Strengthen Your Business
• Advancing Retail Sales Through Technology Solutions
SPONSOR RESOURCES
• Connecting to Better Customer Service
28 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS
 | P CI-DSS

SPONSOR RESOURCES

Guardium
See ad page 26

• Your Enterprise Database Security Strategy 2010

• Essential Steps to Implementing Database Security and Auditing
• HOW TO Secure and Audit Oracle 10g and 11g: Hardening the Database

TABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

SPONSOR RESOURCES

29 S E A R C H S E C U R I T Y. C O M Technical Guide on PCI-DSS