Pci Ssc Quick Guide

pci_ssc_quick_guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 32

PCI Quick Reference Guide

Understanding the Payment Card Industry

Data Security Standard version 1.2

For merchants and organizations that store, process or transmit cardholder data

Contents

This Quick Reference Guide to the PCI Data Security Standard is provided by the PCI Security

Standards Council to inform and educate merchants and other organizations that process, store or

transmit cardholder data. For more information about the PCI SSC and the standards we manage,

please visit www.pcisecuritystandards.org.

The intent of this document is to provide supplemental information, which does not replace or

supersede PCI Security Standards Council standards or their supporting documents. Full details can

be found on our Web site.

03/09

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Contents

Introduction: Protecting Cardholder Data with PCI Security Standards ................................... 4

Overview of PCI Requirements ...................................................................................................................... 6

PCI Data Security Standard (PCI DSS) .................................................................................................... 8

Payment Application Data Security Standard (PA DSS) .................................................................. 10

PIN Transaction Security Requirements (PTS) .................................................................................... 10

Security Controls and Processes for PCI DSS Requirements ............................................................. 11

Build and Maintain a Secure Network................................................................................................... 12

Protect Cardholder Data ............................................................................................................................ 14

Maintain a Vulnerability Management Program ............................................................................... 16

Implement Strong Access Control Measures ..................................................................................... 18

Regularly Monitor and Test Networks ................................................................................................... 21

Maintain an Information Security Policy .............................................................................................. 23

Compensating Controls for PCI Security .............................................................................................. 24

How to Comply with PCI DSS ............................................................................................................................ 25

Choosing a Qualied Security Assessor (QSA) ................................................................................... 26

Choosing an Approved Scanning Vendor (ASV) ............................................................................... 27

Using the Self-Assessment Questionnaire (SAQ) .............................................................................. 28

Reporting ....................................................................................................................................................... 29

Web Resources ....................................................................................................................................................... 30

About the PCI Security Standards Council ............................................................................................... 31

Introduction

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Introduction: Protecting Cardholder Data with

PCI Security Standards

The twentieth century U.S. criminal Willie Sutton was said to rob banks because “that’s where the

money is.” The same motivation in our digital age makes merchants the new target for nancial

fraud. Occasionally lax security by some merchants enables criminals to easily steal and use personal

consumer nancial information from payment card transactions and processing systems.

It’s a serious problem – more than 234 million records with sensitive information have been breached

since January 2005, according to Privacy Rights Clearinghouse.org. As a merchant, you are at the

center of payment card transactions so it is imperative that you use standard security procedures and

technologies to thwart theft of cardholder data.

Merchant-based vulnerabilities may appear almost anywhere in the card-processing ecosystem

including point-of-sale devices; personal computers or servers; wireless hotspots or Web shopping

applications; in paper-based storage systems; and unsecured transmission of cardholder data to

service providers. Vulnerabilities may even extend to systems operated by service providers and

acquirers, which are the nancial institutions that initiate and maintain the relationships with

merchants that accept payment cards (see diagram on page 5).

Compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) helps to alleviate

these vulnerabilities and protect cardholder data.

RISKY BEHAVIOR

A survey of businesses in the U.S.

and Europe reveals activities that

may put cardholder data at risk.

81% store payment card

numbers

73% store payment card

expiration dates

71% store payment card

verication codes

57% store customer data from

the payment card magnetic stripe

16% store other personal data

Source: Forrester Consulting: The State

of PCI Compliance (commissioned by

RSA/EMC)

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

The intent of this PCI Quick Reference Guide is to help you understand the PCI DSS and to apply it to

your payment card transaction environment.

There are three ongoing steps for adhering to the PCI DSS: Assess — identifying cardholder

data, taking an inventory of your IT assets and business processes for payment card processing,

and analyzing them for vulnerabilities that could expose cardholder data. Remediate — xing

vulnerabilities and not storing cardholder data unless you need it. Report — compiling and

submitting required remediation validation records (if applicable), and submitting compliance reports

to the acquiring bank and card brands you do business with.

PCI DSS follows common sense steps that mirror best security practices. The DSS globally applies to

all entities that store, process or transmit cardholder data. PCI DSS and related security standards

are administered by the PCI Security Standards Council, which was founded by American Express,

Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Participating

organizations include merchants, payment card issuing banks, processors, developers and other

vendors.

PCI COMPLIANCE IS A

CONTINUOUS PROCESS

ASSESS

REMEDIATE REPORT

POS Merchant AcquirerService Provider

INTERNET

PUBLIC NETWORKS

WIRELESS

INTERNET

PUBLIC NETWORKS

WIRELESS

INTERNET

PUBLIC NETWORKS

WIRELESS

Overview of PCI

Requirements

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Overview of PCI Requirements

PCI security standards are technical and operational requirements set by the PCI Security Standards

Council (PCI SSC) to protect cardholder data. The standards apply to all organizations that store,

process or transmit cardholder data – with guidance for software developers and manufacturers

of applications and devices used in those transactions. The Council is responsible for managing

the security standards, while compliance with the PCI set of standards is enforced by the founding

members of the Council, American Express, Discover Financial Services, JCB International, MasterCard

Worldwide and Visa Inc.

PAYMENT CARD INDUSTRY SECURITY STANDARDS

Protection of Cardholder Payment Data

MANUFACTURERS

SOFTWARE

DEVELOPERS

MERCHANTS &

PROCESSORS PCI SECURITY

STANDARDS

& COMPLIANCE

PCI PTS

Payment Application

Vendors

Data Security

Standard

PIN Transaction

Security

PCI PA-DSS PCI DSS

Ecosystem of payment devices, applications, infrastructure and users

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

PCI Security Standards Include:

PCI Data Security Standard (DSS)

The PCI DSS applies to all entities that store, process, and/or transmit cardholder data. It covers

technical and operational system components included in or connected to cardholder data. If you are

a merchant who accepts or processes payment cards, you must comply with the PCI DSS.

PIN Transaction (PTS) Security Requirements

PCI PTS (formerly PCI PED) is a set of security requirements focused on characteristics and

management of devices used in the protection of cardholder PINs and other payment processing

related activities. The requirements are for manufacturers to follow in the design, manufacture and

transport of a device to the entity that implements it. Financial institutions, processors, merchants and

service providers should only use devices or components that are tested and approved by the PCI SSC

(www.pcisecuritystandards.org/security_standards/ped/pedapprovallist.html).

Payment Application Data Security Standard (PA-DSS)

The PA-DSS is for software developers and integrators of payment applications that store, process

or transmit cardholder data as part of authorization or settlement when these applications are sold,

distributed or licensed to third parties. Most card brands encourage merchants to use payment

applications that are tested and approved by the PCI SSC. Validated applications are listed at:

www.pcisecuritystandards.org/security_standards/pa_dss.shtml

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

The PCI Data Security Standard

The PCI DSS version 1.2 is the global data security standard adopted by the card brands for all

organizations that process, store or transmit cardholder data. It consists of common sense steps that

mirror best security practices.

Goals PCI DSS Requirements

Build and Maintain a Secure

Network

1. Install and maintain a rewall conguration to protect cardholder

data

2. Do not use vendor-supplied defaults for system passwords and

other security parameters

Protect Cardholder Data 3. Protect stored cardholder data

4. Encrypt transmission of cardholder data across open, public

networks

Maintain a Vulnerability

Management Program

5. Use and regularly update anti-virus software or programs

6. Develop and maintain secure systems and applications

Implement Strong Access

Control Measures

7. Restrict access to cardholder data by business need-to-know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test

Networks

10. Track and monitor all access to network resources and cardholder

data

11. Regularly test security systems and processes

Maintain an Information

Security Policy

12. Maintain a policy that addresses information security for

employees and contractors

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Tools for Assessing Compliance with PCI DSS

The PCI SSC sets the PCI DSS standard, but each card brand has its own program for compliance,

validation levels and enforcement. More information about compliance can be found at these links:

• 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

Visa Europe: • www.visaeurope.com/ais

Qualied Assessors. The Council manages programs that will help facilitate the assessment of

compliance with PCI DSS: Qualied Security Assessor (QSA) and Approved Scanning Vendor (ASV).

QSAs are approved by the Council to assess compliance with the PCI DSS. ASVs are approved by the

Council to validate adherence to the PCI DSS scan requirements by performing vulnerability scans of

Internet-facing environments of merchants and service providers. Additional details can be found on

our Web site at: www.pcisecuritystandards.org/qsa_asv/nd_one.shtml

Self-Assessment Questionnaire. The “SAQ” is a validation tool for organizations that are not

required to undergo an on-site assessment for PCI DSS compliance. Dierent SAQs are specied for

various business situations; more details can found on our Web site at:

www.pcisecuritystandards.org/saq/index.shtml. The organization’s acquiring nancial institution can

also determine if it should complete a SAQ.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Payment Application Data Security Standard

The PA-DSS is a standard for developers of payment applications. Its goal is to help development of

secure commercial payment applications that do not store prohibited data, and ensure that payment

applications support compliance with the PCI DSS. Merchants and service providers should ensure

that they are using Council-approved payment applications; check with your acquiring nancial

institution to understand requirements and associated timeframes for implementing approved

applications. PA-DSS has 14 requirements: For details and a list of approved Payment Applications,

see: www.pcisecuritystandards.org/security_standards/pa_dss.shtml

PIN Transaction (PTS) Security Requirements

These requirements, referred to as PCI PTS (formerly PCI PED), applies to companies which make

devices or components that accept or process personal identication numbers as a part of a PIN

based transaction and for other payment processing related activities. Recognized PTS laboratories

validate adherence to the PTS requirements. Financial institutions, processors, merchants and service

providers should ensure that they are using approved PTS devices or components. Non nancial

institutions should check with their acquiring nancial institution to understand requirements and

associated timeframes for compliance. The PTS requirements cover devices, including the physical and

logical security characteristics of their components, and device management. For details and a list of

approved PTS devices and components see:

www.pcisecuritystandards.org/security_standards/ped/index.shtml

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Security Controls

and Processes for PCI

DSS Requirements

Security Controls and Processes for

PCI DSS Requirements

The goal of the PCI Data Security Standard version 1.2 (PCI DSS) is to protect cardholder data that

is processed, stored or transmitted by merchants. The security controls and processes required by

PCI DSS are vital for protecting cardholder account data, including the PAN – the primary account

number printed on the front of a payment card. Merchants and any other service providers involved

with payment card processing must never store sensitive authentication data after authorization. This

includes sensitive data that is printed on a card, or stored on a card’s magnetic stripe or chip – and

personal identication numbers entered by the cardholder. This chapter presents the objectives of PCI

DSS and related 12 requirements.

CID

(American Express)

Expiration Date Magnetic Stripe

(data on tracks 1 & 2)

PAN

Chip

(data on magnetic

stripe image)

CAV2/CID/CVC2/CVV2

(Discover, JCB, MasterCard, Visa)

Types of Data on a Payment Card

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Build and Maintain a Secure Network

In the past, theft of nancial records required a criminal to physically enter an organization’s business

site. Now, many payment card transactions (such as debit in the U.S. and “chip and pin” in Europe)

use PIN entry devices and computers connected by networks. By using network security controls,

organizations can prevent criminals from virtually accessing payment system networks and stealing

cardholder data.

Requirement 1: Install and maintain a rewall and router conguration to protect

cardholder data

Firewalls are devices that control computer trac allowed into and out of an organization’s network,

and into sensitive areas within its internal network. Routers are hardware or software that connects

two or more networks.

1.1 Establish rewall and router conguration standards that formalize testing whenever

congurations change; that identify all connections to cardholder data (including wireless); that

use various technical settings for each implementation; and stipulate a review of conguration

rule sets at least every six months.

1.2 Build a rewall conguration that denies all trac from “untrusted” networks and hosts, except

for protocols necessary for the cardholder data environment.

1.3 Prohibit direct public access between the Internet and any system component in the cardholder

data environment.

1.4 Install personal rewall software on any mobile and/or employee-owned computers with direct

connectivity to the Internet that are used to access the organization’s network.

CONTROLS FOR

NETWORK SECURITY

Firewall

Device that controls the passage

of trac between networks and

within an internal network

Router

Hardware or software that connects

trac between two or more

networks

Illustration / Photo: Wikimedia Commons

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

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

security parameters

The easiest way for a hacker to access your internal network is to try default passwords or exploits

based on default system software settings in your payment card infrastructure. Far too often,

merchants do not change default passwords or settings upon deployment. This is akin to leaving your

store physically unlocked when you go home for the night. Default passwords and settings for most

network devices are widely known. This information, combined with hacker tools that show what

devices are on your network can make unauthorized entry a simple task – if you have failed to change

the defaults.

2.1 Always change vendor-supplied defaults before installing a system on the network. This includes

wireless devices that are connected to the cardholder data environment or are used to transmit

cardholder data.

2.2 Develop conguration standards for all system components that address all known security

vulnerabilities and are consistent with industry-accepted denitions.

2.3 Encrypt all non-console administrative access such as browser/Web-based management tools.

2.4 Shared hosting providers must protect each entity’s hosted environment and cardholder

data (details are in PCI DSS Appendix A: “Additional PCI DSS Requirements for Shared Hosting

Providers.”)

TYPICAL DEFAULT

PASSWORDS THAT MUST

BE CHANGED

[none]

[name of product / vendor]

1234 or 4321

access

admin

anonymous

database

guest

manager

pass

password

root

secret

sysadmin

user

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Protect Cardholder Data

Cardholder data refers to any information printed, processed, transmitted or stored in any form on a

payment card. Organizations accepting payment cards are expected to protect cardholder data and

to prevent their unauthorized use – whether the data is printed or stored locally, or transmitted over a

public network to a remote server or service provider.

Requirement 3: Protect stored cardholder data

In general, no cardholder data should ever be stored unless it’s necessary to meet the needs of the

business. Sensitive data on the magnetic stripe or chip must never be stored. If your organization

stores PAN, it is crucial to render it unreadable (see 3.4, and table below for guidelines).

3.1 Limit cardholder data storage and retention time to that required for business, legal, and/or

regulatory purposes, as documented in your data retention policy.

3.2 Do not store sensitive authentication data after authorization (even if it is encrypted). See

guidelines in table below.

3.3 Mask PAN when displayed; the rst six and last four digits are the maximum number of digits

you may display. Not applicable for authorized people with a legitimate business need to see

the full PAN. Does not supersede stricter requirements in place for displays of cardholder data

such as on a point-of-sale receipt.

3.4 Render PAN, at minimum, unreadable anywhere it is stored – including on portable digital

media, backup media, in logs, and data received from or stored by wireless networks.

Technology solutions for this requirement may include strong one-way hash functions,

truncation, index tokens, securely stored pads, or strong cryptography. (See PCI DSS Glossary for

denition of strong cryptography.)

ENCRYPTION PRIMER

Cryptography uses a mathematical

formula to render plaintext data

unreadable to people without

special knowledge (called a “key”).

Cryptography is applied to stored

data as well as data transmitted

over a network.

Encryption changes plaintext into

ciphertext.

Decryption changes ciphertext

back into plaintext.

Illustration: Wikimedia Commons

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

3.5 Protect cryptographic keys used for encryption of cardholder data from disclosure and misuse.

3.6 Fully document and implement all appropriate key management processes and procedures for

cryptographic keys used for encryption of cardholder data.

Guidelines for Cardholder Data Elements

Data Element Storage

Permitted

Protection

Required

PCI DSS

Req. 3.4

Cardholder Data

Primary Account Number (PAN) Yes Yes Yes

Cardholder Name1Yes Yes1No

Service Code1Yes Yes1No

Expiration Date1Yes Yes1No

Sensitive

Authentication

Data2

Full Magnetic Stripe Data3No N/A N/A

CAV2 / CVC2 / CVV2 / CID No N/A N/A

PIN / PIN Block No N/A N/A

1 These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS

requirements for general protection of the cardholder data environment. Additionally, other legislation (for example,

related to consumer personal data protection, privacy, identity theft, or data security) may require specic protection of

this data, or proper disclosure of a company’s practices if consumer-related personal data is being collected during the

course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.

2 Sensitive authentication data must not be stored after authorization (even if encrypted).

3 Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Cyber criminals may be able to intercept transmissions of cardholder data over open, public networks

so it is important to prevent their ability to view these data. Encryption is a technology used to render

transmitted data unreadable by any unauthorized person.

4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive

cardholder data during transmission over open, public networks (e.g. Internet, wireless

technologies, global systems for communications [GSM], general packet radio systems [GPRS]).

Ensure wireless networks transmitting cardholder data or connected to the cardholder data

environment use industry best practices (e.g., IEEE 802.11ix) to implement strong encryption

for authentication and transmission. For new wireless implementations, it is prohibited to

implement WEP after March 31, 2009. For current implementations, it is prohibited to use WEP

after June 30, 2010.

4.2 Never send unencrypted PANs by end user messaging technologies.

Maintain a Vulnerability Management Program

Vulnerability management is the process of systematically and continuously nding weaknesses in an

organization’s payment card infrastructure system. This includes security procedures, system design,

implementation, or internal controls that could be exploited to violate system security policy.

Requirement 5: Use and regularly update anti-virus software or programs

Many vulnerabilities and malicious viruses enter the network via employees’ e-mail and other online

activities. Anti-virus software must be used on all systems aected by malware to protect systems

from current and evolving malicious software threats.

VULNERABILITY

MANAGEMENT

Create policy governing security

controls according to industry

standard best practices (e.g., IEEE

802.11ix)

Regularly scan systems for

vulnerabilities

Create remediation schedule

based on risk and priority

Pre-test and deploy patches

Rescan to verify compliance

Update security software with

the most current signatures and

technology

Use only software or systems

that were securely developed by

industry standard best practices

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

5.1 Deploy anti-virus software on all systems aected by malicious software (particularly personal

computers and servers).

5.2 Ensure that all anti-virus mechanisms are current, actively running, and capable of generating

audit logs.

Requirement 6: Develop and maintain secure systems and applications

Security vulnerabilities in systems and applications may allow criminals to access PAN and other

cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security

patches, which perform a quick-repair job for a specic piece of programming code. All critical

systems must have the most recently released software patches to prevent exploitation. Organizations

should apply patches to less-critical systems as soon as possible, based on a risk-based vulnerability

management program. Secure coding practices for developing payments applications, change

control procedures and other secure software development practices should always be followed.

6.1 Ensure that all system components and software have the latest vendor-supplied security

patches installed. Deploy critical patches within a month of release.

6.2 Establish a process to identify newly discovered security vulnerabilities, such as by subscribing

to alert services, or using a vulnerability scanning service or software. Update the process to

address new vulnerability issues.

6.3 Develop software applications in accordance with PCI DSS based on industry best practices and

incorporate information security throughout the software development life cycle.

6.4 Follow change control procedures for all changes to system components.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

6.5 Develop all Web applications based on secure coding guidelines and review custom application

code to identify coding vulnerabilities.

6.6 Ensure that all public Web-facing applications are protected against known attacks with at least

annual reviews of code, and by installing a Web application rewall in front of public-facing Web

applications.

Implement Strong Access Control Measures

Access control allows merchants to permit or deny the use of physical or technical means to access

PAN and other cardholder data. Access must be granted on a business need-to-know basis. Physical

access control entails the use of locks or restricted access to paper-based cardholder records or system

hardware. Logical access control permits or denies use of PIN entry devices, a wireless network, PCs

and other devices. It also controls access to digital les containing cardholder data.

Requirement 7: Restrict access to cardholder data by business need-to-know

To ensure critical data can only be accessed by authorized personnel, systems and processes must be

in place to limit access based on need-to-know and according to job responsibilities. Need-to-know is

when access rights are granted to only the least amount of data and privileges needed to perform a job.

7.1 Limit access to system components and cardholder data to only those individuals whose job

requires such access.

7.2 Establish an access control system for systems components with multiple users that restricts

access based on a user’s need-to-know, and is set to “deny all” unless specically allowed.

RESTRICTING ACCESS

IS CRUCIAL!

Restrict Access to Cardholder Data

Environments employing access

controls such as RBAC (Role Based

Access Control)

Limit access to only those

individuals whose job requires such

access

Formalize an access control policy

that includes a list of who gets

access to specied cardholder data

Deny all access to anyone who is

not specically allowed to access

cardholder data

Photo: Wikimedia Commons

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Requirement 8: Assign a unique ID to each person with computer access

Assigning a unique identication (ID) to each person with access ensures that actions taken on critical

data and systems are performed by, and can be traced to, known and authorized users.

8.1 Assign all users a unique user name before allowing them to access system components or

cardholder data.

8.2 Employ at least one of these to authenticate all users: password or passphrase; or two-factor

authentication (e.g., token devices, smart cards, biometrics, public keys).

8.3 Implement two-factor authentication for remote access to the network by employees,

administrators, and third parties. Use technologies such as remote authentication and dial-

in service or terminal access controller access control system with tokens; or virtual private

network with individual certicates.

8.4 Render all passwords unreadable for all system components both in storage and during

transmission using strong cryptography based on approved standards.

8.5 Ensure proper user authentication and password management for non-consumer users and

administrators on all system components.

GIVE EVERY USER A

UNIQUE ID

Every user on the payment system

must have a unique ID. This allows

a business to trace every action to a

specic worker.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Requirement 9: Restrict physical access to cardholder data

Any physical access to data or systems that house cardholder data provides the opportunity for

persons to access and/or remove devices, data, systems or hardcopies, and should be appropriately

restricted.

9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the

cardholder data environment.

9.2 Develop procedures to help all personnel easily distinguish between employees and visitors,

especially in areas where cardholder data is accessible.

9.3 Ensure all visitors are authorized before entering areas where cardholder data is processed or

maintained; given a physical token that expires and that identies visitors as non-employees;

and are asked to surrender the physical token before leaving the facility or at the date of

expiration.

9.4 Use a visitor log to maintain a physical audit trail of visitor information and activity. Retain the

log for at least three months unless otherwise restricted by law.

9.5 Store media back-ups in a secure location, preferably o site.

9.6 Physically secure all paper and electronic media that contain cardholder data.

9.7 Maintain strict control over the internal or external distribution of any kind of media that

contains cardholder data.

9.8 Ensure that management approves any and all media containing cardholder data moved from a

secured area, especially when media is distributed to individuals.

PHYSICALLY SECURE THE

PAYMENT SYSTEM

Businesses must physically secure

or restrict access to printouts of

cardholder data, to media where

it is stored, and to devices used for

accessing or storing cardholder

data. It’s important to understand

that PCI is about protecting both

electronic data and paper receipts

as well.

Illustration: Wikimedia Commons

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

9.9 Maintain strict control over the storage and accessibility of media that contains cardholder data.

9.10 Destroy media containing cardholder data when it is no longer needed for business or legal

reasons.

Regularly Monitor and Test Networks

Physical and wireless networks are the glue connecting all endpoints and servers in the payment

infrastructure. Vulnerabilities in network devices and systems present opportunities for criminals to

gain unauthorized access to payment card applications and cardholder data. To prevent exploitation,

organizations must regularly monitor and test networks to nd and x vulnerabilities.

Requirement 10: Track and monitor all access to network resources and cardholder data

Logging mechanisms and the ability to track user activities are critical for eective forensics and

vulnerability management. The presence of logs in all environments allows thorough tracking and

analysis if something goes wrong. Determining the cause of a compromise is very dicult without

system activity logs.

10.1 Establish a process for linking all access to system components to each individual user –

especially access done with administrative privileges.

10.2 Implement automated audit trails for all system components for reconstructing these events:

all individual user accesses to cardholder data; all actions taken by any individual with root

or administrative privileges; access to all audit trails; invalid logical access attempts; use of

identication and authentication mechanisms; initialization of the audit logs; creation and

deletion of system-level objects.

MONITOR ALL ACTIVITY

Organizations must track and

monitor all access to cardholder

data and related network resources

– in stores, regional oces,

headquarters, and other remote

access.

Photo: Wikimedia Commons

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

10.3 Record audit trail entries for all system components for each event, including at a minimum: user

identication, type of event, date and time, success or failure indication, origination of event,

and identity or name of aected data, system component or resource.

10.4 Synchronize all critical system clocks and times.

10.5 Secure audit trails so they cannot be altered.

10.6 Review logs for all system components related to security functions at least daily.

10.7 Retain audit trail history for at least one year; at least three months of history must be

immediately available for analysis.

Requirement 11: Regularly test security systems and processes

Vulnerabilities are being discovered continually by malicious individuals and researchers, and

being introduced by new software. System components, processes, and custom software should be

tested frequently to ensure security is maintained over time. Testing of security controls is especially

important for any environmental changes such as deploying new software or changing system

congurations.

11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly, or

deploying a wireless IDS/IPS to identify all wireless devices in use.

11.2 Run internal and external network vulnerability scans at least quarterly and after any signicant

change in the network. ASVs are not required to perform internal scans.

11.3 Perform external and internal penetration testing at least once a year and after any signicant

infrastructure or application upgrade or modication, including network- and application-layer

penetration tests.

SEVERITY LEVELS

FOR VULNERABILITY

SCANNING

5 Urgent: Trojan horses; le read

and write exploit; remote command

execution

4 Critical: Potential Trojan horses;

le read exploit

3 High: Limited exploit of read;

directory browsing; DoS

2 Medium: Sensitive

conguration information can be

obtained by hackers

1 Low: Information can

be obtained by hackers on

conguration

“To be considered compliant, a

component must not contain

vulnerabilities assigned Level 3, 4,

or 5. To be considered compliant, all

components within the customer

infrastructure must be compliant.

The scan report must not include

any vulnerabilities that indicate

features or congurations that may

violate PCI DSS requirements.”

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

11.4 Use network intrusion detection systems and/or intrusion prevention systems to monitor all

trac in the cardholder data environment and alert personnel to suspected compromises. IDS/

IPS engines must be kept up to date.

11.5 Deploy le integrity monitoring software to alert personnel to unauthorized modication of

critical system les, conguration les or content les. Congure the software to perform critical

le comparisons at least weekly.

Maintain an Information Security Policy

A strong security policy sets the tone for security aecting an organization’s entire company, and it

informs employees of their expected duties related to security. All employees should be aware of the

sensitivity of cardholder data and their responsibilities for protecting it.

Requirement 12: Maintain a policy that addresses information security for employees

and contractors

12.1 Establish, publish, maintain, and disseminate a security policy that addresses all PCI DSS

requirements, includes an annual process for identifying vulnerabilities and formally assessing

risks, and includes a review at least once a year and when the environment changes.

12.2 Develop daily operational security procedures that are consistent with requirements in PCI DSS.

12.3 Develop usage policies for critical employee-facing technologies to dene their proper use for

all employees and contractors. These include remote access, wireless, removable electronic

media, laptops, handheld devices, email and Internet.

12.4 Ensure that the security policy and procedures clearly dene information security

responsibilities for all employees and contractors.

“PCI DSS represents the best

available framework to guide better

protection of cardholder data.

It also presents an opportunity

to leverage cardholder data

security achieved through PCI DSS

compliance for better protection of

other sensitive business data – and

to address compliance with other

standards and regulations.”

AberdeenGroup

IT Industry Analyst

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

12.5 Assign to an individual or team information security responsibilities dened by 12.5 subsections.

12.6 Implement a formal security awareness program to make all employees aware of the importance

of cardholder data security.

12.7 Screen employees prior to hire to minimize the risk of attacks from internal sources.

12.8 If cardholder data is shared with service providers, then require them to implement PCI DSS

policies and procedures for cardholder data security.

12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.

Compensating Controls for PCI Security

Compensating controls may be considered for most PCI DSS requirements when an entity cannot

meet a requirement explicitly as stated, due to legitimate technical or documented business

constraints, but has suciently mitigated the risk associated with the requirement through

implementation of compensating controls. In order for a compensating control to be considered

valid, it must be reviewed by a QSA. The eectiveness of a compensating control is dependent on the

specics of the environment in which the control is implemented, the surrounding security controls,

and the conguration of the control. Organizations should be aware that a particular compensating

control will not be eective in all environments. See the PCI DSS version 1.2, Appendices B and C for

details.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

How to Comply with PCI DSS

Merchants and organizations that store, process and/or transmit cardholder data must comply with

PCI DSS version 1.2. While the Council is responsible for managing the data security standards, each

card brand maintains its own separate compliance enforcement programs. Each card brand has

dened specic requirements for validation of compliance and reporting, such as provisions for self-

assessment versus using a Qualied Security Assessor.

Depending on an organization’s classication or risk level (determined by the individual card brands),

processes for validating compliance and reporting to acquiring nancial institutions usually follow

this track:

1. PCI DSS Scoping – determine what system components are governed by PCI DSS

2. Sampling – examine the compliance of a subset of system components in scope

3. Compensating Controls – QSA validates alternative control technologies/processes

4. Reporting – merchant/organization submits required documentation

5. Clarications – merchant/organization claries/updates report statements (if applicable)

upon bank request

How to Comply

With PCI DSS

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Specic questions about compliance validation levels should be directed to your acquiring nancial

institution. Only the acquiring nancial institution can assign a validation level to merchants. Links to

card brand compliance programs include:

• 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

Visa Europe: • www.visaeurope.com/ais

Choosing a Qualied Security Assessor

A Qualied Security Assessor (QSA) is a data security rm that has been trained and is certied by the

PCI Security Standards Council to perform on-site security assessments for verication of compliance

with PCI DSS. The QSA will:

• Verify all technical information given by merchant or service provider

• Use independent judgment to conrm the standard has been met

• Provide support and guidance during the compliance process

• Be onsite for the validation of the assessment or duration as required

• Review the work product that supports the PCI Requirements and Security Assessment Procedures

• Ensure adherence to the PCI Security Assessment Procedures

• Dene the scope of the assessment

• Select systems and system components where sampling is employed

• Evaluate compensating controls

• Produce the nal report

PREPARING FOR A PCI

DSS ASSESSMENT

Gather Documentation:

Security policies, change control,

network diagrams, PCI letters and

notications

Schedule Resources: Ensure

participation of a project manager

and key people from IT, security,

applications, human resources and

legal

Describe the Environment:

Organize information about the

cardholder data environment,

including cardholder data ow

and location of cardholder data

repositories

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

The QSA you select should have solid understanding of your business and have experience in

assessing the security of similar organizations. That knowledge helps the QSA to understand business

sector-specic nuances of securing cardholder data under PCI DSS. Also, look for a good t with your

company’s culture. The assessment will conclude whether you are compliant or not – but the QSA will

also work with your organization to understand how to achieve and maintain compliance. Many QSAs

also can provide additional security-related services such as ongoing vulnerability assessment and

remediation. A list of QSAs is available at www.pcisecuritystandards.org/qsa_asv/nd_one.shtml.

Choosing an Approved Scanning Vendor

An Approved Scanning Vendor (ASV) is a data security rm using a scanning solution to determine

whether or not the customer is compliant with the PCI DSS external vulnerability scanning

requirement. ASVs have been trained and are qualied by the PCI Security Standards Council to

perform network and systems scans as required by the PCI DSS. An ASV may use its own software

or an approved commercial or open source solution to validate compliance. ASV solutions must be

non-disruptive to customers’ systems and data – they must never cause a system reboot, or interfere

with or change domain name server (DNS) routing, switching, and address resolution. Root-kits or

other software should not be installed unless part of the solution and pre-approved by the customer.

Tests not permitted by the ASV solution include denial of service, buer overow, brute force attack

resulting in a password lockout, or excessive usage of available communication bandwidth.

An ASV scanning solution includes the scanning tool(s), the associated scanning report, and the

process for exchanging information between the scanning vendor and the customer. ASVs may

submit compliance reports to the acquiring institution on behalf of a merchant or service provider.

A list of ASVs is available at www.pcisecuritystandards.org/qsa_asv/nd_one.shtml.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Using the Self-Assessment Questionnaire

The “SAQ” is a self-validation tool for merchants and service providers who are not required to do

on-site assessments for PCI DSS compliance. The SAQ includes a series of yes-or-no questions for

compliance. If an answer is no, the organization must state the future remediation date and associated

actions. In order to align more closely with merchants and their compliance validation process, the

SAQ was revised and now allows for exibility based on the complexity of a particular merchant’s or

service provider’s business situation (see chart below). The SAQ validation type does not correlate to

the merchant classication or risk level.

Self-Assessment Questionnaires

SAQ Validation

Type Description SAQ

1 Card-Not-Present (e-commerce or MO/TO) merchants, all cardholder data

functions outsourced. This would never apply to face-to-face merchants.

2 Imprint-only merchants with no cardholder data storage. B

3 Standalone dial-up terminal merchants, no cardholder data storage. B

4 Merchants with payment application systems connected to the Internet, no

cardholder data storage.

5 All other merchants (not included in descriptions for SAQs A, B or C above), and

all service providers dened by a card brand as eligible to complete a SAQ.

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Web Resources

Reporting

Reports are the ocial mechanism by which merchants and other organizations verify compliance

with PCI DSS to their respective acquiring nancial institutions. Depending on card brand

requirements, merchants and service providers may need to submit a SAQ or annual attestations

of compliance for on-site assessments (see PCI DSS version 1.2, Appendices D and E for more

information). Quarterly submission of a report for network scanning may also be required. Finally,

individual card brands may require submission of other documentation; see their Web sites for more

information (URLs listed above).

Information Contained in PCI DSS Reports

• Summary of Findings (general statement, details of the security assessment)

• Business Information (contact, business description, processor relationships)

• Card Payment Infrastructure (network diagram, transaction ow diagram, POS products used,

wireless LANs and/or wireless POS terminals)

• External Relationships (list service providers with whom you share cardholder data, connections

to card payment companies, wholly owned entities (national and international) that require

compliance with PCI DSS

COMPLIANCE PROGRAM

Assess

Assess your network and IT

resources for vulnerabilities. You

should constantly monitor access

and usage of cardholder data. Log

data must be available for analysis

Remediate

You must x vulnerabilities that

threaten unauthorized access to

cardholder data

Report

Report compliance and present

evidence that data protection

controls are in place

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

Web Resources

PCI Security Standards Council Web site

www.pcisecuritystandards.org

Frequently Asked Questions (FAQ)

www.pcisecuritystandards.org/faq.htm

Membership Information

www.pcisecuritystandards.org/participation/join.shtml

Webinars

www.pcisecuritystandards.org/news_events/events.shtml

Training (for assessors)

QSAs: www.pcisecuritystandards.org/education/qsa_training.shtml

PA-DSS: www.pcisecuritystandards.org/education/pa-dss_training.shtml

PTS approved devices

PIN Transaction Security (PTS) Devices: www.pcisecuritystandards.org/security_standards/ped/pedapprovallist.html

Payment Applications: www.pcisecuritystandards.org/security_standards/pa_dss.shtml

PCI Data Security Standard version 1.2 (PCI DSS)

The Standard: www.pcisecuritystandards.org/tech/download_the_pci_dss.htm

Supporting Documents: www.pcisecuritystandards.org/security_standards/pci_dss_supporting_docs.shtml

Approved Assessors and Scanning Vendors: www.pcisecuritystandards.org/about/resources.shtml

Navigating the Standard: www.pcisecuritystandards.org/security_standards/pci_dss_supporting_docs.shtml

Self-Assessment Questionnaire: www.pcisecuritystandards.org/saq/index.shtml

Glossary: www.pcisecuritystandards.org/security_standards/pci_dss_supporting_docs.shtml

Approved QSAs: www.pcisecuritystandards.org/qsa_asv/nd_one.shtml

Approved ASVs: www.pcisecuritystandards.org/qsa_asv/nd_one.shtml

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

About the PCI

Security Standards

Council

About the PCI Security Standards Council

The PCI Security Standards Council (PCI SSC) is a global open body formed to develop, enhance,

disseminate and assist with the understanding of security standards for payment account security.

The Council maintains, evolves, and promotes the Payment Card Industry security standards. It also

provides critical tools needed for implementation of the standards such as assessment and scanning

guidelines, a self-assessment questionnaire, training and education, and product certication

programs.

The PCI SSC founding members, American Express, Discover Financial Services, JCB International,

MasterCard Worldwide, and Visa Inc., have agreed to incorporate the PCI Data Security Standard as

part of the technical requirement for each of their data security compliance programs. Each founding

member also recognizes the Qualied Security Assessors and Approved Scanning Vendors qualied

by the PCI SSC to assess compliance with the PCI DSS.

The PCI SSC’s founding member card brands share equally in the Council’s governance and

operations. Other industry stakeholders participate in reviewing proposed additions or modications

to the standards, including merchants, payment card issuing banks, processors, hardware and

software developers, and other vendors.

PCI SSC FOUNDERS

PARTICIPATING

ORGANIZATIONS

Merchants, Banks, Processors,

Hardware and Software Developers

and Point-of-Sale Vendors

This Guide provides supplemental information that does not replace or supersede PCI DSS version 1.2 documents.

PCI Data Security Standard

The PCI DSS version 1.2 is a set of comprehensive requirements for enhancing payment account data security. It represents common sense

steps that mirror security best practices. Learn more about its requirements, security controls and processes, and steps to assess compliance

inside this PCI Quick Reference Guide.

Goals PCI DSS Requirements

Build and Maintain a Secure Network 1. Install and maintain a rewall conguration to protect cardholder data

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

Protect Cardholder Data 3. Protect stored cardholder data

4. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management

Program

5. Use and regularly update anti-virus software or programs

6. Develop and maintain secure systems and applications

Implement Strong Access Control

Measures

7. Restrict access to cardholder data by business need-to-know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks 10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy 12. Maintain a policy that addresses information security for employees and contractors

Pci Ssc Quick Guide

pci_ssc_quick_guide

Navigation menu

Versions of this User Manual:

Views

Navigation