Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards.

Defined by the Payment Card Industry Security Standards Council, the standard was created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually — by an external Qualified Security Assessor (QSA) for organisations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes.^[1]

Requirements

The current version of the standard is version 2.0, released on 26 October 2010. PCI DSS version 2.0 must be adopted by all organisations with payment card data by 1 January 2011, and from 1 January 2012 all assessments must be against version 2.0 of the standard. PCI DSS version 2.0 has two new or evolving requirements out of 132 changes. The remaining changes and enhancements fall under the categories of clarification or additional guidelines.^[2] The table below summarizes the differing points from version 1.2 of 1 October 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
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 versus validation of compliance

Although PCI DSS requirements must be implemented by all entities that process, store or transmit account data, formal validation of PCI DSS compliance is not mandatory for all entities. Currently both Visa and Mastercard require Merchants and Service Providers to be validated according to the PCI DSS. Issuing and acquiring banks are not required to go through PCI DSS validation. [In the event of a security breach, any compromised entity which was not PCI DSS compliant at the time of breach will be subject to additional card scheme penalties, such as fines.]

Compliance and wireless LANs

In July 2009, the Payment Card Industry Security Standards Council published wireless guidelines^[10] for PCI DSS recommending the use of Wireless Intrusion Prevention System (WIPS) to automate wireless scanning for large organisations. Wireless guidelines clearly define how wireless security applies to PCI DSS 1.2 compliance.^[11]

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^[12].

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 organisation 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 organisation 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 organisation 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 organisations 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 organisations 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 organisations 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.

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^{[citation needed]} for organisations looking to fulfill only the minimum scanning requirements for PCI DSS compliance.

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.^[17]

PCI Compliance in Call Centers

While the PCI DSS standards are very explicit about the requirements for the back end storage and access of PII (personally identifiable information), the Payment Card Industry Security Standards Council has said very little about the collection of that information on the front end, whether through websites, Interactive Voice Response systems or call center agents. This is surprising, given the high threat potential for credit card fraud and data compromise that call centers pose.^[18]

In a call center, customers read their credit card information, CVV codes, and expiration dates to call center agents. There are few controls which prevent the agent from skimming (credit card fraud) this information with a recording device or a computer or physical note pad. Moreover, almost all call centers deploy some kind of call recording software, which is capturing and storing all of this sensitive consumer data. These recordings are accessible by a host of call center personnel, are often unencrypted, and generally do not fall under the PCI DSS standards outlined here.^[19] Home-based telephone agents pose an additional level of challenges, requiring the company to secure the channel from the home-based agent through the call center hub to the retailer applications.^[20]

To address some of these concerns, on January 22, 2010 the Payment Card Industry Security Standards Council issued a revised FAQ about call center recordings.^[21] The bottom line is that companies can no longer store digital recordings that include CVV information if those recordings can be queried.

Though the council has not yet issued any requirements, technology solutions can completely prevent skimming (credit card fraud) by agents. At the point in the transaction where the agent needs to collect the credit card information, the call can be transferred to an Interactive Voice Response system.^[22] This protects the sensitive information, but can create an awkward customer interaction. Solutions such as Agent-assisted Automation allow the agent to "collect" the credit card information without ever seeing or hearing it. The agent remains on the phone and customers enter their credit card information directly into the Customer Relationship Management software using their phones. The DTMF tones are converted to monotones so the agent cannot recognize them and so that they cannot be recorded.^[23] The benefits of increasing the security around the collection of personally identifiable information goes beyond credit card fraud to include helping merchants win chargebacks due to friendly fraud.^[24]

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^[25]

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."^[26]

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^[27]

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." ^[28]

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."^[29] 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.^[30] Around this same time Hannaford Brothers^[31] 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.^[32]

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.^[33] 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 validation one day after it had been made aware of a two-month long compromise of its internal systems;^[34] 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,^[35] 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.^[36]

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.^{[citation needed]} In contrast, the PCI Standards Council General Manager Bob Russo has indicated that liabilities could change depending on the state of a given organisation at the point in time when an actual breach occurs.^[37]

Costs

Similar to other industries, a secure state could be more costly to some organisations than accepting and managing the risk of confidentiality breaches^{[citation needed]}. However, many studies have shown that this cost is justifiable.^[38]

See also

• Penetration test
• Vulnerability management
• Wireless Intrusion Prevention System
• Wireless LAN
• Wireless security

References

1. ^ Sidel, Robin (2007-09-22). "In Data Leaks, Culprits Often Are Mom, Pop". The Wall Street Journal. http://online.wsj.com/article/SB119042666704635941.html?mod=sphere_ts. 
2. ^ http://grc360.net/cms/2010/pci-dss-ver-2-0-quick/
3. ^ PCI DSS - PCI Security Standards Council
4. ^ PCI SECURITY STANDARDS COUNCIL RELEASES VERSION 1.2 OF PCI DATA SECURITY STANDARD
5. ^ Supporting Documents PCI DSS
6. ^ https://www.pcisecuritystandards.org/pdfs/statement_090810_minor_corrections_to_standards.pdf
7. ^ Information Supplement: Requirement 11.3 Penetration Testing
8. ^ Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified
9. ^ Navigating the PCI DSS - Understanding the Intent of the Requirements
10. ^ ^{a b} "PCI DSS Wireless Guidelines". https://www.pcisecuritystandards.org/pdfs/PCI_DSS_Wireless_Guidelines.pdf. Retrieved 2009-07-16. 
11. ^ "Don’t Let Wireless Detour your PCI Compliance". http://www.airtightnetworks.com/fileadmin/pdf/whitepaper/PCI_Wireless_Whitepaper.pdf. Retrieved 2009-07-22. 
12. ^ Card Industry (PCI) Data Security Standard Glossary, Abbreviations and Acronyms
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". gartner.com. http://www.airtightnetworks.com/fileadmin/content_images/news/webinars/SaaS/player.html. 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". networkworld.com. http://www.networkworld.com/newsletters/wireless/2008/040708wireless1.html. Retrieved 2008-04-07. 
17. ^ "Big-Time Wireless Security - As a Service". networkworld.com. http://www.networkworld.com/community/node/26755. Retrieved 2008-04-08. 
18. ^ "Overseas credit card scam exposed". bbc.co.uk.com. March 19, 2009. http://news.bbc.co.uk/2/hi/uk_news/7953401.stm. 
19. ^ "PCI Compliance in the Call Center a Headache for Many". searchcrm.com. http://searchcrm.techtarget.com/news/2240031378/PCI-compliance-in-the-call-center-a-headache-for-many. Retrieved 2011-01-28. 
20. ^ "PCI Compliance: What it Means to the Call Center Industry". tmcnet.com. http://callcenterinfo.tmcnet.com/analysis/articles/20732-pci-compliance-what-it-means-the-call-center.htm. Retrieved 2008-02-13. 
21. ^ "Call Center FAQ Significantly Changes". pciguru. http://pciguru.wordpress.com/2010/01/25/call-center-faq-significantly-changes/. Retrieved 2010-01-25. 
22. ^ "Restructuring the Contact Center for PCI Compliance". tmcnet.com. http://callcenterinfo.tmcnet.com/analysis/articles/45010-restructuring-contact-center-pci-compliance.htm. Retrieved 2008-11-10. 
23. ^ "PCI Compliance with CallGuard". elitetele.com. http://www.elitetele.com/PCI-Compliance/. 
24. ^ Adsit, Dennis (February 21, 2011). "Error-proofing strategies for managing call center fraud". isixsigma.com. http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1854&Itemid=1&Itemid=1. 
25. ^ "PCI compliance falls short of assuring website security". http://searchsoftwarequality.techtarget.com/news/column/0,294698,sid92_gci1335662,00.html. Retrieved 2009-02-15. 
26. ^ Jones, Michael (2009-03-31). "TESTIMONY OF MICHAEL JONES BEFORE THE EMERGING THREATS, CYBERSECURITY, AND SCIENCE AND TECHNOLOGY SUBCOMMITTEE". Congress of the United States. http://www.homeland.house.gov/SiteDocuments/20090331142012-77196.pdf. Retrieved 2010-07-19. 
27. ^ "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. ^{[dead link]}
28. ^ Russo, Bob (2009-06-15). "Letter to NRF". PCI Council. http://www.pcisecuritystandards.org/pdfs/statement090615_letter_to_nrf.pdf. Retrieved 2010-10-19. 
29. ^ 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. 
30. ^ "Heartland data breach sparks security concerns in payment industry". http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9126608. 
31. ^ McGlasson, Linda (2008-04-04). "Hannaford Data Breach May Be Top of Iceberg". BankInfo Security. http://www.bankinfosecurity.com/articles.php?art_id=810. Retrieved 2009-01-28. 
32. ^ Goodin, Dan (2009). "TJX suspect indicted in Heartland, Hannaford breaches". http://www.theregister.co.uk/2009/08/17/heartland_payment_suspect/. 
33. ^ Spier, Peter (2010-03-22). "The QSA's Perspective: PCI Compliance Risk Abounds". BankInfo Security. http://blogs.bankinfosecurity.com/posts.php?postID=492. Retrieved 2010-10-19. 
34. ^ Vijayan, Jaikumar (2009-01-04). "PCI security standard gets ripped at House hearing". Computerworld Security. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9130901&intsrc=news_ts_head. Retrieved 2009-05-04. 
35. ^ Visa Merchant levels http://usa.visa.com/merchants/risk_management/cisp_merchants.html
36. ^ Pastor, Adrian (2009). "A Pentester’s Guide to Credit Card Theft Techniques". http://2009.confidence.org.pl/materialy/prezentacje/adrian_pastor_confidence_2009.pdf. 
37. ^ "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. 
38. ^ "PCI Cost Analysis Report: A Justified Expense". Solidcore Systems. http://www.solidcore.com/assets/PCI_Cost_Analysis.pdf. 

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
• Summary of Changes FAQ
• PCI DSS 1.2 Announcement, Oct. 1, 2008

Updates on PCI DSS v2.0

• Summary of Changes
• PCI DSS 2.0 Announcement, Aug. 12, 2010
• PCI DSS Virtualisation Guidelines, June 2011

External links

• PCI DSS Standard
• PCI Quick Reference Guide