1010_sS_TechGuide_PCI_DSS_v4
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
5
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
6
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
R
IS
K
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
8
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
9
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 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 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 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