PCI for Dummies

7/28/2019 PCI for Dummies

1/68

Secure and protect

cardholder data

PCICompliance

Complimentsof

QualysLimitedEdition

Sumedh Thakar

Terry Ramos

UpdatedforPCIDSSVersion2.0!


2/68


3/68

PCI ComplianceFORDUMmIES

by Sumedh Thakar andTerry Ramos

A John Wiley and Sons, Ltd, Publication


4/68


5/68

Introduction

Welcome toPCI Compliance For Dummies! Compliancewith the Payment Card Industry (PCI) Data SecurityStandard (DSS) is mandatory if your company stores,processes, or transmits payment cardholder data. This book

is all about understanding PCI and how merchants cancomply with its requirements.

About This BookThis book simply explains the PCI Data Security Standard anddescribes its requirements for compliance. After reading thisbook youll know more about how to comply with the PCIData Security Standard.

Foolish AssumptionsIn writing this book, we assume that you:

Are a merchant and know you have to comply with PCI

but arent sure whats required or what you need to do.Are familiar with information technology and networking.

Want to discover the easiest, most effective and directway to fulfill compliance requirements for PCI.

How to Use This BookThis book is divided into five succinct and easily-digestible parts:

Part I: Merchants: Cardholder Data Thieves Want You!Start here if you need a primer on security risks faced bymerchants who accept payment cards.

Part II: Looking at the Big Picture of PCI Standards.Understand the three PCI standards and how eachapplies to merchants.


6/68

PCI Compliance For Dummies2

Part III: Surveying Requirements of the PCI DataSecurity Standard. An introduction to the six goals and

12 requirements of PCI DSS.

Part IV: Verifying Compliance with PCI. Become familiarwith the tools and reporting requirements for compli-ance, and discover where merchants can go for help.

Part V: Ten Best Practices for PCI Compliance. Followthis short list of steps to ensure compliance with the PCIstandard.

Dip in and out of this book as you wish; go to any part thatinterests you immediately; or read it from cover to cover.

Icons Used in This BookWe highlight crucial text for you with the following icons:

This icon targets hints and shortcuts to help you get the bestfrom PCI scanning solutions.

Memorize these pearls of wisdom and remember how muchbetter it is to read them here than to have your boss give aknow-it-all lecture.

The bomb means whoops. It signals common errors that canhappen. Avoid these at all cost.

Prepare for a little bit of brain-strain when you see this icon.But dont worry you dont have to be a security whiz or hotrod programmer to do vulnerability scans required for PCIcompliance.

Where to Go from HereCheck out the section headings in this book and start readingwherever it makes sense. This book is written with a sequen-tial logic, but if you want to jump to a specific topic you canstart anywhere to extract good stuff. If you want a hands-ondemo or trial version of QualysGuard our featured PCI scan-ning and reporting solution visit www.qualys.com.
http://www.qualys.com/http://www.qualys.com/


7/68

Part I

Merchants: Cardholder

Data Thieves Want You!

In This Part Identifying the vulnerability of merchants to a payment card data

breach

Understanding the risks and consequences of a breach

Reviewing risk points of the payment card transaction processingflow

Using PCI as a way to control risks and protect cardholder data

To some people, the idea of crime against merchants mightbe a gun-toting thug (Empty your cash register NOW!), ashoplifter, or perhaps a wily embezzler. A modern, more lucra-tive, and easier-to-exploit target is sensitive data for paymentcard accounts of a merchants customers. With these data,

criminals can unlock direct access to money and personalidentities. Cyber thieves can easily send these data to distantcohorts for exploitation beyond the practical reach of lawenforcement. Damage can be swift and punish merchants aswell as the customer. Fallout varies, but when customers losetrust, they usually take their business elsewhere.

Fortunately, theres a clear path of action for merchants thatcan help prevent compromise of payment card data. The

Payment Card Industry Data Security Standard is the author-ized program of goals and associated security controls andprocesses that keep payment card data safe from exploitation.The standard is often called by its acronym PCI DSS. Wesimply call it PCI. This book,PCI Compliance For Dummies, canhelp merchants to quickly understand PCI, and how yourorganization can use it as a tool to prevent breaches of card-holder data.


8/68


Compliance with PCI is mandatory for any merchant or otherorganization that accepts payment cards.

Merchants Have What DataThieves Want

Personal consumer information has been under siege foryears. Since January 2005, more than half a billion database

records containing sensitive personal information have beeninvolved in security breaches in the U.S. alone, according toPrivacyRights.org.

The object of desire for data thieves is cardholder data theprimary account number (PAN) and sensitive authenticationdata printed on or stored in a magnetic stripe or chip on thecredit or debit card. Cardholder data is the only informationstanding between thieves and your money. No wonder crimi-

nals seek it with intensity!

New research indicates the most vulnerable sector for databreaches is merchants. Merchants process the bulk of creditand debit cards offered for payment of goods and services.Smaller merchants are the most attractive targets for datathieves because theyre less likely to have locked down pay-ment card data. According to Visa Inc, 96 per cent of success-ful attacks on payment card systems have compromised Level

4 Merchants those who process less than 1 million paymentcard transactions each year.

More than 6 million Level 4 Merchants operate in the U.S.,processing about 32 per cent of all Visa transactions.Merchants who were breached the most included restau-rants, lodging and hotels, clothing retailers, sporting goods,and direct marketing.

The people behind successful attacks are professionalthieves. About 85 per cent of compromised records wereattributed to organized criminal groups, according to investi-gations of data breaches by Verizon Business and the U.S.Secret Service. Their skill and intent demand your utmostvigilance and response!
http://privacyrights.org/http://privacyrights.org/


9/68

Cardholder data is the

main targetThese attacks on small merchants have a concrete objective.More than half of all data breaches investigated by VerizonBusiness and the U.S. Secret Service involved payment carddata. More telling was the fallout, as 83 per cent of stolenrecords was payment card data (see Figure 1-1). This percent-age dwarfs all other breaches, so clearly your cardholder datais the main target for data thieves!

Figure 1-1: Cardholder data is the largest category of stolen information.

(Source: Verizon Business, 2010 Data Breach Investigations Report)

Breaches can hit merchantsof any sizePayment card data theft has hit organizations of all sizes. Thebiggest known breach to date was the theft and sale of morethan 40 million credit and debit card numbers from nine majorU.S. retailers, including TJX Companies Inc., BJs WholesaleClub Inc., OfficeMax Inc., Barnes and Noble Inc., and SportsAuthority. The criminals were an international credit fraudring; prosecutions and convictions are now underway.

Part I: Merchants: Cardholder Data Thieves Want You! 5


10/68

Cardholder data theft can also occur at small, mom and popstores. For example, in spring 2008, the ATM/credit card

reader was switched in a small supermarkets checkout aislein Los Gatos, California. At least 135 people were reported tohave had cardholder data stolen via this rogue device. Thesmall store is in a community in hi-tech Silicon Valley, so somevictims could have included security technology experts! Noone is immune.

Stories like these make consumers especially nervous aboutsharing cardholder data with online stores. For aside from

the huge roster of documented breaches, theres other evi-dence for concern. According to the Verizon study, the major-ity of compromised records occurred in breaches of web sitesecurity. Indeed, 89 per cent of stolen records were hackedwith the SQL Injection vulnerability. Consumers are right towonder about security of their cardholder data!

Understanding the PotentialFallout from a BreachThanks to federal law and standard practice by the financialindustry, the maximum cash exposure of a consumer whosecardholder data is stolen is just $50; the rest of all relatedlosses are paid by the card companies. If the data allows acriminal to access other accounts or steal a consumers iden-

tity, financial fallout could be severe for that individual.Resolving just one incident of a stolen identity may take yearsof effort. Personal fallout would be catastrophic if multiplebreaches at different merchants occurred during a shortperiod of time.

Merchants face their own types of fallout. When a breachoccurs, there are discovery and containment costs for investi-gating the incident, remediation expenses, and attorney and

legal fees. But this is just for starters. Long-term fallout for allmerchants may include:



11/68

Loss of customer confidence.

Lost sales and revenue.

Lower use of online stores due to fear of breaches.

Brand degradation or drop in public stock value.

Employee turnover.

Fines and penalties for non-compliance with PCI and otherregulations.

Higher costs for PCI assessments when merchants with a

breach must subsequently comply with the penalty ofmore stringent requirements.

Termination of the ability to accept payment cards.

Fraud losses.

Cost of reissuing new payment cards.

Dispute resolution costs.

Cost of legal settlements or judgments.

The potential fallout for larger merchants can be huge, but isntinsurmountable if a company is well capitalized. Discount retailerTJX says its spent more than $200 million in expenses related tothe big data heist mentioned in the previous section and itsjust one of the nine large merchants affected by that breach.

Smaller merchants, however, may have significant troubleweathering a cardholder data breach. Think about your com-panys cash flow and whether it could cover potential damagefrom a breach. The risk of going out of business should bemotivation enough to follow PCI and protect the data. Butthats why youre reading this book, right? So lets get to work.

Exposing the Risks in Payment

Card ProcessingWhen a merchant accepts a payment card, a complex systemof devices, software, networks, service providers and the cardacquirer is required to process the payment and get the money.



12/68

Each element of the payment card technology system posesrisks that could be exploited by criminals, so its vital to use

appropriate security controls and business procedures tominimize risk and protect cardholder data.

Obviously, a merchant cant control the entire payment cardsystem. So PCI limits the scope of responsibility to protectingcardholder data with security technologies and processesthat exclusively cover the merchants domain, such as:

Payment card readers used to swipe and collect data.

Point of sale systems (including PCs and handhelddevices).

In-store and inter-store networks and devices (servers,wireless routers, modems, and so on.).

Payment card data storage and transmission over theInternet to a merchants distributed systems or serviceprovider.

Ensuring that third-party service providers, their applica-tions and systems are compliant with PCI requirements.

Access control to the card processing system.

Network monitoring, scanning and vulnerabilitymanagement.

Company security policy.

Figure 1-2 illustrates domains under the merchants responsi-bility in this case, the POS and Merchant sections of the dia-gram and related network links.

PCI requirements can help your merchant organization imple-ment the right controls and processes to avoid compromisingcardholder data. The good news is that PCI doesnt requestanything different from what youd normally do security-wiseto protect cardholder data. Part II introduces how PCI stan-dards apply to merchants.



13/68

Figure 1-2: PCI requires merchants to protect systems under their control.

POS

Merchant

Service Provider Acquirer

Network

Network

Network



14/68


Risky businessPCI provides the guidelines to helpmerchants protect cardholder data.Unfortunately, merchants are a primetarget for data thieves because theyengage in activities that place card-holder data at risk. According to theNational Federation of Independent

Business (NFIB) Guide to DataSecurity:

37 per cent of card-acceptingbusinesses knowingly store cus-tomer card numbers.

24 per cent store customerSocial Security numbers.

28 per cent store customer bankaccount numbers or copies oftheir checks.

52 per cent of all small busi-nesses keep at least one of thesesensitive pieces of information.

57 per cent dont see securingcustomer data as something thatrequires formal planning.

61 per cent have never soughtout information about how toproperly handle and store cus-tomer information.


15/68

Part II

Looking at the Big Pictureof PCI Standards

In This Part Understanding PCI and how its standards fit together

Meeting PCIs manager, the PCI Security Standards Council

Summarizing the PCI Security Standards

In this part we explore the three PCI standards. One is tai-lored for merchants and other organizations that acceptpayment cards; one for manufacturers of card devices used atthe point of sale; and one for software developers of paymentcard applications. Each of these standards share the same pri-mary goal:protecting cardholder data. Some cardholder dataare printed on a card; others reside in digital format on a mag-netic stripe or computer chip. Figure 2-1 shows the types of

sensitive data and where they reside on a payment card.

Figure 2-1: Types and locations of cardholder data on a payment card.(Source: PCI SSC)

CIS(American Express)

CAV2/CID/CVC2/CVV2(all other payment brands)

PAN ExpirationDate

Magnetic stripe(data on tracks 1 and 2)


16/68


Piecing the Puzzle: How PCIStandards Fit Together

PCI standards present technical and operational requirementsfor protecting cardholder data. The standards apply to anyorganization that stores, processes or transmits cardholderdata. The PCI standards are tailored for three communities:merchants and processors, software developers, and manu-facturers. They address the ecosystem of retail payment

devices, applications, card processing infrastructure, and theorganizations that execute related operations.

Heres how the PCI standards relate to each other (seeFigure 2-2):

PCI Data Security Standard (PCI DSS) is the core stan-dard, which is primarily for merchants and processors. Itaddresses security technology controls and processes

for protecting cardholder data. This book is about PCIDSS, which we more simply call PCI.

Payment Application Data Security Standard (PA-DSS) isfor software developers who sell commercial applica-tions for accepting and processing payment cards. Mostcard brands require merchants and processors to useonly approved payment applications.

Personal Identification Number (PIN) Transaction

Security Requirements (also called PTS) are for manu-facturers of payment card devices used at the point ofsale. In addition to other PCI DSS requirements, softwaredevelopers, merchants and processors must use onlyapproved devices compliant with PTS.

Figure 2-2: PCI is about protecting cardholder data.(Source: PCI SSC)


17/68

The Standards Manager: PCISecurity Standards Council

Every standard has its manager, and PCI is no different. Anopen global forum called the Payment Card Industry SecurityStandards Council (PCI SSC) develops, manages, educates,and raises awareness of the three PCI standards. The Councilalso provides documents to help merchants implement PCI(check out Getting Help: Council Resources for Merchants at

the end of this chapter).

The Council was founded in 2006 by the major card brands:American Express, Discover Financial Services, JCBInternational, MasterCard Worldwide, and Visa Inc. Eachbrand recognized the importance of securing cardholder data,so they all agreed to incorporate the PCI Data SecurityStandard within their own compliance programs. Thefounders also recognize Qualified Security Assessors and

Approved Scanning Vendors who are certified by the Councilas resources for PCI compliance.

The five card brands share equal responsibility in Councilgovernance, are equal contributors to the Council, and shareresponsibility for executing its work. The Council organizationconsists of an executive committee, a management commit-tee, a general manager, marketing working group, legal, andtechnical working groups.

Other industry stakeholders participate in the PCI standardsprocess. These include merchants, payment card issuing banks,processors, hardware and software developers, and other ven-dors. These stakeholders may review proposed changes to stan-dards and vote on their official adoption by the Council.

The PCI Data Security StandardThe PCI Data Security Standard is the key standard for helpingmerchants to protect cardholder data. If your organizationaccepts just one card for payment, you must comply with PCIDSS. This standard describes the technical and operationalsystem components that are part of or connected to card-holder data. PCI DSS is structured by six goals, that include 12

Part II: Looking at the Big Picture of PCI Standards 13


18/68

related requirements which we lay out in Table 2-1. The tableis a handy overview we go into the detail in Part III, and you

can read about how to comply with PCI in Part IV.

Table 2-1 PCI Data Security Standard

Goals PCI DSS Requirements

Build and maintain a 1. Install and maintain a firewallsecure network configuration to protect cardholder

data.

2. Do not use vendor-supplieddefaults for system passwordsand other security parameters.

Protect cardholder data 3. Protect stored cardholder data.

4. Encrypt transmission ofcardholder data across open,public networks.

Maintain a vulnerability 5. Use and regularly update anti-virusmanagement program software or programs.

6. Develop and maintain securesystems and applications.

Implement strong access 7. Restrict access to cardholder datacontrol measures by business need to know.

8. Assign a unique ID to each

person with computer access.

9. Restrict physical access tocardholder data.

Regularly monitor and 10. Track and monitor all access totest networks network resources and cardholder data.

11. Regularly test security systems andprocesses.

Maintain an information 12. Maintain a policy that addressessecurity policy information security for all personnel.

Source: PCI DSS



19/68

The three important tools that play crucial roles withcompliance are:

Card Brand Compliance Programs. The major cardbrands have incorporated the PCI DSS into technicalrequirements for compliance. But each brand has varia-tions in the process of verifying compliance so merchantsneed to check with their acquiring financial institution forspecific requirements (see the nearby sidebar).

Qualified Assessors. The PCI Security Standards Councilqualifies two kinds of assessors to help merchantscomply with PCI. The Qualified Security Assessor (QSA)is a consultant who assesses your organizations compli-ance with the standard. The Approved Scanning Vendor(ASV) validates compliance with the standards externalnetwork scanning requirements. Some ASVs provide soft-ware or a web service to perform scans. Others will scanfor you. See Part IV for details.

Self-Assessment Questionnaire. Based on card brand

requirements, some merchants are able to self-validatefor compliance by completing a Self-AssessmentQuestionnaire (SAQ). Different kinds of SAQs suit differ-ent merchant operations. Part IV describes these andhow to use the questionnaire, which is used primarily byLevels 2 to 4 merchants.


Delving deeper into cardbrand compliance programs

Want more information about cardbrand compliance programs? Checkout:

American Express:www.americanexpress.com/

datasecurity

Discover Financial Services:www.discovernetwork.

com/fraudsecurity/

disc.html

JCB International:www.jcb-global.com/english/

pci/index.html

MasterCard Worldwide:www.mastercard.com/sdp

Visa Inc.: www.visa.com/cisp
http://www.americanexpres.com/datasecurityhttp://www.americanexpres.com/datasecurityhttp://www.americanexpres.com/datasecurityhttp://www.americanexpres.com/datasecurityhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.mastercard.com/sdphttp://www.mastercard.com/sdphttp://www.mastercard.com/sdphttp://www.visa.com/cisphttp://www.visa.com/cisphttp://www.visa.com/cisphttp://www.visa.com/cisphttp://www.mastercard.com/sdphttp://www.jcb-global.com/english/pci/index.htmlhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.americanexpres.com/datasecurity


20/68

Revealing the PIN TransactionSecurity (PTS) Requirements

Cardholder data theft can easily start with insecure point-of-saledevices that accept personal identification number (PIN) entryfor transactions. The PIN Transaction Security Requirements(referred to as PTS) were created to improve the security char-acteristics and management of these PIN entry devices.

PTS requirements apply to manufacturers of these point ofsale devices. Manufacturers must provide a finished productfor which physical and logical security is never compromised,either during the process of manufacturing or distribution tothe merchant buyer.

Merchants are required to use only PIN entry devices that areapproved by the PCI Security Standards Council. Before you pur-chase any PIN entry devices, check the list of approved devices

on the PCI Security Standards Council website. Merchant com-pliance with this point is checked every year. Heres a summaryof the PTS security requirements (source: PCI SSC):

Evaluation Module

Core Requirements

POS Terminal Integration

Open Protocols

Secure Reading and Exchange of Data

Core Requirements

Device Management (manufacturing and initial keyloading)

Requirements Set

Physical and logical security

POS terminal integration

Open protocols

Requirements in support of cardholder accountdata encryption



21/68

Payment Application (PA)Data Security Standard

Another place where thieves can attack is through paymentapplications used to store, process or transmit cardholderdata during authorization or settlement. The PaymentApplication Data Security Standard (PA-DSS) applies to cre-ators of commercial off-the-shelf payment applications andtheir integrators and service providers. If you use a custom

payment application, PA-DSS doesnt apply. Instead, you areresponsible for making the application meet PCI DSS require-ments.

The focus of PA-DSS is preventing the compromise of fullmagnetic stripe data digitally stored on the back of a pay-ment card. It also aims to protect cardholder data stored onthe computer chip embedded on the front of some paymentcards.

Most card brands encourage merchants to use payment appli-cations that comply with PA-DSS and are approved by the PCISecurity Standards Council. Before you purchase a paymentapplication, check the list of approved payment applicationsatwww.pcisecuritystandards.org. Heres a summary ofthe Payment Application Data Security Standard requirements(source: PCI SSC):

Do not retain full magnetic stripe, card validation code orvalue (CAV2, CID, CIV2, CW2) or PIN block data.

Provide secure password features.

Protect stored cardholder data.

Log application activity.

Develop secure applications.

Protect wireless transmissions.

Test applications to address vulnerabilities.

Facilitate secure network implementation.

Do not store cardholder data on a server connected tothe Internet.

http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/


22/68

Facilitate secure remote software updates.

Facilitate secure remote access to application.

Encrypt sensitive traffic over public networks.

Encrypt all non-console administrative access.

Maintain instructional documentation and training pro-grams for customers, resellers and integrators.


Is PCI the Law?Is there a law that compels you tocomply with PCI? There is, but onlyin the states of Minnesota, Nevada,and Washington.

In 2007, Minnesota passed the nat-tily named Minn. Stat. 365E.64, which

prohibits storing data from the mag-netic stripes on payment cards, plusrelated security codes and PINs formore than 48 hours after approval ofa card transaction. This law is asubset of PCI, specifically relatedonly to PCI DSS Requirement 3(Protect stored data). Minnesotalaw also allows financial institutions

to recover reasonable costs from amerchant related to the theft of card-holder data.

Legislators in at least 10 otherstates thought Minnesotas law wasa good idea. Bills were introducedin Alabama, California, Illinois,Indiana, Iowa, Michigan, New

Jersey, Texas, Washington, andWisconsin. But none were passed.

As of 2010, Nevada requires compli-ance with PCI DSS for all businessesaccepting payment cards. In effect,so does Washington, which now

allows financial institutions to sueentities accepting or processingpayment card transactions whocause a breach due to their own fail-ure to protect cardholder data.Codification of PCI DSS will continue

in other states.During the past few years, propos-als have also made rounds in the USCongress but none were passed.

When Governor Arnold Schwarz-enegger vetoed Californias bill, hesaid the payment card industry wasin a better position to maintain the

standard, and anything passed intolaw would end up conflicting withPCI DSS as the standard wasrevised.

Other critics say that turning PCIinto law would make the PCISecurity Standards Council (andeffectively, the card brands) aquasi-legislative, quasi-judicial

body with the power to set regula-tions and punishments yet beaccountable to no one.

Transforming PCI into law faces thesame kind of challenges any goodtechnology legislation would face.


23/68


For example, after Californiapassed a data breach notificationlaw in 2002 (SB 1386), at least 45other states passed similar bills.Yet despite nearly universalrequirements to disclosebreaches to consumers, only fourof the nine large retailers whorecently suffered a breach of 40million records clearly alertedtheir customers to the incident.Statutory enforcement of PCIrequirements would be muchmore difficult.

For now, know that the full PCIData Security Standard is not alaw in any country. Instead, PCI isenforceable under private con-tractual conditions stipulated byeach of the card brands. When amerchant accepts one card pay-ment, it must abide by PCI and anyside provisions decreed by thatcards brand.

For more information about howto comply with PCI, head to PartIV of this book.

Getting Help: Council Resourcesfor MerchantsThe PCI Security Standards Council provides a variety of toolsto help merchants understand the requirements of PCI DSSand the steps to verify compliance. You can find links to thefollowing documents on the Councils website at www.pcisecuritystandards.org.

Frequently Asked Questions (FAQ)

Membership

Webinars

Training (for assessors)

PCI SSC Approved PIN Entry Devices

PCI SSC Approved Payment Applications

The PCI Data Security Standard(PCI DSS)

Navigating the PCI DSS

Security audit procedures

Glossary
http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/


24/68

PCI SSC Approved Qualified Security Assessors

PCI SSC Approved Scanning Vendors

Now that you have the big picture of PCI, turn to Part III anddiscover how to protect sensitive cardholder data with thedetailed requirements for the PCI Data Security Standard.



25/68

Part III

Surveying Requirementsof the PCI Data Security

StandardIn This Part Gauging the effort for meeting PCI requirements

Understanding where merchants should focus on security

Comparing the two kinds of PCI requirements: technology andprocess

Surveying the goals and requirements of the PCI Data SecurityStandard

Reviewing the role of compensating controls for PCI requirements

As you go through this book, you may wonder how muchof the information really applies to your business. The

answer depends on the nature of your business operations,the volume of payment card transactions, and the complexityof IT resources that underpin your card processing infrastruc-ture. If your business is a regional or national chain of stores,fulfilling PCI requirements will require more effort thansmaller stores who dont have as much hardware and soft-ware to protect and whose business processes are usually

simple. A single small mom-and-pop store will require theleast effort to comply with PCI.

The great thing about PCI requirements is that they providean excellent checklist for protecting cardholder data. The PCIData Security Standard requirements are the same pointsyoud normally use for overall information and network secu-rity. By implementing security for PCI, youll effectively use


26/68


the industrys best practices for security. And PCI not onlywill help you secure cardholder data it also may fulfill secu-

rity requirements for other laws and business regulationsaffecting your company. PCI is good for cardholder data secu-rity and good for your business.

Focusing on Security in thePayment Card Process

The payment card process is a system whose various compo-nents are each exposed to security risks. As shown in Figure3-1, the front-line interaction is between cardholders and mer-chants. The merchants interact with a back-end system com-prised of their own acquirer (the merchant bank servicing abusiness), any of five payment card brand networks, and thecard issuers.

Figure 3-1: Card payment system.

Acquirer(Merchant Bank)

Paymentbrand network

IssuerCardholders

Merchant


27/68

The three steps to process a payment card transaction are:

1: Authorization. The merchant requests and receivesauthorization from the card issuer, which enables themerchant to complete the purchase with the expectationof getting paid.

2: Clearing. The acquirer and the issuer exchange infor-mation about the purchase via a network owned andoperated by a payment brand.

3: Settlement. The merchants bank pays the merchantfor the cardholder purchase and the cardholders bankbills the cardholder or debits the cardholder account.

Obviously, merchants arent required to handle security for allthree steps. Merchants are expected to check with their third-party service providers and get their certificate of PCI compli-ance. Otherwise, the domain of a merchants responsibility forPCI security is in the authorization phase of card processing(see Figure 3-2).

The authorization phase has many points of vulnerability thatcould expose cardholder data to unauthorized access.Merchants must secure cardholder data passing through sev-eral system elements, including:

Point-of-sale PIN entry devices.

Point-of-sale terminals.

Servers used to process and store cardholder data.

Payment applications.

Internal networks used for cardholder data.

Wireless access points.

Routers, gateways and other network devices.

Virtualization components, including virtual machines,

switches/routers, applications and desktops, and hyper-visors.

Network connectivity with third-party card serviceproviders and web-based shopping carts.

Storage and backup systems used for cardholder data.

Part III: Surveying Requirements of the PCI Data Security Standard 23


28/68

Network-attached printers used for transferring card-holder data to paper.

Paper-based storage systems.

Portable devices that could link to cardholder data (lap-tops, handheld devices, USB-attached storage devicesand smart phones for example).

Insecure internal card processing procedures and accesscontrols.

Disgruntled employees or contractors.

Guests with access to network with cardholder data.

Poor physical security of the building and devices usedfor cardholder data.

Poor procedures for monitoring security, finding vulnera-bilities and fixing them.

Lack of a policy or interest in security by management.

Figure 3-2: The primary domains of PCI security responsibility for a

merchant.

Wired POS Wireless POS

Merchant Network

Router

Server

Acquirer, SP or Payment Processor

Internet



29/68

Two Kinds of PCI Requirements:Technology and Process

The PCI Data Security Standard specifies two kinds of tools orcontrols for fixing the vulnerabilities mentioned in the previ-ous section and securing cardholder data. They are technologyandprocess:

Security technology consists of software, hardware and

third-party services used to implement purpose-builtapplications that protect cardholder data from variousthreats.

Security process is a specific set of operational proce-dures used to implement and maintain protection,which may or may not require a particular type ofsecurity technology.

Quite often, though, technology and process go hand-in-hand.

For example, every merchant needs to stop malware such asviruses, worms, and spyware from breaching cardholder data.The PCI-approved solution for malware entails both technol-ogy andprocess:

Technology: Deploy anti-virus software on all systemscommonly affected by malicious software (particularlypersonal computers and servers).

Process: Ensure that all anti-virus mechanisms are cur-rent, actively running, and generating audit logs.

Merchants must devote ongoing attention to PCI. Compliancewith PCI isnt a one-shot event it demands continuous moni-toringof all security technologies and processes for protectingcardholder data. But the benefits are worth the effort.

As we explained in Part I, the PCI Data Security Standard hassix major goals with 12 associated requirements. In the nextsections, we explain the PCI requirements, condensed fromthe official standard. (The information in this book does notreplace granular requirements in the actual standard. Consult



30/68

PCI DSS Requirements and Security Assessment Proceduresforfull details. A copy is posted at the PCI Security Standards

Council website:www.pcisecuritystandards.org.)

Build and Maintaina Secure Network

The network is the glue connecting payment card terminals,

processing systems, and retail commerce in general. Byexploiting network vulnerabilities, a criminal can access card-holder data much more easily than when thieves had to gainphysical access to your building and systems. The Internetand web were never designed with security as a core require-ment, so its vital that merchants implement PCI controls tosecure their internal networks, and links through external net-works to third-party service providers who process card-holder data. Toward this end, the PCI Data Security Standard

provides the following two requirements for network security.

Requirement 1:Install and maintain a firewallconfiguration to protectcardholder dataThe firewall is a fundamental security tool that every mer-chant must use when cardholder data on the internal networkis potentially exposed to the Internet. In the world of network-ing, a firewallcontrols the passage of electronic traffic withinyour internal network and between internal and external net-works. Using a firewall on your network has the same value asusing mechanical locks on doors to your physical business.Firewalls keep the bad guys out.

Firewall capability is often built into another device called arouter, which is hardware or software that provides connec-tion functionality for traffic flowing between networks. Forexample, most Wi-Fi routers for wireless hotspots include afirewall.

http://pcisecuritystandards.org/http://pcisecuritystandards.org/http://pcisecuritystandards.org/


31/68

PCI requires the use of a firewall, but it also asks merchants touse appropriate processes to ensure that the firewall effec-

tively blocks malicious traffic. PCI requires you to use firewalland router configuration standards that must be tested everytime you change equipment or software configurations. Thesemust be reviewed at least every six months. Merchants needto be aware of all connections to cardholder data includingwireless. Your firewall configuration must deny all traffic tothe cardholder data except for authorized users and uses.

Your firewall and router configuration must prohibit unautho-

rized access to system components in your cardholder dataenvironment. Access to non-essential system components andports should also be blocked. Be sure to install personal fire-wall software on each mobile and/or employee-owned com-puter that connects to your cardholder data environment orto the public Internet.

Follow this requirement and youll have fixed a major expo-sure to cardholder data!

Requirement 2:Dont use vendor-supplieddefaults for system passwords andother security parametersIts vital for merchants to ensure strong passwords are usedfor PCI security. Doing so may seem obvious, but the easiestway for hackers and criminals to breach your cardholder datais by guessing the right password.

When software and hardware comes out of the box, the pass-words are set to a default value. The most common securityerror by merchants who deploy these is to not change defaultpasswords. Default passwords are easily retrieved with a

search engine, so leaving them intact is like giving thieves amaster key to access your cardholder data. Yikes!

Table 3-1 shows typical default passwords that you need tochange beforeyou deploy any infrastructure used with card-holder data.



32/68

Table 3-1 Typical Default Passwords to

Change Before Deployment[no password] manager

[name of product or vendor] pass

1234 or 4321 password

access root

admin sa

anonymous secret

database sysadmin

guest user

The PCI Data Security Standard directs merchants to developconfiguration standards for all system components that

address all known vulnerabilities. This includes changingdefault passwords for wireless devices that link to the card-holder data environment or are used to transmit cardholderdata. PCI says you need to encrypt all non-console adminis-trative access such as when using a browser to manage awireless router. The next section explores encryption andother ways to ensure the security of cardholder data.

Protect Cardholder DataThe goal of protecting cardholder data is at the heart of PCI.Various technical methods of protecting cardholder dataexist, such as encryption, tokenization, truncation, maskingand hashing. But you dont have to be a tech guru to under-stand their purpose: to make cardholder data unreadabletounauthorized people. Even if a thief manages to smashthrough security controls and obtain cardholder data, theinformation will have no value because the thief will be unableto read and use it.

We gave a general description of cardholder data at the begin-ning of Part II, but this is a good place to dive deeper and clar-ify exactly what merchants must protect to comply with PCIrequirements.



33/68

Cardholder data is any information printed on or stored on apayment card. Digital storage is on the magnetic stripe on the

back of a card, or in a chip embedded on the front of somecards. The Primary Account Number (PAN) is the most promi-nent cardholder data, along with the cardholders name, serv-ice code and expiration date. In addition to these, sensitiveauthentication data must be protected. The cardholder datawe mean here is data thats processed or stored in the mer-chants information technology infrastructure, and data trans-mitted over open, public networks like the Internet.

Table 3-2 summarizes cardholder data elements and sensitiveauthentication data, plus the security guidelines required(data such as PIN numbers should never be stored, so protec-tion by the merchant isnt applicable).

Table 3-2 Cardholder Data Elementsand PCI Security Guidelines


Source: PCI DSS


34/68

Requirement 3:

Protect stored cardholder dataIf you dont store cardholder data, its easy compliance withthis PCI requirement is automatic. PCI compliance requiresmerchants to keep cardholder data storage to a minimum, andto create a retention and disposal policy limiting this practiceto the minimum required for business, legal, and/or regula-tory purposes.Neverstore sensitive authentication data(detailed in Table 3-2). Some merchants do so at great risk to

customers and to themselves. Dont fall into this trap if youdont need it, dont store it!

A typical place where merchants electronically gather andinappropriately store cardholder data is the card-not-presentpurchase done via mail, telephone, or a web-based e-com-merce application. Figure 3-3 shows the tools and controlsused to authenticate these purchases. Non-compliance withPCI begins when a merchant stores these data. Ironically,

breaches have occurred where the merchant wasnt evenaware that these data had been stored. Analyze your busi-nesss card processing applications to find out exactly wherecardholder data resides at all times, and eliminate storage ofall sensitive data after authentication. Sensitive authenticationdata may notbe stored at any time, even if encrypted.

Stored data must kept to a minimum, and be strictly managedby a data retention and disposal policy. The PCI Data Security

Standard provides guidelines for cardholder data that you canstore. Aside from employees who may have a legitimate busi-ness reason to see a cardholders full PAN, a merchant mustalways mask display of this number. In other words, the mostyou can show are the first six and last four digits. This restric-tion doesnt supersede stricter requirements for displayingPAN on a point-of-sale receipt.



35/68

Figure 3-3: Controls for authorizing and validating card-not-presentpurchases.

Merchants must always render PAN unreadable wherever itsstored, including backup media, in logs, on portable digitalstorage devices, and via wireless networks. Permissible tech-nology solutions for masking PAN include:

Strong one-way hash functions or a hashed index, whichshows only index data that point to database recordscontaining the PAN.

Truncation, which deletes a forbidden data segment and

shows only the last four digits of the PAN.

Strong cryptography and associated key managementprocesses and procedures. Cryptographic keys must beprotected from disclosure and any misuse documentedby the merchant.

Card-Not-Present Merchant

Payment Channels

Mail

Telephone

E-Commerce

Controls

CID, CAV2, CVC2, CVV2

AVS

3D Secure(Verified by Visa, MasterCardsSecure Code, JCBs J/Secure)



36/68

Requirement 4:Encrypt transmission of card-holder data across open, publicnetworksCardholder data that moves across open, public networksmust be encrypted to protect it from being compromised bythieves. PCI requires you to use strong cryptography andsecurity protocols such as SSL/TLS or IPSec to protect sensi-tive cardholder data during transmission. Examples of open,public networks include the Internet and email, wireless hotspots, global system for mobile communications (GSM) andgeneral packet radio service (GPRS).


Understanding strong cryptographyCryptography is a complex mathe-matical process of making plaintextdata unreadable to people who donthave special knowledge in the formof a key to unlock the data.Encryption transforms plaintext intociphertext, while decryption changes

ciphertext back into plaintext.Cryptography may be used on datathats stored or transmitted over anetwork.

Strong cryptography is extremelyresilient to unauthorized access provided that the key isnt exposed.The strength of a cryptographic for-mula relies on the size of the key. The

key you use needs to meet the mini-mum size suggested by several indus-try recommendations. A good publicreference is the National Institute ofStandards and Technology (NIST)Special Publication 800-57 (find it at

http://csrc.nist.gov/pub

lications/PubsSPs.html).You may need technical assistanceto implement strong encryption butcommercial and public domain solu-tions are available. Options that meetminimum key bit security require-

ments include:80 bits for secret key based sys-tems (such as TDES)

1024 bits modulus for public keyalgorithms based on the factor-ization (such as RSA)

1024 bits for the discrete loga-rithm (such as Diffie-Hellman)

with a minimum 160 bits size of alarge subgroup (such as DSA)

160 bits for elliptic curve cryp-tography (such as ECDSA)

(Source: PCI DSS Glossary)
http://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.htmlhttp://csrc.nist.gov/publications/PubsSPs.html


37/68

New changes to this encryption requirement focus on upgrad-ing the security of wireless networks transmitting cardholder

data, or connecting to the cardholder data environment. PCIsuggests using the industry standard best practices (IEEE802.11i, for example) to implement strong encryption forauthentication and transmission. The use of WEP (WirelessEquivalent Privacy) was prohibited as of June 30, 2010.

Neversend unprotected PANs with end-user messaging tech-nologies such as email, text messaging, instant messaging orchat.

Maintain a VulnerabilityManagement Program

Vulnerability management is a process that every merchantcan use to avoid exploiting weaknesses in your card payment

infrastructure. New vulnerabilities appear every day due toflaws in software, faulty configuration of applications and ITgear, and (dare we say it?) good old human error. Whatevertheir source, vulnerabilities dont go away by themselves.Their detection, removal, and control require vulnerabilitymanagement. VM, as vulnerability management is called, isthe regulated, continuous use of specialized security toolsand workflow that actively help to eliminate exploitable risks.Every merchant can benefit from a comprehensive VM pro-

gram to protect cardholder data. Typical VM workflowincludes these steps:

Ensuring that security policies for cardholder data workwith the VM process.

Tracking IT inventory and categorizing assets to help pri-oritize the elements most critical for safeguarding card-holder data.

Scanning systems for vulnerabilities (more on this laterin the section Requirement 11: Regularly test securitysystems and processes).



38/68

Verifying vulnerabilities against inventory to weed outfalse positive indications of weak points.

Classifying and ranking risks.

Pre-testing and applying patches, fixes, andworkarounds.

Rescanning to verify compliance.

In the next sections we describe two specific requirements ofPCI for vulnerability management.

Requirement 5:Use and regularly update anti-virus software or programsAnti-virus software comes up a lot in discussions about ITsecurity, and for good reason. Vulnerabilities such as mal-

ware, viruses, Trojan horses and worms often inject them-selves into a cardholder data system by means of email andother common online activities undertaken by your employ-ees. Anti-virus software is the technology used to limit thisrisk vector to protect cardholder data.

PCI requires merchants to use anti-virus software on all sys-tems that touch the cardholder data environment, which maybe affected by malicious software. The risk is especially high

for personal computers and mobile devices that plug into thecardholder data environment. Servers are another high-impact risk that need anti-virus protection.

The process portion of the anti-virus requirement is to ensurethat the technology you deploy is the current version, isalways running on every affected device, and generates auditlogs to help auditors verify compliance during a PCI assess-ment or forensic analysis. Without audit logs, you could be

unaware of an unauthorized browser extension or malwarethat reads PANs as theyre entered into a payment application.



39/68

Requirement 6:

Develop and maintain securesystems and applications

Data thieves frequently exploit vulnerabilities within the card-holder data system and its applications. So when you pur-chase payment applications and devices used to accept cardpayments (it would be most unusual for a small merchant tobe creating these from scratch), you need to buy only those

payment applications and devices that are approved by thePCI Security Standards Council. Lists of each are posted onthe Council website.

Manufacturers and developers must follow guidelines of thePA-DSS and PIN Transaction Security Requirements to lockdown those attack vectors. The specifications in Requirement6 are primarily for organizations that develop their owncustom payment applications. Whether you develop in-house

payment applications or buy them from someone else, thedevelopment process needs to use secure coding best prac-tices such as Open Web Application Security Project(OWASP).

Vulnerabilities in systems and applications may occur overtime as data thieves discover ways to subvert what was oncesecure. Security patches for payment applications developedin-house must be devised by your organization. You must

install vendor-supplied security patches to eliminate vulnera-bilities. Think of these as a quick-repair job addressing a spe-cific section of programming code prone to error.

New vulnerabilities appear every day so merchants must dofrequent audits and repair weaknesses as soon as possible.The process of patching requires merchants to employ sev-eral strategies to keep systems and applications secure. In anutshell:

Install the most recently-released patch for critical cardpayment systems and applications within one month ofrelease.

Apply patches to less-critical systems as soon as youcan, based on priorities established by your vulnerabilitymanagement program.



40/68

Follow a process to ensure you dont overlook a new vul-nerability. A vulnerability scanning service can provide

you with this information automatically. Scans should rankvulnerabilities as "High," "Medium" or "Low" to prioritizethem for patching and remediation.

If you develop your own payment applications, followindustry best practices that incorporate security into theentire software development lifecycle.

Follow change control procedures whenever you changepayment card system components or configurations.

Follow secure coding guidelines for internal and externalweb applications and use a process to review customapplication code for coding vulnerabilities. Web applica-tions are particularly susceptible to exploitation of vulner-abilities such as remote code execution, SQL injection,format strings, cross-site scripting, and username enumer-ation. For a swift guide to these issues, see our companionbook, Web Application Security For Dummies!

To secure your public-facing web applications, make sure

you regularly use specialized web application scanningtools or methods. Optionally, you can also install a webapplication firewall.

Implement Strong AccessControl Measures

The essence of access controlis simple: it enables merchants topermit or deny the physical or technical means to access PANor other cardholder data. Access control is so crucial for PCIthat its the only goal in the Data Security Standard with threeseparate requirements. These provide merchants with a com-prehensive strategy for implementing strong access control:

The first requirement ensures that cardholder data canbe accessed only by employees with a business need to

know no snooping allowed!

The second addresses logical access pertaining to PINentry devices, payment applications, networks, PCs andother computing gear used to view cardholder data.

The third requirement addresses physical access such aslocks and other security measures used to protect paper-based records and cardholder system hardware.



41/68

Requirement 7:

Restrict access to cardholder databy business need to knowSegregating access rights is nowhere more crucial than withcardholder data. PCI requires merchants to ensure thatemployees are granted access rights to the leastamount ofdata they need to perform a job. To put it bluntly, if anemployee doesnt need access to cardholder data, the

employee must not have access.

To implement this requirement, you need to establish anaccess control system for each element of the cardholder datainfrastructure, based on a users need to know. All accessrights must be set by default to deny all unless an individualis specifically allowed access to designated cardholder data no exceptions!

Requirement 8:Assign a unique ID to each personwith computer accessThe intent of Requirement 8 is to aid forensic analysis of card-holder data access that permits a merchant to trace every

action of electronic access to a specific worker. To do this, PCIspecifies the following:

You must assign each worker a unique user name beforegranting access rights to cardholder data system compo-nents or the data itself.

Each user must be authenticated to access the system byusing a password or passphrase, or two-factor authenti-cation (see the nearby sidebar, "Feeling the power of

'Strong Authentication'" for an explanation).

For all remote access to the network, you need to imple-ment two-factor authentication. The standard suggestsusing a remote authentication and dial-in service, a terminalaccess controller access-control system with tokens, or avirtual private network (VPN) with individual certificates.



42/68

You must make all passwords unreadable for each card-holder data system component both in storage and

during transmission using strong cryptography basedon approved standards.

For non-consumer users and administrators, be sure touse proper user authentication and password manage-ment on all system components.


Feeling the power of StrongAuthentication

Authenticationis the process of ver-ifying a device or a person for securitypurposes. Traditional authenticationhas been single factor, which meansonly one piece of information was

required to complete authentication.Multi-factor authentication raises thebar by requiring two or more factorsor pieces of information to completeauthentication. When a merchant usesmulti-factor authentication, expertscall this strong authentication.

An authentication factor usually falls

into one of three types:Something a user knows, such asa password or passphrase, a keysequence, or a personal identifi-cation number (PIN). A securepass code must include at leastseven alpha and numeric char-acters, and be changed at leastonce every 90 days.

Something a user has, such asan ID card, a device or securitytoken, or a telephone.

Something a user is or does,which usually is a fingerprint,retinal pattern, voice pattern, sig-nature, or DNA sequence.

For example, in-person payment card

authentication requires two factors.First, a user presents the physicalcard with its associated PAN, andthen the user enters the PIN.Authenticating a card-not-presenttransaction requires presentation ofthree factors: the PAN, the card expi-ration date, and the three-digitCAV2/CID/CVC2/CW2.

The PCI Data Security Standardrequires you to have employees usetwo-factor authentication for access-ing cardholder data. Using one factortwice (such as two separate pass-words) is not considered two-factorauthentication! The employee mustalso meet the precondition of being

authorized to access cardholder dataas a job function requirement. Byusing strong authentication, you canfulfill PCI Requirement 8 and help pro-tect cardholder data.


43/68

Requirement 9:

Restrict physical access to card-holder dataLest you forget about old fashioned non-digital security, PCIalso instructs merchants to restrict physical access to card-holder data or systems that house cardholder data includinghardcopies. This provision has several sub-requirements:

Limit and monitor physical access to systems in the card-holder data environment with facility entry controls.

Use video cameras to monitor entry and exit points ofyour cardholder data storage facility, and store thefootage for at least three months. Surveillance is notrequired for point-of-sale locations.

Use badges or other procedures to help all workerseasily tell the difference between an employee and a visi-

tor especially in the cardholder data environment.

Authorize all visitors before admitting them to areaswhere cardholder data is processed. Give visitors a phys-ical token that expires and clearly identifies them as non-employees. Visitors must surrender the physical tokenbefore they leave the facility or upon expiration.

Retain visitor information and activity in a visitor log foraudit purposes, and retain it for at least three months

unless restricted by law.

Store media backups of cardholder data in a secure loca-tion (preferably offsite).

Ensure that all paper and electronic media with card-holder data is physically secure.

Strictly control the distribution of any media with card-holder data both to internal and external recipients.

Formally approve any movement of media with card-holder data from a secured area especially when it goesto individuals.

Strictly control the storage and accessibility of mediawith cardholder data.

Be sure to destroy media with cardholder data when youno longer need it for business or legal reasons.



44/68

Regularly Monitor andTest Networks

Your network is one of the most important elements in thecardholder data environment. Physical and wireless networksenable the flow of cardholder data from PIN entry devices andPCs to servers, payment applications, storage media, andonward to the third-party processor or acquiring bank. A vul-nerability existing at any point of the network spells trouble if

a data thief exploits it for unauthorized access to cardholderdata.

New vulnerabilities appear every day. Merchants must regu-larly monitor and test all of their networks to find and fix vul-nerabilities before trouble occurs.

Requirement 10:Track and monitor all accessto network resources andcardholder dataThis requirement is all about system activity logs. Loggingmechanisms are critical for vulnerability management andforensics. If something goes wrong, only a log can provide the

data you need to determine who did what, when it happened,and what needs to be fixed. For this reason, merchants mustcreate a process that links all access by individual users tocardholder system components especially when done withadministrative privileges.

Your IT staff has a big role for meeting this requirement. ITmust implement automated audit trails for monitoring andtracking. Recording the operational minutia is the only way to

reconstruct events in question. You may be required to showinvestigators individual user accesses to cardholder data.Documentation may be required for all actions taken byanyone with root or administrative privileges with preciseaudit trails. Merchants must be able to show details such asinvalid logical access attempts, use of identification andauthentication mechanisms, initialization of audit logs, andcreation and deletion of system-level objects.



45/68


The ability to produce detailed audit reports on demand isimportant for PCI. The standard requires the following:

You have entries for all system components for eachevent.

You ensure a minimum level of detail that includes userID, type of event, date, time, success or failure indication,origination of event, ID or name of affected data, systemcomponent or resource.

All system clocks/times are synchronized.

Audit trails are impervious to alteration.

The logs for security-related functions of every systemcomponent are reviewed at least daily.

You store the audit trail history for at least one year.Three months of data must be immediately available foranalysis.

Requirement 11:Regularly test securitysystems and processes

New vulnerabilities are discovered daily but thats no reasonto be paralyzed with dread. PCI requires merchants to regu-larly test cardholder data systems and processes in order to

systematically find those vulnerabilities and fix them. Items totest include wired and wireless networks, network gear,servers, other system components, processes, and customsoftware. Testing must be frequent, and is vital right after youmake big changes such as deploying new software or chang-ing a system configuration.

Threats come from inside and outside so you need to testboth your internal and external networks every 90 days.

How to test?Vulnerability scanning products and services enable youto scan automatically and fulfill PCI testing requirements.You need to use an Approved Scanning Vendor (ASV) to scanyour external network. A list of ASVs is available at


46/68


www.pcisecuritystandards.org. A Qualified SecurityAssessor may audit all 12 requirements of PCI, but cant do

network scans unless it is also an ASV.

What to test?PCI requires at least quarterly scans of your cardholder datanetwork, including wireless. Follow these points:

For wired networks, use an ASV to scan your externalnetwork. Internal networks may be scanned by your in-house staff with scanning tools.

For wireless networks, use a wireless analyzer or wirelessintrusion detection service or intrusion prevention serv-ice (IDS/IPS). You must be able to identify allwirelessdevices to control their access to the cardholder dataenvironment.

IDS/IPS is also required to monitor all other traffic in thecardholder data environment. Alerts should notify secu-rity specialists immediately. You need to keep securitysoftware up to date.

Use file integrity monitoring software. This alerts you tounauthorized changes to critical system files, configura-tion files, and content files. Compare critical files at leastweekly.

When to test?Merchants must scan their internal and external networks atleast quarterly, and always right after making a big change tothe network. Youre not required to hire an ASV to do internalscans, but must have one to do external scans. Merchants mustdo internal and external penetration testing (pen test) at leastannually. Apenetration testis a controlled attack on your card-holder data environment. Merchants must also do a pen testafter a big change to the cardholder data environment.
http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/


47/68


Humane Society of the US case study

Industry: Not-for-profitHeadquarters: Washington, DC

Business: Leading animal protectionnon-profit that fights for the protec-tion of animal rights through advo-cacy, education, legislation, andhands-on programs

Size: The nations largest animal pro-

tection organization with 10+ millionmembers and constituents

By turning to QualysGuard PCI, wesignificantly save on the time andresources we need to dedicate tomaintaining PCI compliance. ChiefInformation Officer

Objectives:

The Humane Society had main-tained a secure network, butcontinuously maintaining PCIcompliance was costly and time-consuming.

The organization needed astreamlined way to complete therequired PCI DSS questionnairesand network vulnerability audits,and validate compliance to itsacquiring banks.

Results:

QualysGuard PCI helps theHumane Society to automaticallyvalidate its PCI DSS complianceand its now able to quickly com-plete PCI DSS Self-AssessmentQuestionnaires.

QualysGuard enables theHumane Society to document

and submit proof of complianceto acquiring banks.

The Humane Society can protectits member and contributor infor-mation with help fromQualysGuard.

Take a look atwww.qualys.com/customers/success/ for more

info and other case studies.
http://www.qualys.com/customers/successhttp://www.qualys.com/customers/successhttp://www.qualys.com/customers/successhttp://www.qualys.com/customers/successhttp://www.qualys.com/customers/success


48/68

Using the testsWhen you scan for vulnerabilities, the report presenting scanresults need to provide a clear, overall, pass/fail as well as apass/fail for each individual component. The pass/fail is deter-mined by the ASV based on requirements set by the PCICouncil. The report should classify the information with theCommon Vulnerability Scoring System to help prioritize reme-diation.

The CVSS scores "High Severity" vulnerabilities on a scale of7.0 through 10.0; "Medium Severity" from 4.0 to 6.9; and "LowSeverity" from 0.0 to 3.9. To pass a scan, the Council prohibitsany vulnerabilities in the cardholder data environment with abase score equal to or higher than 4.0.

Maintain an InformationSecurity Policy

A merchant organization needs to govern all PCI securityactivity with clear security policies. The policies make iteasier to create and follow your PCI compliance program. Theresult of good policies makes it easier and faster for your ITsecurity team to discover vulnerabilities in the cardholderdata environment, remediate those security holes, and pro-

duce documentation to satisfy requirements for compliance.

Policy-making starts at the top of an organization, and mustflow through to each worker so that everyone understandstheir role in protecting cardholder data.



49/68

Requirement 12:

Maintain a policy that addressesinformation security forall personnel

Your security policies determine the nature of the controlsused to ensure security and comply with PCI requirements.The policies and controls need to apply to everything in the

cardholder data environment PIN entry devices, PCs andother endpoints, servers, network services, applications, andthe people who use them.

The PCI Data Security Standard requires merchants to main-tain a policy that addresses information security for all per-sonnel. The following list adapts text from nine areas of thestandard that must be established, published, maintained,and disseminated to everyone affected by the policy:

Comprehensive formal policy: Your security policy mustaddress all PCI requirements. You need a process to iden-tify vulnerabilities and assess risk, with at least an annualreview. Reviews must be conducted when a cardholderenvironment changes.

Daily procedures: Be sure your daily operations proce-dures meet PCI requirements.

Usage policies: all personnel must have usage policiesfor each technology they use that affects the cardholderdata environment. This would include handheld devicesand laptops, tablets, personal digital assistants, remov-able electronic media, Internet, wireless, remote access,email and other applications.

Clear responsibilities: All personnel must clearly under-stand their information security responsibilities.

Assigned responsibilities: Assign responsibilities to spe-cific individuals, such as someone to receive andrespond to security alerts, or someone who should moni-tor and control access to data.



50/68

Security awareness program: Your business must for-mally teach all personnel the importance of cardholder

data security.

Employee screening: You need to screen all personnelbefore hiring to help limit security risks from inside yourbusiness.

Third-party services screening: If you share cardholderdata with a third-party service provider, they must alsocomply with PCI.

Incident response plan: Be prepared with a detailed planfor immediate response to a breach.

Compensating Controls for PCIMany merchants face legitimate business and technical con-straints related to specific PCI requirements. To acknowledgethis fact of business life, the PCI Data Security Standard

includes an appendix called Compensating Controls. The ideais to give merchants a measure of flexibility in following a par-ticular control in PCI DSS, provided the merchant has suffi-ciently mitigated the risk with a compensating control.

Compensating controls arent automatically approved. Theymust meet these criteria:

Provide identical intent and rigor of the PCI require-

ment.

Provide identical level of security defense as the PCIrequirement.

Be above and beyond other PCI requirements. Thismeans existing PCI requirements cannot also serve ascompensating controls if theyre already required for theitem under review. They may be considered if theyrerequired somewhere else, but not for the item under

review. You may also combine existing PCI requirementsand new controls as a compensating control.

Be effective enough to meet additional risk created bynot following the PCI requirement.



51/68

The use of compensating controls allows merchants somemeasure of flexibility in complying with PCI. But merchants

must still be able to pass an annual assessment by a QualifiedSecurity Assessor according to the standards set in PCI DSSAppendix B. As with all PCI requirements, processes and con-trols must assure continuous use of compensating controlsafter each annual assessment.

Our summary of PCI requirements should give you a solidgrasp of how to comply with the standard. You can find fulldetails of each requirement inPCI DSS Requirements and

Security Assessment Proceduresat www.pcisecuritystandards.org. In Part IV, we describe the actual processof what a merchant can do to comply with PCI DSS.

http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/


52/68

Part IV

Verifying Compliancewith PCI

In This Part Understanding the formal process of compliance

Preparing for a PCI onsite compliance assessment

Choosing a Qualified Security Assessor or an Approved ScanningVendor

Using a Self-Assessment Questionnaire

The PCI Data Security Standard must be met by merchants and indeed, anyorganization that stores, processes ortransmits cardholder data. While the PCI Security StandardsCouncil manages the standard, the card brands do the actualenforcement. Each brand has its own cardholder data securitycompliance program, but all brands endorse PCI DSS and rec-

ognize its requirements as meeting their own technicalrequirements.

Each card brand still has a few unique requirements for com-pliance. These mainly deal with merchant classification levelsand rules for self-assessment, such as when to use a QualifiedSecurity Assessor. Consult these links for specific card brandcompliance programs:

American Express: www.americanexpress.com/datasecurity

Discover Financial Services: www.discovernetwork.com/fraudsecurity/disc.html

JCB International: www.jcb-global.com/english/pci/index.html
http://www.americanexpress.com/datasecurityhttp://www.americanexpress.com/datasecurityhttp://www.americanexpress.com/datasecurityhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.jcb-global.com/english/pci/index.htmlhttp://www.discovernetwork.com/fraudsecurity/disc.htmlhttp://www.americanexpress.com/datasecurity


53/68

Part IV: Verifying Compliance with PCI 49

MasterCard Worldwide: www.mastercard.com/sdp

Visa Inc: www.visa.com/cisp (US)

Visa Europe: www.visaeurope.com/ais

Following the Processof Compliance

The most important idea to remember about PCI complianceis your merchant level number. The leveldetermines thedegree of rigor that your organization will be subjected to forpurposes of verifying PCI compliance. The levels are based oncriteria published by the card brands, and there are a few dif-ferences from one card brands compliance program toanother.

For purposes of illustration, Table 4-1 shows the typical mer-

chant levels and criteria. (Please consult specific card brandcompliance programs for exact specifications.)

Level 2 to 4 merchants must complete an annual Self-Assessment Questionnaire (SAQ) and an Approved ScanningVendor (ASV) must do a quarterly scan of the cardholder datanetwork. If you use compensating controls, you need toinclude that documentation with yourReport on Compliance(described in the later section Meeting the Reporting

Requirements of PCI DSS). Level 2 to 4 merchants dontrequire an annual onsite assessment, except in some casessuch as after suffering a breach of cardholder data. On-siteassessments must be completed by a Qualified SecurityAssessor (QSA). Later in this part, we describe how to choosea QSA and ASV, and how merchants can select and use a SAQ.

For most merchants, the formal process of PCI complianceconsists of submitting the annual SAQ and quarterly ASV-gen-

erated network scan reports. However, if your organization isrequired to have an annual security assessment, you need tofollow other steps in the process of PCI compliance. Read on!
http://mastercard.com/sdphttp://www.visa.com/cisphttp://www.visaeurope.com/aishttp://www.visaeurope.com/aishttp://www.visa.com/cisphttp://mastercard.com/sdp


54/68


Table4-1:TypicalCard

BrandMerchantLevelsandValidationA

ctions

Level

Criteria

On-Si

te

Self-

Network

Security

Assessmen

t

Scan

Audit

Questionna

ire

1

Anymerc

han

t,regar

dlesso

f

Requ

ire

dannua

lly

.

Requ

ire

dquar

ter

ly.

acceptancec

hanne

l,

process

ingm

orethan6

milliontransactionsper

year.

Anymerc

hantthat

su

ffere

dasecur

ity

breac

h

resu

lting

incar

dho

lder

data

comprom

ise.

2

Anymerc

han

tprocess

ing

Requ

ire

dannua

lly

.

Requ

ire

dquar

ter

ly.

between1to

6million

transactionsperyear.

3

Anymerc

han

tprocess

ing

Requ

ire

dannua

lly

.

Requ

ire

dquar

ter

ly.

between20,0

00to1million

transactionsperyear.

4

Allothermerchantsnot

in

Requ

ire

dannua

lly

.

Requ

ire

dquar

ter

ly.

Leve

ls1

,2or

3,

regar

dlesso

f

acceptancec

hanne

l.


55/68

Preparing for a PCI On-siteAssessment

Depending on the complexity of your cardholder data environ-ment, an onsite PCI security assessment requires activepreparation, coordination and follow-up. Your organizationneeds to designate a project manager to coordinate theprocess with internal resources and the Qualified SecurityAssessor (QSA) especially during onsite visits. Preparation

can smooth execution and help ensure a successful assess-ment. Heres a list of the advance preparation you need to do:

Coordinate internal resources and availability includingIT security, networking, infrastructure, payment cardapplication owners, legal, human resources and execu-tive management.

Create timelines and internal reporting mechanisms.

Document everything related to your cardholder dataenvironment including security policies, network dia-grams, change control procedures, and log files specifiedby PCI DSS. Include PCI letters and notifications.

Describe compensating controls and why they wereselected, the business and technical reasons for the par-ticular implementation and deployment, and perform-ance and results.

Describe the cardholder data environment, especially thecardholder data flow and location of cardholder datarepositories.

The Qualified Security Assessor requests these documentsduring the onsite PCI compliance assessment. The processincludes interviews and inspections of the physical and logi-cal cardholder data infrastructure. An assessment usually fol-lows five steps.

Step 1: ScopingScopingis the process of specifying exactly what is tested forcompliance. It limits the PCI assessment to security technol-ogy and processes affecting the security of cardholder data. A



56/68


merchant can leverage network segmentation to effectivelyisolate systems that store, process, or transmit cardholder

data from the rest of the network. For purposes of PCI compli-ance, controls are required only for the affected segments. Inthe practical world, most merchants would probably want toextend security controls to their entire IT infrastructure toensure comprehensive protection beyond the letter of the law.

The PCI DSS notes that the scope of assessment includes allvirtualization components that are part of the cardholder dataenvironment. These components may include virtual machines,

virtual switches and routers, virtual appliances, virtual applica-tions and desktops, and hypervisors.

Step 2: AssessingDuring a PCI assessment, assessing is where the QSA selects asample or subset of in-scope security controls and processes.Compliance tests are done only on the subset. Sampling is

allowed because examining and testing every single controland process is a little impractical! (You can find a flowchartfor scoping and sampling in PCI DSS Appendix D atwww.pcisecuritystandards.org.)

Step 3: Verifying compensatingcontrolsIf youve investigated a particular risk associated with PCI andelected to deploy a compensating control, the QSA will exam-ine the compensating control and weigh your arguments forits alternative deployment. The QSA may test the compensat-ing control to verify its effectiveness. The QSA must OK thecompensating control in order for you to pass the assessmentfor PCI compliance.

Step 4: ReportingReporting includes four steps:

The QSA completes a formal document called theReporton Compliance (ROC).

You attach evidence of passing four quarterly vulnerabil-ity scans from an Approved Scanning Vendor.
http://www.pcisecuritystandards.org/http://www.pcisecuritystandards.org/


57/68


You complete theAttestation of Compliance (see theDocuments Library on the Council's website).

You submit the three documents to your acquirer or pay-ment card brand.

Step 5: ClarifyingSometimes the acquirer or payment brand may ask you forclarification on a point covered in the Attestation ofCompliance. You must meet requests for clarification to be

compliant with PCI.

Choosing a QualifiedSecurity Assessor

Sometimes a merchant must hire a Qualified Security Assessor(QSA) in order to assess compliance with the standard. The

PCI Security Standards Council website posts a list of QSAs,which are data security companies that are trained and certi-fied to do onsite assessments that verify compliance with PCIDSS. A merchants choice of the QSA is important to gettingcertified for compliance with the standard.

Aside from the usual customer testimonials on a QSA website,be sure to check out the QSAs business culture. Will it fit withthe culture of your own organization? Seek a QSA that knows

how your business works. Their experience with your stan-dard processes will help make the assessment go moresmoothly and quickly and will be invaluable for understandingthe rationale of your compensating controls.

The QSAs job is to verify your documentation, and technicaland process controls for adherence to thePCI DSS

Requirements and Security Assessment Procedures (see theCouncils website for a copy). The QSA will define the scope of

your assessment and select systems for sampling. Ask the QSAto describe its standard density formula and how that pro-duces a sample. Find out how the QSA will assess your card-holder data environment, such as by function or technology.

The QSA will produce your final report called theReport onCompliance (ROC), which you must submit to your acquireror payment card brand.


58/68

Your organization might ask the QSA to do other security-related custom services, such as a penetration test or a PCI

gap assessment. This is another reason to look for a good fit toensure a successful long-term engagement.

QSAs arent allowed to require any particular product or vendoras a condition to assess compliance. The QSA must accept a scanreport from any ASV. The QSA is also required to provide youwith a feedback form, which you can send to the PCI Council.

Selecting an ApprovedScanning Vendor

External network scanning is done with vulnerability assess-ment tools that are created or used by an Approved ScanningVendor (ASV). The ASV may perform the scans for the merchantor provide a self-service web-based network vulnerability scan-

ning solution specifically for PCI scanning. You can find a list ofApproved Scanning Vendors posted on the Council website.

If false positives appear in the scanning process, the ASVworks with the merchant to analyze report results, and grantappropriate exceptions with clarifying documentation.

When choosing an ASV, pick one that can help you meet com-pliance requirements and help your organization become more

secure. Beware of an ASV thats too eager to grant your organi-zation with a passing score just to get your business this ploymay do more harm than good if actual vulnerabilities arentidentified or remediated to produce real security.

The ASV scanning solution must meet several preconditions tobe approved for use by merchants:

Non-disruptive: When conducting a scan, the solution

must never interfere with the cardholder data system. Forexample, you wouldnt want the scanning process to trig-ger a system reboot, nor would you want it to conflictwith domain nam