These materials are the copyright of John Wiley & Sons ...lt.idg.com.br/thales/pci_compliance_for_dummies.pdf · These materials are the copyright of John Wiley & Sons, Inc. and any

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

http://www.thales-esecurity.com

Data Protection & PCI Compliance

FOR

DUMmIES‰

THALES SPECIAL EDITION

by Richard Moulds with Bridget Kenyon, QSA CISSP


Data Protection & PCI Compliance For Dummies®, Thales Special EditionPublished by John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030-5774 www.wiley.com

Copyright © 2012 by John Wiley & Sons, Inc., Hoboken, New Jersey

Published by John Wiley & Sons, Inc., Hoboken, New Jersey

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.

Trademarks: Wiley, the Wiley logo, For Dummies, the Dummies Man logo, A Reference for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. Thales and the Thales logo are trademarks or registered trademarks of Thales Corporation. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

For general information on our other products and services, please contact our Business Development Department in the U.S. at 317-572-3205. For details on how to create a custom For Dummies book for your business or organization, contact [email protected]. For information about licensing the For Dummies brand for products or services, contact BrandedRights& [email protected].

ISBN 978-1-118-37049-0 (pbk); ISBN 978-1-118-37218-0 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1


http://www.wiley.com

http://www.wiley.com/go/permissions

mailto:[email protected]

mailto:BrandedRights&[email protected]


Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

How This Book Is Organized .................................................... 1Who Should Read This Book .................................................... 2Icons Used in This Book ............................................................ 2

Chapter 1: Why Focus on Protecting Account Data? . . .3Seeing Why PCI DSS Matters..................................................... 3Understanding the Core Requirements of PCI DSS ................ 6Adopting a Data-centric Approach .......................................... 8Seeking the Holy Grail of Scope Reduction ............................ 9

Chapter 2: Examining Data Protection Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Encrypting Account Data in Transit (Requirement 4) ........ 12Protecting Stored Cardholder Data (Requirement 3) ......... 13Mastering Key Management ................................................... 21

Chapter 3: Choosing a Data Protection Strategy . . . . . .27Encrypting Network Traffic .................................................... 28Protecting Data in Storage Systems....................................... 32Protecting Data at the Point of Capture ................................ 36Choosing a Data Protection Solution .................................... 39

Chapter 4: Ten Keys to PCI DSS Success . . . . . . . . . . . .41Understand the Here and Now ............................................... 41Tailor Your Compliance Plan ................................................. 42Limit Your Exposure and Scope ............................................. 42Accept Responsibility in Outsourcing................................... 42Take a Holistic Approach ........................................................ 43Consider the Business Context .............................................. 43Sharpen Your Key Management Skills................................... 43Take Security to the Top ......................................................... 44Think of Security as a Journey ............................................... 44Keep Your Eyes on the Prize .................................................. 44


Publisher’s AcknowledgmentsWe’re proud of this book and of the people who worked on it. For details on how to create a custom For Dummies book for your business or organization, contact [email protected]. For details on licensing the For Dummies brand for products or ser-vices, contact BrandedRights&[email protected]. Some of the people who helped bring this book to market include the following:

Acquisitions, Editorial, and Vertical Websites

Development Editor: Kathy SimpsonProject Editor: Jen BinghamEditorial Manager: Rev MengleBusiness Development Representative:

Sue BlessingCustom Publishing Project Specialist:

Michael Sullivan

Composition Services

Project Coordinator: Kristie ReesLayout and Graphics: Carl ByersProofreaders: Susan Moritz

Publishing and Editorial for Technology Dummies

Richard Swadley, Vice President and Executive Group PublisherAndy Cummings, Vice President and PublisherMary Bednarek, Executive Director, AcquisitionsMary C. Corder, Editorial Director

Publishing and Editorial for Consumer Dummies

Kathleen Nebenhaus, Vice President and Executive PublisherComposition Services

Debbie Stailey, Director of Composition ServicesBusiness Development

Lisa Coleman, Director of New Market and Brand Development





Introduction

M ost systems for handling cardholder data were designed and implemented long before the threats

that we see today came into existence. Today, the Payment Card Industry Data Security Standard (PCI DSS) attempts to address those threats. Introducing technologies such as encryption and tokenization to meet the Standard can be a challenge, giving rise to serious operational and security implications. Consequently, some aspects of your environ-ment will probably have to change.

Our goal in this book is to provide an easy-to-understand introduction to protecting payment card data and a reference framework you can use as you work with architects, opera-tions, analysts, and assessors. We cover not just the PCI DSS mandates themselves but also ways in which you can employ data protection techniques to reduce the scope of your PCI footprint, which we hope will make your life easier and save you money.

You may wonder whether PCI DSS compliance is a worthwhile endeavor, a costly annoyance, or some of both. We hope that by the time you finish this book, you’ll agree that it’s not just worthwhile but also valuable. The goals, approaches, and benchmarks within the Standard have general applicability, and adopting them will almost certainly improve your overall security posture, support your broader privacy obligations, and ultimately protect your brand.

How This Book Is OrganizedThe book is divided into four chapters. Here’s what you’ll find:

✓ Chapter 1: Why Focus on Protecting Account Data? A refresher on the goals of PCI DSS and its structure, as well as the mandates associated with account data protection.


Data Protection and PCI Compliance For Dummies 2 ✓ Chapter 2: Examining Data Protection Requirements:

Specific Requirements for protecting data in transit and in storage, technology options, and key management challenges.

✓ Chapter 3: Choosing a Data Protection Strategy: Practical issues to consider when planning your imple-mentation, including the pros and cons of various approaches to reduce scope.

✓ Chapter 4: Ten Keys to PCI DSS Success: A reference to help keep your data protection efforts focused and on the track to success.

Who Should Read This BookIf your business accepts, processes, or manages payment card data, this book is for you. Whether you work in infor-mation technology (IT) security, auditing, risk management, compliance operations, or even finance, there’s something in it for you.

Icons Used in This BookAs you read this book, you’ll notice the following icons located in the margins. These icons highlight important points and information.

The Myth Buster icon marks topics that are frequently misun-derstood or misrepresented.

Tips are suggestions or shortcuts that could simplify your path to PCI DSS compliance.

The Remember icon points out important issues to keep in mind as you consider your path forward.

Warnings are words of caution about issues that could hold you back or trigger unintended consequences.


Chapter 1

Why Focus on Protecting Account Data?

In This Chapter▶ Introducing PCI DSS▶ Understanding the importance of protecting account data▶ Reducing the scope of assessment

Y ou can’t escape them: Fraud, hacking, insider theft, and human error affect virtually every business.

Unfortunately, the picture is much worse if you handle pay-ment card data. According to a recent study by Verizon and the U.S. Secret Service, 78 percent of data-breach incidents involved loss of payment card data, and across the incidents they investigated, 96 percent of records lost were payment card records.

PCI DSS is intended to help. This information security frame-work was designed by the leading players in the payments industry. This global Standard is published and maintained by the PCI Security Standards Council (PCI SSC), and compliance is mandatory for any organization that stores, processes, or transmits payment card data, officially referred to as account data. A statement attesting to PCI compliance must be made annually (but really, compliance is a year-round process).

Seeing Why PCI DSS MattersBefore you dive into the details in this chapter, it’s important to consider how PCI DSS fits into the broader security land-scape. Protecting payment-related data is certainly important,


Data Protection and PCI Compliance For Dummies 4but similar concerns about a much wider range of sensitive personal information — such as medical records, criminal backgrounds, and employment information — have elevated the issue of data protection, triggering numerous privacy laws and data-breach-disclosure obligations.

These broad external requirements, coupled with the long-standing need to protect corporate intellectual property, could lead you to conclude that PCI DSS is just a pesky com-pliance issue to keep the card brands off your back. That conclusion, however, would be a mistake. The reality is that PCI DSS says very little that’s specific to payment card data. In fact, many of the technologies and processes you might put in place to achieve PCI DSS compliance can be used to protect a wide variety of classes of data right across your extended enterprise.

Compliance, of course, is mandatory. Failure to take the appropriate steps would at the very least put you at a compet-itive disadvantage and make you liable for fines or other sanc-tions from the card brands or your acquirer (the organization that processes transactions on your behalf and that might be responsible for vouching for your PCI DSS compliance to the card brands). Worse, if you experienced a data breach, you’d be hit by fines that might otherwise be waived, and the accu-sations of negligence would come thick and fast.

Safeguarding account dataRegulation is nothing new to the payments industry. It’s been a fact of life for centuries. Technology mandates such as the protection of personal identification numbers (PINs) and other authentication credentials at ATMs and point-of-sale (POS) terminals have been in place for well over a decade. In many ways, PCI DSS merely expands the scope of protection to include other types of data such as cardholder name, card expiration date, primary account number (PAN), and other information.

This evolution sounds very logical, particularly because cards are increasingly used for online transactions, but it does raise some new and quite important issues. PINs, for example, are used transiently to authorize transactions and are rarely stored — which isn’t the case for other types of account data. Names, account numbers, and expiration dates are frequently


Chapter 1: Why Focus on Protecting Account Data? 5stored for a variety of reasons, including to enhance the user experience and to protect the merchant or payment processor. Table 1-1 presents the most common reasons for storing account data according to Qualified Security Assessors (QSAs), the people that are responsible for assessing compliance.

Table 1-1 Most Common Reasons for Storing Account Data, as Reported by QSAs Reason Frequency Encountered

Chargebacks 83%Customer service 68%Recurring subscription 61%Card reuse 32%Marketing analytics 19%Other reasons 2%Source: Ponemon Institute

While we’re on the topic of QSAs, it’s worth giving a little background on their roles. First of all, QSAs are individuals who are certified by the PCI SSC to assess compliance. They must be employed by validated QSA companies (there are no freelance QSAs). The rules vary slightly by card brand, but in most cases you won’t actually be required to work directly with a QSA. An internal self-assessment and self-generated statement of compliance may be acceptable, particularly for smaller merchants. Check with your acquirer to be sure you understand your obligations. But whether or not you are forced to use a QSA, talking with one can be a valuable source of infor-mation and guidance as you prepare for assessment and then maintain compliance over the long run.

Maintaining a universal security standardAccount data can easily find its way into a wide variety of business systems, ranging from transaction processing to customer relationship management and added value systems such as loyalty and customer support. It’s also easy to see that account data isn’t just found in traditional merchants,


Data Protection and PCI Compliance For Dummies 6but also in service providers, business partners, and even offshore developers. The challenge is that all of these environ-ments need to be protected to achieve compliance with PCI DSS. The Standard, therefore, has breadth and depth that far exceed those of other privacy and data-security mandates.

It’s tempting to be somewhat cynical about the Standard, viewing it as merely a vehicle for addressing the card brands’ most worrisome risks, since it does focus on protecting “their” data — the information contained on payment cards. The Standard isn’t necessarily trying to address the risks that you care about, so some of the required controls may seem less than ideal from your perspective. On the whole, however, security experts tend to agree that it represents good basic practice. Some aspects of the Standard are new to many orga-nizations, but the areas it covers are certainly areas in which genuine risk does exist.

The Standard was designed to be applied consistently by all companies around the world, from one-man bands to huge multinational corporations. But in practice, interpretation will always have to take into account your specific situation. Local variations may exist, and if a conflict exists between PCI DSS and local laws, those laws take precedence.

Understanding the Core Requirements of PCI DSS

To achieve the desired breadth, PCI DSS consists of 12 pub-lished Requirements, which in turn are made up of more than 250 specific statements. The Requirements, which should be considered as a mutually supporting set rather than in isola-tion, are organized into six groups (see Table 1-2).

Table 1-2 PCI DSS RequirementsGroup Requirements

Build and Maintain a Secure Network

Requirement 1: Install and main-tain a firewall configuration to protect cardholder data.


Chapter 1: Why Focus on Protecting Account Data? 7

Group Requirements

Requirement 2: Do not use vendor- supplied defaults for system passwords and other security parameters.

Protect Cardholder Data Requirement 3: Protect stored cardholder data.Requirement 4: Encrypt transmis-sion of cardholder data across open, public networks.

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update antivirus software or programs.Requirement 6: Develop and maintain secure systems and applications.

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need to know.Requirement 8: Assign a unique ID to each person with computer access.Requirement 9: Restrict physical access to cardholder data.

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data.Requirement 11: Regularly test security systems and processes.

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security for all personnel.

Source: PCI Security Standards Council

This list of Requirements may seem to be very daunting, particularly if you’re a small or medium-size merchant, but remember that you’re not on your own. For most card brands, the enforcement of PCI DSS compliance by merchants is the responsibility of the acquirers, so it’s generally in everyone’s interest to help merchants succeed in protecting account data


Data Protection and PCI Compliance For Dummies 8and achieving compliance. In fact, many acquirers offer ser-vices to help simplify the process for merchants.

You may have noticed that the Requirements refer to card-holder data, whereas so far in this book we have used the term account data. It’s an important distinction that we cover in more detail in Chapter 2, but it’s worth remembering that the term account data relates to all types of information that PCI DSS is designed to protect. Account data includes cardholder data (PAN, cardholder name, expiration date, service code) and sensitive authentication data (PIN, PIN block, contents of magnetic stripe, and security code/CVV2).

It’s easy to see how confusion about PCI DSS can arise and myths can propagate quickly. The PCI SSC website (www.pcisecuritystandards.org) is a good source for clari-fication and updated guidance. For starters, download Ten Common Myths of PCI DSS at www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf.

Adopting a Data-centric Approach

PCI DSS, almost by definition, is a data-centric standard. Data (in this case, account data) flows through the entire organi-zation, and this raises a variety of interesting issues that we attempt to address throughout this book:

✓ The data that passes through different parts of the IT infrastructure may be owned by different teams.

✓ The data is subject to various security technologies that are already in place — some old, some new, some in line with PCI DSS, and some not.

✓ The data will be used and stored for different reasons, and each reason is subject to different business drivers and constraints.

✓ The data will exist in structured, unstructured, and even paper-based forms.


Chapter 1: Why Focus on Protecting Account Data? 9 ✓ The data will fall into the hands of the end user, finding

its way into e-mail messages, spreadsheets, and thumb drives — where it is effectively beyond the control of IT staff.

Although PCI DSS is itself a data-centric standard, the majority of the 12 Requirements focus on the environment in which the data exists, addressing such issues as the need for security policies and access controls, the use of antivirus software, and avoidance of default passwords. Only Requirements 3 and 4 focus on the protection of the data itself.

These two Requirements collectively protect data as it moves over vulnerable networks and as it is stored. This area is where PCI DSS overlaps most with many of the more generic privacy mandates and data-breach-disclosure laws. Yet Requirements 3 and 4 represent some of the most taxing aspects of PCI DSS compliance, often requiring unfamiliar technologies and practices (such as key management; see Chapter 2) and involving multiple touchpoints within organi-zations, crossing business silos and political domains.

Because of the relative complexity of protecting data and satisfying Requirements 3 and 4, the remainder of this book focuses almost exclusively on this topic. But as we get into the detail, you will see that data-protection technologies such as encryption aren’t just ways to achieve compliance with these two Requirements; they also have the potential to reduce the scope of your overall PCI DSS compliance obliga-tion (a topic we introduce in the next section).

Seeking the Holy Grail of Scope Reduction

While working to secure payment card data, almost every organization rightly looks for opportunities to reduce the scope of its PCI DSS obligations. Reducing the number of systems, networks, applications, locations, administrators, and users covered by PCI DSS reduces business disruption, costs, complexity, and time spent on documentation. All these reductions minimize your compliance footprint.


Data Protection and PCI Compliance For Dummies 10

Nothing can eliminate all systems and all data from being in scope for PCI DSS. After all, if you’re accepting or processing payments, at least some part of your environment must be exposed to account data. Even if you outsource everything, you still have to ensure your service provider adheres to the Standard.

It’s fair to say that guidance regarding scope management has been rather vague. Recently, however, the PCI SSC advised that under certain circumstances account data that has been rendered unreadable can be considered out of scope from a PCI DSS perspective.

If both of the following circumstances apply, then the systems holding the unreadable data are not in scope:

✓ If systems that hold this data are unable to make it read-able again.

✓ If they’re segmented from systems that can read the data.

PCI DSS, in the form of Requirements 3 and 4, requires account data to be made unreadable (by encryption, for example) only while that data is passing over open or public networks or when it’s stored. As we discuss in Chapter 3, however, you have the opportunity — and potentially a strong business case — to go beyond these base Requirements, both to improve security and to reduce scope.

Before you consider implementation options, it’s important to gain a clear understanding of the obligations defined by Requirements 3 and 4 and of the technologies that they man-date. We discuss both of these topics in Chapter 2.


Chapter 2

Examining Data Protection Requirements

In This Chapter▶ Protecting data in transit▶ Protecting data in storage▶ Meeting the challenges of key management

O f the twelve Requirements defined by PCI DSS (see Chapter 1), the two that are grouped under the title

Protect Cardholder Data are:

✓ Requirement 3: Protect stored cardholder data.

✓ Requirement 4: Encrypt transmission of cardholder data across open, public networks (note that this title is slightly misleading because it actually applies to all forms of account data, not just cardholder data).

These Requirements incorporate more than 20 lower-level testing procedures, which can be summarized as follows:

✓ Don’t store cardholder data if you can avoid it (but almost everyone does, so see the next paragraph).

✓ Protect cardholder data everywhere it’s stored, from data centers to tape backups and from laptops to log files.

✓ Encrypt cardholder data (and any other type of account data) as it moves over any vulnerable network, particu-larly Wi-Fi and the Internet.

✓ Make sure that the way you’re protecting data can be demonstrated but can’t be compromised.


Data Protection and PCI Compliance For Dummies 12In this chapter, we cover Requirements 3 and 4 in detail, along with some technologies you can use to address them. Because protecting stored data is quite a bit more complex than pro-tecting data in transit, we discuss these two Requirements in reverse order.

Encrypting Account Data in Transit (Requirement 4)

Account data is always on the move. After all, it’s often used to complete a transaction across the multiple agents in modern payment networks. Along the way, that data is likely to encounter in-store wireless networks, virtual private net-works (VPNs), corporate backbones or wide area network (WAN) connections, the Internet, and even cloud-based envi-ronments. All these networks offer various degrees of native security. Some can give eavesdroppers a front-row seat, and others make unauthorized access much more difficult; some are under enterprise control, and others aren’t.

To establish some level of consistent protection, PCI DSS ded-icates one of the twelve Requirements purely to the topic of protecting data in transit. Requirement 4 (“Encrypt transmis-sion of cardholder data across open, public networks”) pro-vides the most concise and specific instructions in the whole Standard, covering any networks that are “easily accessed by malicious individuals.” Satisfying the Requirement involves validating the implementation and configuration of security protocols, and in the case of encryption, verifying that the appropriate strength is used to address the prevailing risks. The Requirement also makes it clear that only trusted keys and certificates should be used, a topic we discuss in more detail later in this chapter.

“Open, public networks” definedThe question is this: What constitutes an “open, public net-work”? The Standard makes it clear that the list includes the Internet and wireless networks (including Wi-Fi and cellular), as well as end-user messaging technologies such as e-mail, instant messaging, and chat.


Chapter 2: Examining Data Protection Requirements 13

Gray areas in network protectionGray areas exist, however. What about corporate backbones, networks within outsourced data centers, and even cloud computing environments — are they open or public? Very few organizations own and operate their own WAN environments; instead, they share high-speed networks with other tenants, which raises the question of trust. Can your managed service provider (MSP) ensure that eavesdroppers or even men in the middle aren’t listening to — and potentially corrupting, substituting, or even rerouting — your information? Your MSP will tell you that its network is safe, but can it back up the claim, and if not, how will you persuade your PCI DSS asses-sor that everything is okay? Most assessors fall on the side of caution (they’re those sorts of people!) by concluding that the network you use is open unless you can prove otherwise.

You may not even be able to assume that your own internal networks — even the ones whose wires you physically own — are exempt from the need for encryption, either now or at some point in the future. The language of Requirement 4 refers to networks that are “easily accessed by malicious individuals” and that could certainly apply to insiders.

In the next section, we discuss protecting stored cardholder data, which raises additional challenges.

Protecting Stored Cardholder Data (Requirement 3)

PCI DSS has always placed a great deal of emphasis on the protection of stored cardholder data. Whereas eavesdrop-pers on a network can capture live transactions or individual messages, the theft of stored data can be much more harmful, resulting in the loss of large amounts of valuable information, potentially spanning many years of activity. When it comes to protecting stored data, however, the Standard is less pre-scriptive than it is with data in transit. Requirement 4 con-tains an explicit mandate to encrypt data in transit. However, in the case of stored cardholder data, there is only the more general obligation to render stored data “unreadable,” and there are several suggested methods for achieving this.



The best advice (it’s actually explicit in the Standard) is to store as little cardholder data as possible and to destroy that data as soon as it’s no longer needed. The only reason to store data is if you will need it in the future.

Watch out, though: Any process that makes stored data unreadable could make it permanently unavailable. That could be a very bad thing — possibly even a career-affecting event.

Knowing the data storage rulesBefore you consider the various approaches to making data unreadable, it’s important to understand what types of data may be stored and — more important — what must not be stored at all. Table 2-1 summarizes the rules.

Table 2-1 Cardholder Data Protection and Storage RequirementsAccount Data Storage

PermittedRender Unreadable

Cardholder DataPrimary Account Number Yes YesCardholder Name Yes NoService Code Yes NoExpiration Date Yes NoAuthentication DataFull Magnetic Stripe Data or equivalent on a chip

No N/A

CAV2/CVC2/CVV2/CID No N/APIN/PIN Block No N/A

The first thing to note is that the various types of sensitive authentication data can’t be stored at all after a transaction has been authorized, even if they’re encrypted. Only the subset of account data called cardholder data can be stored. But, out of all the various elements of cardholder data, only the primary account number (PAN) must be stored in an unreadable format. Other forms of cardholder data, such as


Chapter 2: Examining Data Protection Requirements 15cardholder name and expiration date, may be stored in the clear. But don’t forget, even though it’s not necessary to make these classes of cardholder data unreadable, you still must protect them in accordance with the other aspects of PCI DSS whenever they’re stored.

Making stored data unreadablePCI DSS suggests four alternative methods for rendering PAN information unreadable when it’s stored (Requirement 3.4):

✓ One-way hashes

✓ Truncation

✓ Tokenization

✓ Encryption

The Standard also mandates the use of masking for displaying account data to anyone who doesn’t have a legitimate need to access the full PAN (Requirement 3.3).

These techniques aren’t new and certainly aren’t specific to protecting cardholder data. Many organizations already have experience with some or all of these approaches. In this sec-tion, we briefly review each of them in the context of PCI DSS compliance.

As you identify your organization’s stored data, consider more than just intentionally stored data — data that you con-sciously placed in databases, archives, and the like. Account data can also be inadvertently saved in many other places, such as audit logs, e-mail archives, portable devices, and even call-center voice recordings. In the eyes of your assessor it all counts as stored account data, and if it shouldn’t be there or, in the case of PANs, it isn’t unreadable, you will be in trouble: no exceptions!

MaskingStrictly speaking, masking relates only to protecting stored data when it’s displayed and not to protecting the data while it is actually stored, but we cover it in this section for com-pleteness. Masking is mandated by the Standard for maintain-ing confidentiality of data after it has been taken out of the storage environment and is presented to a person. The


Data Protection and PCI Compliance For Dummies 16process is familiar to anyone who has used a card in a res-taurant or shop and then checked the printed receipt, finding that certain digits of the PAN — and, in some cases, the expi-ration date — are shown as Xs rather than the actual digits, as illustrated in Figure 2-1.

Stored PAN6011-0009-9013-9424 Mask

Displayed masked PAN6011-00XX-XXXX-9424

Figure 2-1: Masking a PAN for display purposes.

TruncationTruncation renders stored data unreadable by ensuring that only a subset of the complete PAN is stored. In fact, according to PCI DSS, if truncation is used, then no more than the first six and last four digits can be stored, as illustrated in Figure 2-2. This tech-nique is probably the easiest way to protect stored cardholder data, but it suffers from a major drawback, it’s not reversible.

Received PAN6011-0009-9013-9424 Truncate

Stored truncated PAN6011-9424

Discarded digits: 0009-9013

Figure 2-2: Truncating a PAN.

Truncation may be the right choice for storing copies of the PAN in account records to be used by customer service agents, where it is only used as a means to authenticate the cardholder or to distinguish between accounts if a cardholder has multiple cards, for example.

But a PAN stored in truncated form is no longer a valid PAN because a proportion of the original data was discarded when


Chapter 2: Examining Data Protection Requirements 17it was stored. So it won’t be possible to use that truncated PAN for subsequent transactions, which is one of the main reasons that cardholder data is stored in the first place. Also, because data has been discarded, each truncated PAN may no longer be unique. Two different PANs may appear to be the same after they’re truncated, which may affect your ability to use truncated PANs as indexes or customer identifiers when you’re handling chargebacks, for example.

One-way hashingA hash function is a well-defined, provably secure crypto-graphic process that converts an arbitrary block of data — in this case, a PAN — to a different string of data that’s unique to the original. In other words, every different PAN will yield a different result. The process, which is irreversible (that’s why it’s called a one-way hash), is commonly used to check that data hasn’t been modified because any changes to the original block of data would result in a different hash value.

Figure 2-3 illustrates the use of the hash function in the con-text of PCI DSS. It provides confidentiality (it’s effectively impossible to re-create a PAN from a hashed version of that PAN), but like truncation, it makes using the stored data for subsequent transactions impossible.

Received PAN6011-0009-9013-9424 Hash

Stored hashed PANa6?Dy81

Figure 2-3: One-way hash of a PAN.

TokenizationTokenization is a process that replaces the original PAN with surrogate data, a token (it may even look just like a legitimate PAN) that has no value to an attacker. Most implementa-tions enable the process to be reversible — tokens can be converted back to the original PAN on request. This enables tokenization to be used in situations where stored PANs need to be accessible in order to make subsequent transactions.


Data Protection and PCI Compliance For Dummies 18Tokens can be created in a variety of ways. Two common approaches are:

✓ Tokens calculated directly from the original PAN value. This method yields the same token for each given PAN, a process that is said to be “deterministic.”

✓ Tokens generated randomly. This method yields differ-ent tokens every time (unless an exhaustive lookup of previous PANs is used to consciously reuse a previously issued token).

The degree to which the tokenization process is deterministic could be very important in certain operational scenarios. It all depends on what the tokens are used for.

A common goal of data protection activities is to avoid the need to modify the various applications that handle the pro-tected data. By arranging the tokenization system such that the tokens look as much like PAN values as possible, it is real-istic for certain applications that already expect to see PAN values (but don’t actually need to know the real PAN values) to continue working, oblivious to the fact that the PAN values have been replaced. In some cases, it might be desirable to preserve not just the format of the PAN during the tokeniza-tion process but also certain of the PAN digits (see Figure 2-4). However, this preservation requires considerable care.

Only those applications that need access to the real PAN will need to have access to a detokenization service. Similarly, any data that needs to be sent to an external organization like your acquirer or payment processor will probably have to be detokenized first.

Received PAN6011-0009-9013-9424

Tokenize/Detokenize

PAN/Token vault

Stored tokenized PAN4012-9424-6264-9424

Figure 2-4: Tokenization of a PAN (last four digits preserved).



Tokens aren’t actually PANs, so they — and the systems that are exposed to them — are out of scope from a compli-ance perspective. Only the systems that can perform the tokenization process or request access to the original PANs are in scope. These systems effectively become repositories of all PANs and their associated tokens; therefore, they’re highly sensitive. Needless to say, your assessor will be keenly focused on testing the strength of your access controls around any detokenization service.

When you assess the security properties of tokenization sys-tems or services, think of tokenization as being a generic data transformation process, rather than a standardized algorithm or protocol. Implementations can vary widely, and you should be prepared to ask tough questions; you can bet that your assessor will.

EncryptionEncryption has goals similar to tokenization’s, in that PAN data is replaced by data that has no intrinsic value to an attacker; therefore, like tokenization it has the potential to reduce scope from the perspective of PCI DSS compliance.

Encryption uses standardized cryptographic algorithms and keys to derive the encrypted PAN from the original data. Because the algorithms are widely known, the security of the process hinges on the secrecy of the cryptographic keys.

Guidelines for tackling tokenizationThe PCI SSC issued specific guidance about tokenization in August 2011 in a document called Information Supplement: PCI DSS Tokenization Guidelines (www.pcisecurity standards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf). It describes the major components of a tokenization system and high-lights its primary security aspects,

including how tokens are generated, mapped to PANs, and protected when stored, and how access to the system is controlled. The docu-ment also deals with the topic of distinguishing tokens from real PAN values — a very important task from an assessing point of view, because it’s necessary to prove that data objects that look like PAN data are in fact only tokens.


Data Protection and PCI Compliance For Dummies 20Anyone or anything that has access to the keys can encrypt and, more importantly, decrypt the data that was encrypted with those keys. Key management, therefore, is a critical issue in encryption — so critical that we devote the last section of this chapter to this topic.

The fact that encryption and decryption are fixed mathemati-cal processes yields an important benefit: Systems that need to protect or unprotect PAN data (or any other information, for that matter) can perform the conversion process locally, pro-viding they have a copy of the correct key. This is in contrast to tokenization-based systems, where it’s often the case that data to be protected has to be sent to a shared tokenization service when the tokens are generated, and the original data is retained for subsequent detokenization. This is particularly powerful when encrypted data needs to be shared with external parties. The receiving party, such as a business partner, simply needs a copy of the appropriate key to decrypt the data. With tokeniza-tion, however, the receiving party needs access to a shared de-tokenization service. For this reason, encryption is the primary means of protecting card-based transactions in which PINs are exchanged across payment networks.

The encryption process generally changes the format of the data. Typically, the size of data increases when that data is encrypted. For the same reason that tokenization attempts to preserve the format of the original PAN data — to minimize changes to existing systems that come into contact with the data — a particular class of encryption known as format-preserving encryption (FPE; see Figure 2-5) is often employed. Currently, certain implementations of FPE are undergoing standardization; you should verify that they’re suitable before using them.

Received PAN6011-0009-9013-9424

Encrypt/Decrypt

Key manager

Stored encrypted PAN7823-1264-7835-9424

Figure 2-5: Encryption of a PAN (using format-preserving encryption and with preservation of last four digits).



Mastering Key ManagementWhether you’re managing keys associated with encrypting data in transit, or those associated with encrypting stored data, it’s important to ensure that you’re in full control of those keys and living up to the standards of due care set forth in PCI DSS.

Even if you use tokenization to protect stored data, you may still have a large number of keys to manage. Many implemen-tations of tokenization systems use a shared token database that’s highly security-sensitive and completely in PCI DSS scope because the token database contains PAN data — and potentially large amounts of it. The only practical way to pro-tect that database is through encryption.

Key management RequirementsPCI DSS places considerable emphasis on key management. The Standard distinguishes between the protection of keys and the management processes associated with keys, and it does a great job of identifying the important issues that you should consider as you define your key management strategy.

In particular, the Standard makes the important observation that its Requirements apply to all keys associated with pro-tecting cardholder data — not just the keys used to actually encrypt data (data-encrypting keys) but also the keys used to encrypt these encryption keys (key-encrypting keys or KEKs). In some cases many tiers of key encryption may exist, making up a whole hierarchy of KEKs, with the keys at the highest tiers potentially protecting thousands or even millions of data-encrypting keys. There’s a good argument to be made that the keys that are highest in the hierarchy — effectively, the “keys to your kingdom” — deserve even greater protec-tion, which is something that your QSA can advise you about.

Protecting keys (Requirement 3.5)Requirement 3.5 (“Protect any keys used to secure cardholder data against disclosure and misuse”) contains a couple of subsections:


Data Protection and PCI Compliance For Dummies 22 ✓ Restricting access to as few users as possible: These

users are more formally called key custodians.

✓ Storing keys securely by ensuring that data-encrypting keys are always encrypted and stored separately from that data: The same applies to KEKs. This rule sounds obvious, but you’d be surprised by how rarely it’s followed.

✓ Storing keys in as few locations and forms as possible: Again, this rule sounds obvious, but the more places a key is stored, the greater the risk that an attacker may obtain a copy.

These Requirements aren’t as easy to satisfy as they may seem. Essentially, they mean that you need to track every instance of keys being stored and used. That job is a big one when you consider the rate of change in your user community and the generation upon generation of back-ups, archives, and fail-over copies spanning diverse applications across your organization. If you’re unable to destroy keys (and all copies of those keys) as they reach the end of their useful lives, this challenge just gets tougher and tougher. These key management issues can impinge on your activities in the areas of identity management, user provisioning, and data and storage management.

The need to protect keys goes beyond just preventing them from being stolen while they’re stored. An attacker who can’t actually steal a key may still employ various methods that make it easier to guess a key (keys are just very big numbers, after all) or otherwise intervene in the process of using or managing keys to decrypt data.

Documenting processes (Requirement 3.6)Requirement 3.6 defines a specific need: “Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data.” This statement highlights some of the most pertinent aspects of what is often referred to as the key management lifecycle:

✓ Generation of strong keys: Creating keys that are truly random and of the appropriate length — making them harder to guess or analyze — is harder than it sounds.


Chapter 2: Examining Data Protection Requirements 23 ✓ Secure distribution of keys: Sharing keys between

organizations or even individuals is also harder than it sounds. Issues such as authenticating the parties involved, establishing trust, and enforcing policies (what people can do with the keys) in a way that you can easily demonstrate to assessors, requires careful thought.

✓ Periodic rotation of keys: Keys have natural lifetimes. The longer they live or the more data they encrypt, the greater the risk that they’ll be compromised. You should have formal processes for changing and replacing keys on a regular basis.

✓ Revocation of keys: Any key that faces an unacceptable risk of being compromised, that is suspected to have been compromised, or that is known to have been com-promised, must be withdrawn from service. Again, this is easier said than done, particularly if multiple copies of those keys exist. Worse, if those keys have been used to encrypt data, you may have no option but to create a new key to re-encrypt all that data.

✓ Split knowledge and dual control: Whenever keys exist as clear text (not encrypted) and are being managed manually, more than one person must be involved. This practice would typically apply to virtually the entire key management lifecycle. No single person can have access to the entire key. Instead, fragments or components of keys should be shared across several people who under-stand and have formally accepted their roles in the pro-cess. No super-user is allowed to have knowledge of a full key, no matter how senior he or she may be.

✓ Prevention of key substitution: Sometimes it’s easy to forget that even if an attacker can’t steal your key, he may be able to substitute your key for his key. Preventing this form of attack isn’t as easy as it sounds. It requires you to keep a rigorous inventory of all keys and to audit their use, which can be very difficult indeed in a large organization.

Key management is as much about process as it is about technology, which is perhaps why it’s notoriously tricky. In the context of PCI DSS compliance, plenty of scope for mis-interpretation exists. The Standard refers to national bodies, such as the National Institute of Standards and Technology (NIST) in the United States, which defines some best practices


Data Protection and PCI Compliance For Dummies 24in the area. Otherwise, the Standard is fairly vague about what constitutes sufficient protection of keys and key management processes.

From a pure security perspective, your implementation deci-sions should be driven by a realistic assessment of the risks and potential effects of a data breach, but identification of the appropriate actions to achieve PCI DSS compliance requires a conversation between you and your QSA or internal assessor.

Key controlAs you dig into the various deployment options for encryption and key management, the most important issue to address is whether you’re in control of your keys. Many situations can undermine your level of control. Here are a few of the most important questions that you need to answer:

✓ How well do you understand your applications? If you wrote your own business applications, there’s a good chance that you know how the application uses keys. If you’re deploying commercial software, however, you may not even know what keys exist within those systems, let alone how well they’re being protected (and there’s little chance that the vendor in question will tell you!).

Check whether the software is certified compliant with PA-DSS (Payment Application Data Security Standard; check it out at www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php). If it is, you’re in a much better position.

(By the way, the issue of your level of understand-ing of your applications also crops up as you address Requirements 6 and 10.)

✓ What logical access controls exist? Even if you’re com-fortable that your application protects keys appropri-ately, the risk still exists that the application itself can be misused. Unauthorized users, or legitimate users with excessive privileges, can make even highly secure applications do bad things, so you should have logical controls in place to reduce this risk. These controls may include multifactor authentication, multiparty authori-zation, and secure logging — topics that also apply to Requirements 7 and 8.


Chapter 2: Examining Data Protection Requirements 25 ✓ Are physical controls necessary? Virtually all software-

based systems are susceptible to potential physical tampering or theft. Requirement 9 forces you to consider the physical environment of your systems, including those that contain keys. In some cases, locks on doors and security cameras are sufficient. Sometimes, however, physical isolation, safes, and hardened security appli-ances and modules are unavoidable.

For well over a decade, even before PCI DSS, organizations have used specialist encryption and key management devices called hardware security modules (HSM) to address these issues. The argument is that if you can’t make the applica-tion or its host computer secure, simply offload the encryp-tion and key management processes to a separate dedicated environment that can be independently certified as being adequately secure and trustworthy.

More key management resourcesTo find out more about the thorny topic of key management, we sug-gest that you add the following resources to your reading list:

✓ Key Management For Dummies, by Richard Moulds (Wiley): This 2011 book provides a concise discussion of the primary chal-lenges, the key management life cycle, and implementation scenarios. Download a copy at www.thales-esecurity.com.

✓ The Thales Key Management Digital Media Center (www.key managementinsights.com): This site draws together news items and commentary about current topics in the area of key management.

✓ National Institute of Standards and Technology (NIST) Computer Security Division, Computer Security Resource Center (http://csrc.nist.gov): NIST is a U.S. government agency that provides guidelines and tech-nology best practices; it’s spe-cifically referenced in PCI DSS. (Other regional guidelines are published by other governments and industry bodies.) SP 800-57, Parts 1, 2, and 3, specifically focus on key management best prac-tices. You can download these publications at http://csrc. nist.gov/publications/PubsSPs.html.



Locking down your keys in an HSM makes it considerably easier to demonstrate that you’re in control, which is just what your assessor wants to hear. In fact, according to the Ponemon Institute, 81 percent of QSAs recommend the use of HSMs to manage encryption keys, and 63 percent agree that using an HSM reduces the time spent on demonstrating PCI DSS compliance.


Chapter 3

Choosing a Data Protection Strategy

In This Chapter▶ Protecting network traffic▶ Securing stored data▶ Reducing scope with point-to-point encryption▶ Defining data protection priorities

I n Chapter 2, we summarize the formal Requirements of PCI DSS that focus explicitly on data protection, and explain

the primary related technologies. In this chapter, we shift our perspective to implementation choices.

There’s no one-size-fits-all solution for protecting account data; every organization is different, faces different threats, and has different security objectives that (ideally) go beyond simple PCI DSS compliance. This chapter presents a general framework that you can apply to your own organization.

It’s worth reiterating that any part of your organization that comes into contact with account data must be assessed against the full set of PCI DSS Requirements — but only func-tions that store that data or transmit it over open networks are subject to Requirements 3 and 4, which are the focal points of this book.



Encrypting Network TrafficAs you think about the various types of networks that orga-nizations employ to get data to the right place, three general categories emerge:

✓ The Internet: You use the Internet to connect with con-sumers, external business partners, and remote workers.

✓ Wide area network (WAN): A WAN serves as a backbone that interconnects regional data centers.

✓ Local area network (LAN): You use a LAN to connect devices and systems in a given location (such as a retail store or single data center).

To encrypt traffic over any of these types of networks, you can encrypt the network itself, so that everything that flows over it is protected, or you can encrypt just those data objects that are deemed to be sensitive.

As an analogy, think about protecting documents that people send and receive via the postal system — what we today call snail mail. It’s appealing to try to make the whole postal system secure — probably an impossible task, but if it could be pulled off, people could quite safely send even the most sensitive documents on postcards! In the absence of such confidence, the system relies on each sender to make security decisions — such as whether to use an envelope to protect confidentiality. Think of this selective approach to protection as being data-centric.

For the purposes of this book, this type of data-centric protec-tion occurs when an application encrypts only specific classes or types of data — such as PAN data — before it’s sent over a network. This strategy sounds ideal, but such a selective approach to protection can come at a cost, as we discuss later in this chapter.

Here, we focus on network-level encryption. The bulk protec-tion of data flowing over a network is a blunt but effective security instrument.


Chapter 3: Choosing a Data Protection Strategy 29

Encrypting Internet trafficSecure Sockets Layer (SSL), more properly called Transport Layer Security (TLS), has become the default approach for protecting sensitive data flowing over the Internet. It uses encryption to provide confidentiality for connections between users and websites and the web-based services that they provide. Overall security is provided by master keys and asso-ciated SSL certificates that can identify the parties involved in the connection and enable unique encryption keys to be derived for each individual session. As such, these keys pro-tect all traffic to and from a website and if they’re exposed, you sacrifice confidentiality, once again highlighting that keys and certificates need special attention and protection.

You may be tempted to think that SSL protects traffic all the way from a consumer’s browser right through to the business systems of the organization that she is interacting with — genuine, end-to-end security. But quite often that would be mistake. In reality, SSL protection may be removed and reap-plied multiple times as data traverses the network, potentially exposing air-gaps where data can be exposed. There are some good reasons for this. Think of SSL encryption as a type of “invisibility cloak” for network data: It’s very effective at hiding sensitive data but it also hides information that has legitimate uses within the network as well as potentially malicious data that’s staging an attack.

For example, networking equipment often needs to peel away SSL protection so that it can do its job. Load balanc-ers, for example, can optimize traffic flows if they can see cookies — legitimate data objects that are hidden by SSL encryption. When it comes to spotting malicious data, secu-rity systems such as web application firewalls, data loss prevention, and other deep-packet inspection technologies can be blindsided by viruses and other malicious attacks hidden under the cover of SSL encryption. They have no choice but to penetrate that protection to see what’s really happening on the network. This might make busi-ness or security sense, but whenever protective measures are lifted, even temporarily, it exposes vulnerabilities that might be invisible to users and application owners, but serious nonetheless.



Don’t assume that your data is protected just because you turned on SSL, and don’t forget that any devices that termi-nate SSL connections are in scope with respect to PCI DSS.

Encrypting local area networksGenerally, local networks are under your direct control; they’re not considered to be open or public and therefore need not be encrypted under the Requirements of PCI DSS. The obvious exceptions are wireless networks, including those located in retail stores and on corporate premises.

It’s best not to use wireless networks at all for account data, and indeed the Standard explicitly warns against it. Such net-works are capable of “bleeding” through physical boundaries (for example beyond the walls of a retail store) which means there’s no defence in depth if someone accidentally miscon-figures your wireless access point. If you must go wireless, make sure that you implement at least Wi-Fi Protected Access (WPA) encryption — not Wired Equivalent Privacy (WEP), which PCI DSS outlawed several years ago. Also ensure that these wireless networks are segmented from any wired net-works.

If you’re using private radio or microwave links, then WAN encryption technologies are more applicable (see the next section).

Encrypting wide area networksFew organizations own their own wide area private networks. Most use virtual private networks (VPNs), which are owned and managed by service providers and used by multiple cus-tomers. It can be a matter of opinion whether any particular vir-tual network is vulnerable and therefore requires encryption.

As a general rule, if you can’t demonstrate that a service pro-vider, or another one of its customers, is capable of accessing your data, you need to encrypt that data.


Chapter 3: Choosing a Data Protection Strategy 31When it comes to choosing how to encrypt, you have two pri-mary decisions to make, each with its own pros and cons:

✓ Layer 2 versus Layer 3 encryption: The first choice you need to make is whether the data is to be encrypted at Layer 2 or Layer 3 in the OSI Model. The primary issues here are network overhead and potential waste of band-width. If you don’t care about those things, jump to the next item.

With reference to the OSI Model, your routers run at Layer 3, and your network switches usually run at Layer 2. Applying encryption at Layer 3 preserves access to routing information used by equipment along the chain, but also creates overhead, ultimately affecting capacity and latency. Layer 2 encryption operates at a lower layer and is independent of the routing information and flow-management techniques that exist at Layer 3. In most cases, this means it’s more efficient. Nevertheless, IPsec, which is a Layer 3 technology, remains the most common form of network encryption for all but high-speed data center–to–data center connections.

✓ Embedded versus best-of-breed encryption: The second choice for WAN encryption is more security oriented. Network-level encryption is a relatively mature technol-ogy, commonly available as an embedded or native fea-ture of routing or switching equipment.

The alternative to using embedded encryption is using stand-alone encryption devices. Typically, these exter-nal appliances offer a higher level of assurance and are independently certified against security benchmarks such as FIPS 140 and Common Criteria. Additionally, they offer tamper resistance and feature strong access con-trols for administrators (such as multifactor rather than password-based authentication). External devices intrin-sically establish a strong separation of duties between security officers, who are responsible for encryption, and network managers, who are responsible for the perfor-mance of the network.



Protecting Data in Storage Systems

Data can have an almost viral ability to spread across an orga-nization, piling up in data repositories and archives, and spill-ing over into test locations, audit logs, and forensic reports. Recognizing this, the first step should always be to minimize the amount of stored account data well before you try to figure out how to protect it. Simply limiting the spread of account data is the easiest way to reduce PCI DSS scope.

In this section, we provide an overview of various technologies you can use to protect your stored data. Although protecting data on end-user devices such as mobile devices, laptops, and flash drives is important, in this section we focus entirely on business applications and enterprise infrastructure.

Self-encrypting storageAs we discuss in Chapter 2, PCI DSS makes it very clear that only cardholder data — and not other types of account data — can be stored, and that PAN data in particular must be made unreadable whenever it’s stored. The good news is that in response to general market demand, low-cost stor-age encryption has become widely available. Today, it’s commonplace to find self-encrypting disk and tape drives, storage network switches, host bus adapters, and even con-sumer thumb drives with native encryption capabilities.

These products are relatively simple to deploy, and in most cases, have a minimal effect on performance; you simply choose whether to encrypt either all the data or none of the data being stored. This use of encryption can be made trans-parent to the rest of your environment. Data is encrypted as it’s stored, and when that data is retrieved, it’s decrypted on the fly — often requiring no changes to legacy systems and business applications.

Storage-level encryption ensures that if storage media is lost or stolen — as it frequently is — the data it contains is worthless. This has a clear benefit even beyond the


Chapter 3: Choosing a Data Protection Strategy 33Requirements of PCI DSS. And because it is relatively undis-ruptive, some argue that all storage systems should be encrypted by default, just in case they end up containing regulated or otherwise sensitive data. Some off-site archival firms and couriers are starting to turn away unencrypted tapes or charge a premium to cover their increased risk.

File-system and database encryptionEncryption at the disk or tape level guards against the loss of physical storage media but does little to protect against mali-cious insiders or systems infected by malware.

Just because PCI DSS requires that stored PAN data should be unreadable doesn’t mean that it has to be made unreadable by the storage system itself. If the data on storage media ends up being unreadable, the actual protection process could be performed before the data is stored. Applying encryption within file systems or within databases is a good example of how you can satisfy PCI DSS, simplify compliance, and serve broader security goals all at the same time.

By applying protection within the file system or database, it is possible to be more selective and to tie that protection into a framework of access controls, activity monitoring capabilities, and auditing tools. Encryption at the level of storage media tends to be an all-or-nothing experience. But encryption within the file system and particularly within databases can target individual tables, columns even cells.

Although this kind of specific encryption sounds more com-plex than low-level encryption of storage media, it may still be possible to deploy database and file encryption in a way that is transparent to your business applications. In the past, adding encryption to commercial file systems, and par-ticularly to databases, often triggered changes to application software and database schemas and negatively impacted performance-sensitive tasks such as searching and indexing. But, today, many commercial databases and file systems support native encryption capabilities that can simply be turned on.



Application-level encryptionApplication-level encryption — or, equally, tokenization — applies data protection at an even higher level than the data-base or file system. Logically, the application is the ideal entity to protect account data because it’s the only thing that actually knows what account data is and how it is allowed to be used. You can protect individual PAN records selec-tively by making them unreadable on a record-by-record and user-by-user basis.

If you apply protection at the application level, downstream systems — databases, file systems, and storage environments — are exposed only to encrypted or tokenized PANs. If those downstream systems have no means of converting the PAN data back to a readable format and are segmented from those systems which can perform this conversion, they can be taken out of scope completely from a PCI DSS perspective.

This sort of high-level, targeted approach sounds great — very neat and tidy. Don’t forget, however, that it almost always involves changing application software, which incurs a cost and can raise some tricky issues. Here are some to consider:

Don’t lose your keys!All forms of storage encryption must involve some element of key management, which (as we explain in Chapter 2) can be a thorny topic. Key management isn’t just about protecting access to keys to meet compliance obligations; it’s also a business-continuity issue. Protecting stored data with persistent encryp-tion gives rise to the need to manage keys over the long term: Lose the keys, and you lose the data.

The good news is that in most cases, systems can be easily configured to

support hardware security modules (HSMs). These devices can enforce key management policies, provide physical protection against tamper-ing, and establish a clear separation of duties between security officers and storage administrators.

Provided that the issue of key man-agement is taken seriously, storage encryption is a win for security pro-fessionals. It not only addresses com-pliance requirements, it also improves your overall security posture.


Chapter 3: Choosing a Data Protection Strategy 35 ✓ Closed commercial applications and cloud services: If

you’re using off-the-shelf software or even SaaS cloud ser-vices, you almost certainly don’t have the ability to make changes. Application-level encryption in these cases may not be feasible, unless it is offered by the software or ser-vice vendor.

✓ Diverse business applications: Account data is likely to be handled by a variety of different business applications within your organization. Their handling of sensitive data and the security controls they have in place could vary widely. Applying application-level encryption in a uni-form way across such diverse systems could be a greater challenge than you expect.

✓ Performance hits: Applications are often precisely tuned to maximize performance, and encryption can be a per-formance drain, so building encryption into the applica-tion layer may not be optimum unless you can employ cryptographic acceleration or offloading.

✓ Effects on other systems: If data is protected in one application and subsequently sent to databases or other applications, those systems may be adversely affected. If the systems expect to receive PAN data but instead are provided data in a completely different format, they’re unlikely to be happy. Fortunately, tokenization provides the possibility of format preservation, as mentioned in Chapter 2, and various format-preserving encryption options also exist.

Because new applications are frequently deployed and exist-ing ones modified in order to satisfy shifting business require-ments, it’s hard to know for sure which applications are exposed to account data (which is what makes a QSA’s job so interesting). Given this fact, it’s important not to jump into a project to deploy application-level protection until you’ve done your homework.

Sharing encrypted data between applications means sharing keys, which relies on shared trust and, potentially, shared security management systems, all of which need to comply with PCI DSS. The same is true of tokenization. Once again, you can use HSMs to provide consistency and interoperability.



Protecting Data at the Point of Capture

Account data doesn’t materialize from thin air. You capture the information from consumers or allow it to enter your organization by some means or another. Protecting data at the point of capture — literally the first opportunity you have to protect it — can have the greatest effect in terms of scope reduction.

Some methods by which you capture or are exposed to account data are obvious and entirely intentional; others are not. The areas where you unintentionally receive and/or store account data, even temporarily, are the ones that might trip you up.

It’s impossible to provide an exhaustive list because all busi-nesses are different, but the following sections list some places where account data may enter your organization — and, there-fore, where you could render that data unreadable and poten-tially reduce scope.

Retail storesRetail stores are obvious locations where account data is captured; therefore, they’re obvious sources of risk. Encrypting authentication information, such as PINs, has been mandated for years; point-of-sale (POS) devices and ATMs go through rigorous certification programs to validate their security properties, including physical hardening and key management practices.

With the arrival of PCI DSS, some POS vendors have extended POS functionality to encrypt account data as well as PINs, which makes it much easier to protect data at this particular point of capture. However, the same isn’t true for the huge assortment of basic card readers (including cash registers, vending machines, and even airport check-in desks) that lack any real security capabilities and are unlikely to support encryption capabilities anytime soon.


Chapter 3: Choosing a Data Protection Strategy 37The same is true of a range of next-generation payment ter-minals, including contactless readers, optical scanners, and smartphone accessories.

If it proves to be impractical to protect data as soon as it is captured, the next-best thing would be to consider the next step in the chain that data passes through — typically an in-store application, sometimes called the store controller. These localized systems consolidate transaction data, poten-tially act as local caches, and communicate with the central processing center. Adding protection to store-based data processing systems is another example of application-level protection (see “Application-level encryption,” earlier in this chapter).

Faced with turning away business, virtually all retailers will fall back on paper signatures and card imprints. Processes for scanning these elements or otherwise getting them into the payment system may be manual, falling outside the scope of automated encryption mechanisms. Don’t overlook them.

Web infrastructureThere can be a fine line between an organization’s web infra-structure and its business applications. Here, we focus on the front line: the systems that are exposed to clear-text account data coming in from the web. This area is critical because it’s subject to all the attacks the Internet can throw at it — some aimed at service disruption and others aimed at data theft.

The Requirements for protecting data as it passes over the web are clear, and in virtually all cases, that connection is protected by the use of SSL (refer to “Encrypting Internet traffic,” earlier in this chapter). But SSL protection isn’t selec-tive or persistent. SSL protects the Internet connection and everything that passes over it, but when the data is received, it’s immediately decrypted. If your goal is to reduce scope, it will be necessary to apply record-level protection, such as encryption or tokenization. This protection will be persistent and can protect data from that point onward, even when it’s stored.



Consumer devicesLooking to the future, it would be ideal if account data (and many other things) could receive persistent protection at the hands of the consumer even before it crosses the Internet. The concept of an entirely trusted computer has been a pipe dream for years and may never arrive. There are, however, industry initiatives to provide trusted card readers and browser-level encryption — which would certainly reduce the risk of online and card-not-present transactions.

There is also industry excitement about smartphones and their potential to become trusted payment devices that pro-tect data literally at the user’s fingertips. Various standards activities are under way to define trusted encryption capabili-ties for smartphones, effectively giving them the ability to protect data just as an ATM pin pad or POS terminal protects PINs today.

Employing Point-to-Point EncryptionThe concept of reducing scope by encrypting account data at the point of capture has triggered such inter-est that the PCI Security Standards Council gave it a name: Point-to-Point Encryption (P2PE) and issued specific guidance in late 2011 to define its use. Find out more at www.pcisecuritystandards.org/security_standards/ documents.php . If the pro-cess is implemented correctly, with account data being encrypted within an approved secure cryptographic device (SCD), such as a POS terminal and not decrypted within the merchant environment there is the potential for

that merchant to be taken almost com-pletely out of scope. Strict controls for protection of and access to decryp-tion keys need to be in place; in fact, the current guidance requires the use of HSMs with an appropriate security rating to qualify. Any system that has the capability to decrypt account data immediately comes into scope from a PCI DSS perspective.

Acquirers and other players in the payments chain have already begun to market value-added services that exploit P2PE to reduce compliance costs for their merchants.


Chapter 3: Choosing a Data Protection Strategy 39

Other channelsSo far, we’ve talked about some of the ways that organizations intentionally collect account data. However, there are plenty of examples of organizations inadvertently becoming exposed to account data through call centers, e-mail systems, and even fax machines. Very often, customer exchanges conducted through these channels are recorded and stored for future ref-erence; therefore, if they contain account data, they need to be rendered unreadable.

Choosing a Data Protection Solution

No single technology or point of deployment will ever repre-sent a silver bullet for account data protection. PCI DSS man-dates a multilayered approach. Even if you employ encryption or tokenization within applications or databases, and your data therefore spends its life protected, you should still use encryption for network traffic and even consider it for bulk storage media. This is partly because protection at these lower layers is relatively easy to deploy, but mostly because it provides protection if unprotected account data falls through the cracks of your application or database infrastructure.

The actual data protection technologies that you adopt, and the locations where you choose to deploy them, depend on many factors. We don’t have the space to go into detail, but just to whet your appetite, Figure 3-1 shows the result of a survey that asked auditors which of the four technologies sug-gested for rendering data unreadable they would recommend in each of the locations that we cover in this section.

Very few, if any, of the Requirements of PCI DSS are unique to it, or even to account data and payment environments in gen-eral. You will be able to employ the data protection technolo-gies that you put in place for PCI DSS to improve your security posture with regard to other sensitive data.



0%

10%

20%

30%

40%

50%

60%

Data in a database Data in applications Data in storage Data at pointof capture

Encryption Tokenization Truncation

Figure 3-1: Recommendations from auditors on technology choices at the four primary points of protection.

Approach data protection as a strategic investment, rather than a purely compliance-driven obligation. Be creative, and work with your assessor. If you do, you should not only sat-isfy the assessor’s expectations but also reduce your PCI DSS compliance burden.


Chapter 4

Ten Keys to PCI DSS Success

In This Chapter▶ Deciding what needs to be done▶ Adopting the right perspective▶ Planning for the future

T his chapter outlines ten critical steps that can help you with your PCI DSS project and make sure that you get off

to a good start.

Understand the Here and NowIt’s tempting to dive right into a compliance project. You may be under extreme pressure to “just get it done.” Common sense dictates, however, that you know what you’re protect-ing, and where it exists within your organization, before you determine the best protection strategy. Before you spend the big bucks, take the path of discovery.

Understand your data lifecycle, for example. Which of your systems and processes are currently exposed to account data? How does that data come into your possession? What do you do with it, and what happens to it when you don’t need it any-more? The answers to these questions can be very helpful.

Also, in addition to your payment systems, check develop-ment and test activities, log files, and backup and recovery facilities. Finally, list the threats you face and the protection measures you already have in place.



Tailor Your Compliance PlanThere’s no silver bullet for PCI DSS compliance, or even a perfect “compliant environment” that you can duplicate. The PCI SSC recognizes that every situation is different and delib-erately leaves certain topics open to interpretation. QSAs and internal security assessors (ISAs) are therefore expected to apply their own judgment to each situation. Make sure that they understand your business objectives and technical con-straints, so they can give the best advice for your situation.

Limit Your Exposure and ScopeAs you progress from defining what you need to protect to focusing on how you should protect it, continually repeat the maxim “If you don’t need it, don’t have it.” Just because a par-ticular business system touches account data today doesn’t mean that it actually needs to.

You can reduce the scope of your assessment in numer-ous ways. Segmenting networks, rendering data unreadable as soon as you receive it, and disposing of data at the first opportunity are good places to start. Being a data hoarder costs real money and provides more opportunities for attack-ers to ruin your day.

Accept Responsibility in Outsourcing

Whether selling cloud computing, an outsourced application, or a basic hosting service, every service provider says that its infrastructure is secure. It may argue that it’s better able to protect your data than you are, and it may even be right. But remember that accountability for compliance still rests with you; you have no opt-out option.

By using external service providers, you inevitably give up some control and instead place some of your trust in a service-level agreement. It’s vital that all parties in a service relationship are clear about what all the other parties are


Chapter 4: Ten Keys to PCI DSS Success 43doing, what parts of PCI DSS each party is responsible for, and how compliance will be demonstrated to assessors, acquirers, and card brands.

Take a Holistic ApproachThis book focuses on Requirements 3 and 4, but it’s a mistake to consider any Requirement in isolation. PCI DSS is intended to be viewed as a whole. You should also be aware of related PCI Standards, such as the Payment Application Data Security Standard (PA-DSS). It is also worth looking further at proven standards, such as ISO/IEC 27001, that address the bigger security picture and make it easier to stay PCI DSS compliant.

In addition, when addressing information security, always bear in mind your overall regulatory environment, particu-larly with regard to privacy.

Consider the Business ContextAs you define your deployment project, ensure that you remember what your business is trying to achieve. Maybe the goal is minimizing cost, maximizing customer satisfaction, reducing risk, building competitive advantage, or growing the business. Regardless of the goal, don’t lose sight of the big picture. IT departments and business managers make deci-sions more effectively if they understand why you’re asking them to change what they’re doing and what your guiding principles are.

Sharpen Your Key Management Skills

If you accept the need to store cardholder data or transmit account data, you also accept the responsibility to protect that data. In almost all cases, protecting data means using encryp-tion, which in turn means that you have keys to manage. As we mention in Chapter 3, key management isn’t just a compliance issue; it’s also a business-continuity issue. Poor key manage-ment can bring your business to a standstill.



Look after your keys, and they’ll look after you — and make your path to compliance easier.

Take Security to the TopAny project that spans multiple security and IT domains has the potential to disrupt day-to-day operations, so it must be elevated to a strategic level. Fragmenting your PCI DSS compliance project into isolated technology tasks is likely to result in inconsistencies and compliance gaps that delay assessment, drive up costs, and potentially create new secu-rity and operational risks. Make sure that the top level of your organization knows what’s happening and drives your compli-ance program.

Think of Security as a JourneySecurity standards are always subject to change as the threat landscape evolves, and PCI DSS is no different. PCI DSS is a reflection of IT security best practices, not the other way around. The security industry is always coming up with new ways to solve old problems, and the inevitable changes within your business result in a very dynamic situation, whether or not you’ve already achieved compliance.

You’re never going to stop doing compliance. Compliance is a process, not a one-off project.

Keep Your Eyes on the PrizeYou may well find that PCI DSS compliance programs have a relatively high priority when it comes to budgeting. That pri-ority can make you a target for others whose security projects weren’t so lucky. Don’t be surprised by requests like “Just add this item to the PCI to-do list.” Project bloat is one of the most common issues that assessors witness, bringing with it a loss of direction, unnecessary expenditure, and delays. New technology and processes put in place to achieve PCI DSS compliance may well have value outside the realm of account data — but first prove that they’re necessary for PCI DSS.



http://www.thales-esecurity.com/kmdummies

http://www.thales-esecurity.com/kmdummies

http://www.thales-esecurity.com

Documents

These materials are the copyright of John Wiley & Sons ...lt.idg.com.br/thales/pci_compliance_for_dummies.pdf · These materials are the copyright of John Wiley & Sons, Inc. and any