Payment Card Industry Data Security Standard 1

Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard (PCI DSS) is a worldwide information security standard
defined by the Payment Card Industry Security Standards Council. The standard was created to help payment card
industry organizations that process card payments prevent credit card fraud through increased controls around data
and its exposure to compromise. The standard applies to all organizations that hold, process, or exchange cardholder
information from any card branded with the logo of one of the card brands.
Validation of compliance can be performed either internally or externally, depending on the volume of card
transactions the organization is handling, but regardless of the size of the organization, compliance must be assessed
annually. Organizations handling large volumes of transactions must have their compliance assessed by an
independent assessor known as a Qualified Security Assessor (QSA), while companies handling smaller volumes
have the option of demonstrating compliance via a Self-Assessment Questionnaire (SAQ). In some regions these
SAQs still require signoff by a QSA for submission.
Enforcement of compliance is done by the bodies holding relationships with the in-scope organizations. Thus, for
organizations processing Visa or MasterCard transactions, compliance is enforced by the organization's acquirer,
while organizations handling American Express transactions will deal directly with American Express for the
purposes of compliance. In the case of third party suppliers such as hosting companies who have business
relationships with in-scope organizations, enforcement of compliance falls to the in-scope company, as neither the
acquirers nor the card brands will have appropriate contractual relationships in place to mandate compliance.
Non-compliant companies who maintain a relationship with one or more of the card brands, either directly or
through an acquirer, risk losing their ability to process credit card payments and being audited and/or fined.[1]

Requirements
The current version of the standard is V2.0 released on 26/10/2010. PCI DSS v2.0 must be adopted by all
organisations with payment card data by 1st January 2011, and from 1st January 2012 all assessments must be under
version 2.0 of the standard. PCI DSS Version 2.0 has two (2) new or Evolving Requirements out of 132 changes.
Remaining changes/enhancements falls under the category of Clarification or Additional guidelines. [2] Table below
summarizes the points from V1.2 01/10/2008[3] and specifies the 12 requirements for compliance, organized into six
logically related groups, which are called "control objectives."

Control Objectives PCI DSS Requirements

Build and Maintain a Secure Network 1. Install and maintain a firewall configuration 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 on all systems commonly affected by malware

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

Payment Card Industry Data Security Standard 2

Maintain an Information Security Policy 12. Maintain a policy that addresses information security

History
PCI DSS originally began as five different programs: Visa Card Information Security Program, MasterCard Site
Data Protection, American Express Data Security Operating Policy, Discover Information and Compliance, and the
JCB Data Security Program. Each company’s intentions were roughly similar: to create an additional level of
protection for card issuers by ensuring that merchants meet minimum levels of security when they store, process and
transmit cardholder data. The Payment Card Industry Security Standards Council (PCI SSC) was formed, and on 15
December 2004, these companies aligned their individual policies and released the Payment Card Industry Data
Security Standard (PCI DSS).
In September 2006, the PCI standard was updated to version 1.1 to provide clarification and minor revisions to
version 1.0.
Version 1.2 was released on October 1, 2008.[4] Version 1.1 "sunsetted" on December 31, 2008.[5] v1.2 did not
change requirements, only enhanced clarity, improved flexibility, and addressed evolving risks/threats. In August
2009 the PCI SSC announced [6] the move from version 1.2 to version 1.2.1 for the purpose of making minor
corrections designed to create more clarity and consistency among the standards and supporting documents.

Updates and supplemental information

The PCI SSC has released several supplemental pieces of information to clarify various requirements. These
documents include the following
• Information Supplement: Requirement 11.3 Penetration Testing[7]
• Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified[8]
• Navigating the PCI DSS - Understanding the Intent of the Requirements[9]
• Information Supplement: PCI DSS Wireless Guidelines[10]

Compliance and Voice Recording

Recent developments in financial data security standards handed down and ultimately enforced by credit card
network processors have turned a keen eye on the contact center. Call and transaction recording systems dutifully
storing the verbatim details of payment card transactions represent a potentially rich vein of illicit account
information for thieves, and the payment card industry has responded in clear terms. Storing payment card data, even
in encrypted form, is expressly forbidden by the Payment Card Industry Data Security Standard (PCI DSS). The
rules laid out by the world’s top five payment brands are simple, yet far-reaching. Virtually every merchant must be
able to show, through audit or self-certification, that they comply with fundamental requirements when processing
and /or storing sensitive credit card information. That includes card account numbers, expiration dates and security
codes. Databases, transaction histories, logs and trace files are all covered by this requirement— and that includes
audio recordings and agent screen playbacks. Considering the high-profile thefts of literally millions of payment card
profiles at a time in recent years, the concern is well-founded.
Payment Card Industry Data Security Standard 3

Compliance and Wireless LANs

In July 2009, the PCI Security Standards Council [11] published wireless guidelines[10] for PCI DSS recommending
the use of Wireless Intrusion Prevention System (WIPS) to automate wireless scanning for large organizations.
Wireless guidelines clearly define how wireless security applies to PCI DSS 1.2 compliance[12] .
These guidelines apply to the deployment of Wireless LAN (WLAN) in cardholder data environments, also known
as CDEs. A CDE is defined as a network environment that possesses or transmits credit card data.

Wireless LAN and CDE Classification

PCI DSS wireless guidelines classify CDEs into three scenarios depending on how wireless LANs are deployed.
• No Known WLAN AP inside or outside the CDE: The organization has not deployed any WLAN AP. In this
scenario, 3 minimum scanning requirements (Sections 11.1, 11.4 and 12.9) of the PCI DSS apply.
• Known WLAN AP outside the CDE: The organization has deployed WLAN APs outside the CDE. These
WLAN APs are segmented from the CDE by a firewall. There are no known WLAN APs inside the CDE. In this
scenario, Three minimum scanning requirements (Sections 11.1, 11.4 and 12.9) of the PCI DSS apply.
• Known WLAN AP inside the CDE: The organization has deployed WLAN APs inside the CDE. In this
scenario, three minimum scanning requirements (Sections 11.1, 11.4 and 12.9), as well as six secure deployment
requirements (Sections 2.1.1, 4.1.1, 9.1.3, 10.5.4, 10.6 and 12.3) of the PCI DSS apply.
Key sections of PCI DSS 1.2 that are relevant for wireless security are classified and defined below.

Secure Deployment Requirements for Wireless LANs

These secure deployment requirements apply to only those organizations that have a known WLAN AP inside the
CDE. The purpose of these requirements is to deploy WLAN APs with proper safeguards.
• Section 2.1.1 Change Defaults: Change default passwords, SSIDs on wireless devices. Enable WPA or WPA2
security.
• Section 4.1.1 802.11i Security: Set up APs in WPA or WPA2 mode with 802.1X authentication and AES
encryption. Use of WEP in CDE is not allowed after June 30, 2010.
• Section 9.1.3 Physical Security: Restrict physical access to known wireless devices.
• Section 10.5.4 Wireless Logs: Archive wireless access centrally using a WIPS for 1 year.
• Section 10.6 Log Review: Review wireless access logs daily.
• Section 12.3 Usage Policies: Develop usage policies to list all wireless devices regularly. Develop usage possible
for the use of wireless devices.

Minimum Scanning Requirements for Wireless LANs

These minimum scanning requirements apply to all organizations regardless of the type of wireless LAN deployment
in the CDE. The purpose of these requirements is to eliminate any rogue or unauthorized WLAN activity inside the
CDE.
• Section 11.1 Quarterly Wireless Scan: Scan all sites with CDEs whether or not they have known WLAN APs in
the CDE. Sampling of sites is not allowed. A WIPS is recommended for large organizations since it is not
possible to manually scan or conduct a walk-around wireless security audit[13] of all sites on a quarterly basis
• Section 11.4 Monitor Alerts: Enable automatic WIPS alerts to instantly notify personnel of rogue devices and
unauthorized wireless connections into the CDE.
• Section 12.9 Eliminate Threats: Prepare an incident response plan to monitor and respond to alerts from the
WIPS. Enable automatic containment mechanism on WIPS to block rogues and unauthorized wireless
connections.
Payment Card Industry Data Security Standard 4

Wireless Intrusion Prevention System (WIPS) Implementations

Wireless Intrusion Prevention Systems are a possible option for compliance with some PCI DSS requirements, and
can be implemented in either an internally hosted or externally hosted Software as a Service(SaaS) model.[14] [15]
The hosted implementation is offered in an on-demand, subscription-based SaaS model[16] . Hosted implementations
are said to be particularly cost-effective[17] for organizations looking to fulfill only the minimum scanning
requirements for PCI DSS compliance (AirMinder [18]).
The network implementation is an on-site deployment of WIPS within a private network. Such a deployment is
viable, but the significant costs have been thought to lead some companies to avoid WIPS deployments.[19]

Controversies and criticisms

It has been suggested by some IT security professionals that the PCI DSS does little more than provide a minimal
baseline for security.
"The fact is you can be PCI-compliant and still be insecure. Look at online application vulnerabilities. They're
arguably the fastest growing area of security, and for good reason — exposures in customer-facing applications
pose a real danger of a security breach." - Greg Reber[20]
Additionally, Michael Jones, CIO of Michaels' Stores, testifying before a U.S. Congress subcommittee, regarding the
PCI DSS, says "(...the PCI DSS requirements...) are very expensive to implement, confusing to comply with, and
ultimately subjective, both in their interpretation and in their enforcement. It is often stated that there are only twelve
“Requirements” for PCI compliance. In fact there are over 220 sub-requirements; some of which can place an
incredible burden on a retailer and many of which are subject to interpretation."[21]
In contrast, others have suggested that PCI DSS is a step toward making all businesses pay more attention to IT
security, even if minimum standards are not enough to completely eradicate security problems.
"Regulation--SOX, HIPAA, GLBA, the credit-card industry's PCI, the various disclosure laws, the European Data
Protection Act, whatever--has been the best stick the industry has found to beat companies over the head with. And it
works. Regulation forces companies to take security more seriously, and sells more products and services." - Bruce
Schneier[22]
Further, per PCI Council General Manager Bob Russo's response to the NRF: PCI is a structured "blend...[of]
specificity and high-level concepts" that allows "stakeholders the opportunity and flexibility to work with Qualified
Security Assessors (QSAs) to determine appropriate security controls within their environment that meet the intent
of the PCI standards." [23]

Compliance and Compromises

Per Visa, Chief Enterprise Risk Officer, Ellen Richey, "...no compromised entity has yet been found to be in
compliance with PCI DSS at the time of a breach."[24] However, it has nevertheless become a common
misconception that companies have had security breaches while also being PCI DSS compliant. Much of this
confusion is a result of the 2008 Heartland Payment Processing Systems breach, wherein more than one hundred
million card numbers were compromised.[25] Around this same time Hannaford Brothers[26] and TJX Companies
were similarly breached as a result of the alleged very same source of coordinated efforts of Albert "Segvec"
Gonzalez and two unnamed Russian hackers[27] .
Assessments examine the compliance of merchants and services providers with the PCI DSS at a specific point in
time and frequently utilize a sampling methodology to allow compliance to be demonstrated through representative
systems and processes. It is the responsibility of the merchant and service provider to achieve, demonstrate, and
maintain their compliance at all times both throughout the annual validation/assessment cycle and across all systems
and processes in their entirety.[28] Therefore, these frequently cited breaches and their pointed use as a tool for
criticism even to the point of noting that Hannaford Brothers had, in fact, received its PCI DSS compliance
Payment Card Industry Data Security Standard 5

validation one day after it had been made aware of a two-month long compromise of its internal systems[29] ; fail to
appropriately assign blame in their blasting of the standard itself as flawed as opposed to the more truthful
breakdown in merchant and service provider compliance with the written standard, albeit in this case having not
been identified by the assessor.
Other, more substantial, criticism lies in that compliance validation is required only for Level 1-3 merchants and may
be optional for Level 4 depending on the card brand and acquirer. Visa's compliance validation details for merchants
state that level 4 merchants compliance validation requirements are set by the acquirer[30] , Visa level 4 merchants
are "Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants
processing up to 1 million Visa transactions annually". At the same time 80% of payment card compromises since
2005 affected Level 4 merchants[31] .

Compliance as a Snapshot
The state of being PCI DSS compliant might appear to have some temporal persistence, at least from a merchant
point of view. In contrast, the PCI Standards Council General Manager Bob Russo has indicated that liabilities could
change depending on the state of a given organization at the point in time when an actual breach occurs.[32]

Costs
Similar to other industries, a secure state could be more costly to some organizations than accepting and managing
the risk of confidentiality breaches. However, many studies have shown that this cost is justifiable.[33]

Other PCI standards

The PCI Security Standards also include:
• PIN Entry Device (PED) Security Requirements
PCI PED applies to manufacturers who specify and implement device characteristics and management for personal
identification number (PIN) entry terminals used for payment card financial transactions. Merchants should use only
PIN entry devices that are tested and approved by the PCI SSC. Authorized devices are listed at: List of PCI
Approved PIN Entry Devices [34]
• 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 and third party agents to use payment applications that are validated
independently by a PA-QSA company and accepted for listing by the PCI SSC. Validated applications are listed at:
List of PA-DSS Validated Payment Applications [35]

References
[1] Sidel, Robin (2007-09-22). "In Data Leaks, Culprits Often Are Mom, Pop" (http:/ / online. wsj. com/ article/ SB119042666704635941.
html?mod=sphere_ts). The Wall Street Journal. .
[2] http:/ / grc360. net/ cms/ 2010/ pci-dss-ver-2-0-quick/
[3] PCI DSS - PCI Security Standards Council (https:/ / www. pcisecuritystandards. org/ security_standards/ pci_dss. shtml)
[4] PCI SECURITY STANDARDS COUNCIL RELEASES VERSION 1.2 OF PCI DATA SECURITY STANDARD (https:/ / www.
pcisecuritystandards. org/ pdfs/ pr_080930_PCIDSSv1-2. pdf)
[5] Supporting Documents PCI DSS (https:/ / www. pcisecuritystandards. org/ security_standards/ supporting_documents_home. shtml)
[6] https:/ / www. pcisecuritystandards. org/ pdfs/ statement_090810_minor_corrections_to_standards. pdf
[7] Information Supplement: Requirement 11.3 Penetration Testing (https:/ / www. pcisecuritystandards. org/ documents/
information_supplement_11. 3. pdf)
[8] Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified (https:/ / www. pcisecuritystandards. org/ pdfs/
infosupp_6_6_applicationfirewalls_codereviews. pdf)
Payment Card Industry Data Security Standard 6

[9] Navigating the PCI DSS - Understanding the Intent of the Requirements (https:/ / www. pcisecuritystandards. org/ pdfs/
pci_dss_saq_navigating_dss. pdf)
[10] "PCI DSS Wireless Guidelines" (https:/ / www. pcisecuritystandards. org/ pdfs/ PCI_DSS_Wireless_Guidelines. pdf). . Retrieved
2009-07-16.
[11] https:/ / www. pcisecuritystandards. org
[12] "Don’t Let Wireless Detour your PCI Compliance" (http:/ / www. airtightnetworks. com/ fileadmin/ pdf/ whitepaper/
PCI_Wireless_Whitepaper. pdf). . Retrieved 2009-07-22.
[13] "Walk Around Wireless Security Audits – The End Is Near" (http:/ / www. airtightnetworks. com/ fileadmin/ pdf/ whitepaper/
WP_WalkAroundWireless. pdf). . Retrieved 2009-07-22.
[14] "Webinar on Wireless Security as SaaS by Gartner Analyst John Pescatore" (http:/ / www. airtightnetworks. com/ fileadmin/
content_images/ news/ webinars/ SaaS/ player. html). gartner.com. . Retrieved 2009-04-24.
[15] "Saas offerings for wireless pci compliance" (http:/ / www. infosecurity-us. com/ view/ 9661/
comment-saas-offerings-for-wireless-pci-compliance/ ). . Retrieved 2010-05-25.
[16] "Security SaaS hits WLAN community" (http:/ / www. networkworld. com/ newsletters/ wireless/ 2008/ 040708wireless1. html).
networkworld.com. . Retrieved 2008-04-07.
[17] "New Low-Cost Wireless PCI Scanning Services; New Offerings Satisfy PCI DSS Requirements" (http:/ / newsblaze. com/ story/
2009072205011500038. mwir/ topstory. html). . Retrieved 2009-07-22.
[18] http:/ / www. icrewsecurity. com
[19] "Big-Time Wireless Security - As a Service" (http:/ / www. networkworld. com/ community/ node/ 26755). networkworld.com. . Retrieved
2008-04-08.
[20] "PCI compliance falls short of assuring website security" (http:/ / searchsoftwarequality. techtarget. com/ news/ column/
0,294698,sid92_gci1335662,00. html). . Retrieved 2009-02-15.
[21] Jones, Michael (2009-03-31). "TESTIMONY OF MICHAEL JONES BEFORE THE EMERGING THREATS, CYBERSECURITY, AND
SCIENCE AND TECHNOLOGY SUBCOMMITTEE" (http:/ / www. homeland. house. gov/ SiteDocuments/ 20090331142012-77196. pdf).
Congress of the United States. . Retrieved 2010-07-19.
[22] "Bruce Schneier reflects on a decade of security trends" (http:/ / searchsecurity. techtarget. com. au/ contents/
21998-Bruce-Schneier-reflects-on-a-decade-of-security-trends). . Retrieved 2009-02-15.
[23] Russo, Bob (2009-06-15). "Letter to NRF" (http:/ / www. pcisecuritystandards. org/ pdfs/ statement090615_letter_to_nrf. pdf). PCI Council.
. Retrieved 2010-10-19.
[24] Vijayan, Jaikumar (2009). "Visa: Post-breach criticism of PCI standard misplaced" (http:/ / www. cso. com. au/ article/ 296278/
visa_post-breach_criticism_pci_standard_misplaced). .
[25] "Heartland data breach sparks security concerns in payment industry" (http:/ / www. computerworld. com/ action/ article.
do?command=viewArticleBasic& articleId=9126608). .
[26] McGlasson, Linda (2008-04-04). "Hannaford Data Breach May Be Top of Iceberg" (http:/ / www. bankinfosecurity. com/ articles.
php?art_id=810). BankInfo Security. . Retrieved 2009-01-28.
[27] Goodin, Dan (2009). "TJX suspect indicted in Heartland, Hannaford breaches" (http:/ / www. theregister. co. uk/ 2009/ 08/ 17/
heartland_payment_suspect/ ). .
[28] Spier, Peter (2010-03-22). "The QSA's Perspective: PCI Compliance Risk Abounds" (http:/ / blogs. bankinfosecurity. com/ posts.
php?postID=492). BankInfo Security. . Retrieved 2010-10-19.
[29] Vijayan, Jaikumar (2009-01-04). "PCI security standard gets ripped at House hearing" (http:/ / www. computerworld. com/ action/ article.
do?command=viewArticleBasic& articleId=9130901& intsrc=news_ts_head). Computerworld Security. . Retrieved 2009-05-04.
[30] Visa Merchant levels http:/ / usa. visa. com/ merchants/ risk_management/ cisp_merchants. html
[31] Pastor, Adrian (2009). "A Pentester’s Guide to Credit Card Theft Techniques" (http:/ / 2009. confidence. org. pl/ materialy/ prezentacje/
adrian_pastor_confidence_2009. pdf). .
[32] "Q and A: Head of PCI council sees security standard as solid, despite breaches" (http:/ / www. computerworld. com/ action/ article.
do?command=viewArticleBasic& taxonomyName=Financial& articleId=9078059). . Retrieved 2009-02-15.
[33] "PCI Cost Analysis Report: A Justified Expense" (http:/ / www. solidcore. com/ assets/ PCI_Cost_Analysis. pdf). Solidcore Systems. .
[34] http:/ / www. pcisecuritystandards. org/ security_standards/ ped/ pedapprovallist. html
[35] https:/ / www. pcisecuritystandards. org/ security_standards/ vpa/ vpa_approval_list. html
Payment Card Industry Data Security Standard 7

Books on PCI DSS

• "PCI DSS Handbook"(ISBN 9780470260463)
• "PCI DSS: A Practical Guide to Implementation" (ISBN 9781849280235)
• "PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance" (ISBN
9781597494991)

Updates on PCI DSS v1.2

• Summary of Changes (https://www.pcisecuritystandards.org/pdfs/pci_dss_summary_of_changes_v1-2.pdf)
• Summary of Changes FAQ (https://www.pcisecuritystandards.org/pdfs/
pci_dss_summary_of_changes_faqs_v1-2.pdf)
• PCI DSS 1.2 Announcement, Oct. 1, 2008 (https://www.pcisecuritystandards.org/pdfs/
pr_080930_PCIDSSv1-2.pdf)

Updates on PCI DSS v2.0

• Summary of Changes (https://www.pcisecuritystandards.org/pdfs/summary_of_changes_highlights.pdf)
• PCI DSS 2.0 Announcement, Aug. 12, 2010 (https://www.pcisecuritystandards.org/pdfs/
pr_100810_summary_changes.pdf)

External links
• PCI DSS Standard (https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml)
• PCI Quick Reference Guide (https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf)
• Online PCI DSS checking tool(free) (http://checkpcidss.com/)
Article Sources and Contributors 8

Article Sources and Contributors

Payment Card Industry Data Security Standard  Source: http://en.wikipedia.org/w/index.php?oldid=404440980  Contributors: Abadger2k6, Akshaymathur, Alangh, AlephGamma, Andy
Dingley, Andybarratt, AntonChuvakin, Artgib, Arvindn, Beland, Bixgal, Bkell, Blackgorge, Bogey97, Capricorn42, Classof96, CliffC, Coachjpg, Danbriley, Debresser, Desanu, Digital fuel,
Discospinster, Djptechie, Doctorallan, Donalcampbell, Falcon8765, Flowanda, Frap, Fredhopper, Glatk, Hbrandon, Hga, Iain Cheyne, JJC1138, Jehnidiah, Jeltz, Jestep, Jimmyshaft, Jojo-schmitz,
Jonralton, JukoFF, Kashifsohail, Katana0182, Kehrbykid, KelleyCook, Knguyeniii, Kravietz, Lazydaisy, Leeatcookerly, Midnight Madness, Mikaey, Mindmatrix, MrDolomite, MrOllie,
Neilhenry, OnebadGTR, Pcimonkey, Poweron, Pradameinhoff, Quadrature, R'n'B, Random name, Raoulhira, Reconscout94, Rich Farmbrough, Ronz, Scottdimmick, Securityphreaks, Sfoak,
Sh00tr, Sliman89, Stagalj, Steve Baner-Mann, SteveLoughran, Stevehughes, Stymiee, TastyPoutine, Tdurden77007, Technopat, TerraFrost, Tessian, Tnxman307, Vmp2009, William Avery,
Yhabibzai, 206 anonymous edits

License
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/