1010_sS_TechGuide_PCI_DSS_v4

29
technical  guide on SEARCHSECUR ITY . C O M 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 PCI DSS: NEXT-GENERATION DATA SECURITY, STORAGE a n d INTEGRITY

Transcript of 1010_sS_TechGuide_PCI_DSS_v4

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 1/29

technical guide on

SEARCHSECUR ITY.COM

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

PCI DSS:NEXT-GENERATION

DATA SECURITY,STORAGE and 

INTEGRITY

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 2/29

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

Stop cybercriminals, enforce compliance and protect

your company’s data with ArcSight Logger.

© 2010 ArcSight. All rights reserved.

Just downloaded the customer

database onto a thumb drive.

Learn more at www.arcsight.com/logger.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 3/29

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

| T E C H N I C A L G U I D E O N PCI DSS

insight 

contents SEARCHSECURITY.COM presents a comprehensive guide to PCI DSS. Our

experts cover all the angles in order to help your efforts in meetingcompliance with the credit card industry’s data security standard.

PCI DSSThe 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 tec hnology investme nts.

5  PCI DSS compliance requirements: Ensuring data integrityDATA 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 PCITOKENIZATION 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 PCIENCRYPTION 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 storageSTORAGE 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 anassessment. 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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 4/29

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

Protecting the Data That Drives Business®

 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 DrivesBusiness are registered trademarks of Imperva.

Ac h i e v e Comp l i a n c e . S e c u re l y.

Imperva SecureSphere solutions enable medium enterprises

to achieve regulatory compliance. SecureSphere’s unmatched

Data Security capabilites include:

» AutomatedandaccurateWebapplicationsecurity 

» ICSA-certiedWebapplicationrewallforPCIDSSsection6.6

» Databasevulnerabilityassessmentsandriskscoring

» Pre-denedSOX,PCI,HIPAAreportsstreamlinecomplianceinitiatives» Provenandtrustedenterprise-classsecurityatareasonableprice

Imperva, the Data Security

leader, enables a complete

security lifecycle to provide

visibility and control for

business databases and the

applications that use them.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 5/29

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

PCI DSS ComplianceRequirements: EnsuringData Integrity

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

i 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), personalhealth 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-

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

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

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

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

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.

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

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

DATA PROTECTION

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 6/29

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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, whichmandates 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 youthink you have, and that only those who have appropriate access and authorization have

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

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

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 whereto go from there.w

As CSO-in-Residence, David Mortman is responsible for Echelon One’s research and analysis 

 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 

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.

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 7/29

   R I  S I   N   G   R I  S   K   T    O   C   U  S   T    O   M  E   R   D   A   T   A

IS

CUSTOMER DATA

CUSTOMER DATA

Copyright © 2010 Qwest. All Rights Reserved.

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.

WHAT’S t he BUSINESS PROBLEM?

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 8/29

The Future of PCI DSSEncryption Requirements?Tokenization for PCIWhat are the benefits of tokenization and is it right 

 for your organization?  BY RANDALL GAMBY

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

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

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

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 

tokenizing information further, let us discuss

why its counterpoint—encryption—has had

issues, and thus, why modifications are need-ed to deploy encryption technologies and

meet PCI encryption requirements.

Encryption for applicationsToday’s business flows for processing information may require a large number of systems

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

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.

TOKENIZATION

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

Today’s business flowsfor processing information

may require a largenumber of systems towork in lockstep witheach other.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 9/29

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

Encryption keys and standardsIn 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.

Tokenization for PCI DSS compliance, data protectionThe Payment Card Industry Data Security Standard (PCI DSS) encryption require-

ments mandate that credit card data be protected during processing and processes

must be modified to include these changes.

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

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

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

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

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

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

Information FlowENCRYPTION 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)

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 10/29

10 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

process the information.

When an application receives

tokenized data it needs to process,there are two choices: It can either

have the tokenization algorithms

added to its code to reverse the

process or, more commonly, con-

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, streetname, city, state, etc. so the name ‘Joe’ might become ‘John’ and ‘Smith’ becomes

‘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),

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);

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”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

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

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-

opment or testing activities.

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

Tokenization at Work

Production Data Test Data

Given name James Bob

Surname Smith Jones

Account No. 5009 9087 8793 5642 4567 8903 2890 4598

Exp. Date 3/11 12/12

CCV2 567 342

Birth date 3/12/78 3/12/67

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 11/29

11

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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. Thisnot 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 adoptionSo 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.

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 12/29

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 13/29

Ease Credit Card Risks:POS Encryption andData tokenization for PCI

Here’s what you need to consider before using tokenizationand transaction encryption to protect cardholder data.

BY JOHN KINDERVAG

13

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

 pPRETTY 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:

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.

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

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.

From a merchant perspective, the goal of tokenization and transaction encryption

is to effectively protect cardholder data by eliminating it from merchant environments,

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

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

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-

ENCRYPTION

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 14/29

14 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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

of security, such as the discovery that wireless

protocols such as WEP and LEAP were insecure.

The card brands and the PCI Security Standards

Council (SSC) have not fully weighed in on this

issue yet, so be aware that any technologicalproduct currently extant is merely a guess as

to the proper way to implement tokenization.

Currently, companies adopting these types

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 andcard-not-present transactions. Each type of transaction will need a specialized prod-

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.

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-

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.

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

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

can therefore be extended to almost any other type of regulated data, easing your

compliance burden overall.w

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

 professionals.

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

It is possible that aparticular implementationmay be shown to beproblematic or insecure

in the future as a systemis vetted by research andreal world attacks.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 15/29

Malware Protection

Data Protection

Business Productivity

IT Efciency

Compliance

Hospital ood

 worry less. accomplish more.   www.sophos.com

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 16/29

Assessment Success:PCI DSS Standardsand Secure Data Storage

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

16 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

t 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 

often spout generalities—like “use encryption”—

without thinking about the extreme complexity 

of a globally distributed payment environment.

At the same time, QSAs report stories of 

discovering huge data dumps of unencrypted

cardholder data stored right on a merchant’s

Web server, visible to the whole world.

We will share some tactical advice to help

organizations simplify the assessment process

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-

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.

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

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,

STORAGE SECURITY

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

People not familiar withpayment security oftenspout generalities—like“use encryption”—withoutthinking about the extremecomplexity of a globallydistributed paymentenvironment.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 17/29

17 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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

in an assessment—reducing that scope

has an immediate impact on the assess-

ment process. Why? Having a QSA look

at 10,000 systems in a cardholder envi-

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:

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

• 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

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

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

shorter period. This reduces the risk of compromise against historical data.

• Consider using modern approaches to data protection, such as tokenization,

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

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

Another key strategy to make your PCI DSS assessment gomore smoothly is to reducescope.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 18/29

18 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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 passwordsembedded in program code.

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.

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

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

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

compliance.

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 19/29

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 20/29

Wireless Network Guidelinesfor PCI DSS ComplianceDoes the PCI Security Standards Council’s additional 

guidance for WLANs make the compliance process easier? BY BEN ROTHKE

20 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

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-

rity into an existing Wi-Fi network.

Do the PCI Wi-Fi guidelines help?If one takes the guidelines’ three chapters and

methodically applies them to his or her wire-

less network, will it then be PCI DSS com-

plaint? Ostensibly, yes. But adhering to the

spirit of the mandate—protecting sensitive

electronic payment information—can only be

ascertained via in-depth analysis of the requirements, and a plan for compliance.

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-

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

managers must understand the wireless security features of the networks they are

using, as well as their limitations.

 WLAN SECU RITY

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

Many organizationsstruggle with the PCI DSSwireless requirements,since the DSS neverdetailed the securityrequirements for wireless

networks when it wasinitially released.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 21/29

21

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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

of wireless in payment card transaction envi-

ronments.

For instance, Chapter 3 details the specific

wireless requirements for PCI DSS and general

networking. The guidelines note that an entity 

must comply with the wireless requirements,

even if they do not use wireless as part of their

CDE. This is needed as the PCI DSS doesn’t

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

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.

Beyond the guidelinesThe PCI DSS Wireless Guidelines is a valuable document, but the underlying issue is

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

• 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

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

unit or AirMagnet Inc.

• Data mapping—Many organizations seek to guarantee that no cardholder data

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

Even though the PCI DSSis detailed, organizationsneeded more meticulous

details to help them under-stand how to apply theDSS to their wirelessenvironments.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 22/29

22 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI 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 scopefrom 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 .

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 23/29

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 24/29

24 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI DSS

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

TECHTARGET SECURITY MEDIA GROUP

VICE PRESIDENT/GROUP PUBLISHERDoug Olender 

PUBLISHER Josh Garland

DIRECTOR OF PRODUCT MANAGEMENTSusan Shaver 

DIRECTOR OF MARKETING Nick Dowd

SALES DIRECTOR Tom Click 

CIRCULATION MANAGER Kate Sullivan

ASSOCIATE PROJECT MANAGERAllyson Kinch

PRODUCT MANAGEMENT & MARKETINGCorey Strader, Andrew McHugh, Karina

Rousseau

SALES REPRESENTATIVESEric Belcher  [email protected]

Patrick [email protected]

Jason Olson  [email protected]

Jeff Tonello  [email protected]

Nikki Wise [email protected]

TECHTARGET I NC.CHIEF EXECUTIVE OFFICER Greg Strakosch

PRESIDENT Don Hawk 

EXECUTIVE VICE PRESIDENT Kevin Beam

CHIEF FINANCIAL OFFICER Jeff Wakely

EUROPEAN DISTRIBUTIONParkway Gordon Phone 44-1491-875-386www.parkway.co.uk 

LIST RENTAL SERVICESJulie BrownPhone 781-657-1336 Fax 781-657-1100

“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

transmitted or reproduced in any form, or by any means without permission in writing from the publisher,

TechTarget or SearchSecurity.com.

EDITORIAL DIRECTOR Michael S. Mimoso

SEARCHSECURITY.COMSENIOR SITE EDITOR Eric Parizo

NEWS DIRECTOR Robert Westervelt

ASSISTANT EDITOR Maggie Sullivan

ASSOCIATE EDITOR Carolyn Gibney

ASSISTANT EDITOR Greg Smith

ART & DESIGN

CREATIVE DIRECTOR Maureen Joyce

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 25/29

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

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 26/29

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.

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 27/29

27 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| P C I D S S

ArcSightSee ad page 2

• Providing Ultimate Protection for Cardholder Data

• Achieving PCI Data Security Standard (DSS) Compliance

• Combat Cybercrime, Demonstrate Compliance and Streamline IT Operations

ImpervaSee ad page 4

• Imperva

• Web Application Security 

• PCI DSS Compliance

ThawteSee ad page 25

• The Value of Authentication: Authentication + Encryption + CertificationAuthority = Trust

• Extended Validation SSL Certificates

• Understanding SSL Certificates

AstaroSee ad page 12

• The Dark Side of Cloud Computing

• Driving Profitability Through Information Security 

• Reinventing Branch Office Security 

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

S P O N S O R R E S O U R C E S

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 28/29

28 

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

PONSOR RESOURCES

| PCI-DSS

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

Sophos

See ad page 15

• FREE Compliance for Dummies Book from Sophos

• Download the Sophos PCI Toolkit

• Learn more about PCI Compliance

nCircleSee 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 andAgentless File Integrity Monitoring

CorrelogSee ad page 23

• PCI and other Compliance Datasheets

• CorreLog Enterprise Log Management Datasheet

• CorreLog Change Tracker-Change/Configuration Management Datasheet

Qwest CommunicationsSee ad page 7

• Data Protection and Your Customers: How Payment Card Industry ComplianceCan Strengthen Your Business

• Advancing Retail Sales Through Technology Solutions

• Connecting to Better Customer Service

S P O N S O R R E S O U R C E S

8/7/2019 1010_sS_TechGuide_PCI_DSS_v4

http://slidepdf.com/reader/full/1010sstechguidepcidssv4 29/29

ABLE OF CONTENTS

DATA PROTECTION

TOKENIZATION

ENCRYPTION

STORAGE SECURITY

WLAN SECURITY

| PCI-DSS

GuardiumSee 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

S P O N S O R R E S O U R C E S