The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes.
The PCI Standard is mandated by the card brands and administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around cardholder data to reduce credit card fraud. Validation of compliance is performed annually, either by an external Qualified Security Assessor (QSA) or by a firm specific Internal Security Assessor that creates a Report on Compliance for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes.
Video Payment Card Industry Data Security Standard
History
Five different programs: Visa's Cardholder Information Security Program, MasterCard's Site Data Protection, American Express's Data Security Operating Policy, Discover's Information Security and Compliance, and the JCB's Data Security Program were started by card companies. The intentions of each 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 then formed and these companies aligned their individual policies to create the PCI DSS.
There have been a number of versions:
- 1.0 was released on December 15, 2004.
- 1.1 in September 2006 provide clarification and minor revisions.
- 1.2 was released on October 1, 2008. It enhanced clarity, improved flexibility, and addressed evolving risks and threats.
- 1.2.1 in August 2009 made minor corrections designed to create more clarity and consistency among the standards and supporting documents.
- 2.0 was released in October 2010.
- 3.0 was released in November 2013 and was active from January 1, 2014 to June 31, 2015.
- 3.1 was released in April 2015, and has been retired since October 31, 2016.
- 3.2 was released in April 2016.
Maps Payment Card Industry Data Security Standard
Requirements
The PCI Data Security Standard specifies twelve requirements for compliance, organized into six logically related groups called "control objectives."
Each version of PCI DSS has divided these twelve requirements into a number of sub-requirements differently, but the twelve high-level requirements have not changed since the inception of the standard.
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
- Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified
- Navigating the PCI DSS - Understanding the Intent of the Requirements
- Information Supplement: PCI DSS Wireless Guidelines
Validation Compliance
Qualified Security Assessor (QSA)
A Qualified Security Assessor is an individual bearing a certificate that has been provided by the PCI Security Standards Council. This certified person can audit merchants for Payment Card Industry Data Security Standard (PCI DSS) compliance.
Report on Compliance (ROC)
A Report on Compliance is a form that has to be filled by all level 1 merchants Visa merchants undergoing a PCI DSS (Payment Card Industry Data Security Standard) audit. The ROC form is used to verify that the merchant being audited is compliant with the PCI DSS standard.
Self-Assessment Questionnaire (SAQ)
The Self-Assessment Questionnaire is a set of Questionnaires documents that merchants are required to complete every year and submit to their transaction Bank.
Compliance versus validation of compliance
Although the PCI DSS must be implemented by all entities that process, store or transmit cardholder 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. Visa also offers an alternative program called the Technology Innovation Program (TIP) that allows qualified merchants to discontinue the annual PCI DSS validation assessment. These merchants are eligible if they are taking alternative precautions against counterfeit fraud such as the use of EMV or Point to Point Encryption.
Issuing banks are not required to go through PCI DSS validation although they still have to secure the sensitive data in a PCI DSS compliant manner. Acquiring banks are required to comply with PCI DSS as well as to have their compliance validated by means of an audit.
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.
Mandated compliance
Compliance with PCI DSS is not required by federal law in the United States. However, the laws of some U.S. states either refer to PCI DSS directly, or make equivalent provisions.
In 2007, Minnesota enacted a law prohibiting the retention of payment card data.
In 2009, Nevada incorporated the standard into state law, requiring compliance of merchants doing business in that state with the current PCI DSS, and shields compliant entities from liability.
In 2010, Washington also incorporated the standard into state law. Unlike Nevada's law, entities are not required to be compliant to PCI DSS, but compliant entities are shielded from liability in the event of a data breach.
Compliance and wireless LANs
In July 2009, the Payment Card Industry Security Standards Council published wireless guidelines 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.
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 stores, processes 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, three 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 LAN
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 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.
- Sectional 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.
PCI compliance in call centers
While the PCI DSS standards are very explicit about the requirements for the back end storage and access of CHD (Card Holder Data), 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 Website systems or call center agents. This is surprising, given the high threat potential for credit card and data compromise that call center pose.
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. 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.
To address some of these concerns, on 18 March 2011 the Payment Card Industry Security Standards Council issued a revised FAQ about call center recordings. The bottom line is that companies can no longer store digital recordings that include sensitive card data if those recordings can be queried.
Technology solutions can also 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. This protects the sensitive information, but can create an awkward customer interaction. Solutions such as own not automation allow the agent to capture 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 the keypad of their phone. Agent-assisted automation can stumble however if callers read back the digits as they enter them. DTMF tones are suppressed entirely or converted to monotones so the agent cannot recognize them and so that they cannot be recorded. Some secure payment platforms allows for the masking of the DTMF tones, but are still recorded as DTMF tones by the on-site or hosted call recorders. Traditionally the only way to suppress DTMF tones is to intercept the call at the trunk using sophisticated servers and call cards to do so. This way allows for the suppression or masking of the DTMF tones to the call recorder, as well as the agent.
As recently as June 2014, we saw the introduction of cloud-based telephony payment solutions hit the market, but still challenges remain with such deployments as calls need to be routed to the cloud platform before they can be executed onwards to the call center. This is done so the cloud server can intercept the call to control the DTMF tones for secure masking or clamping to both the agent and cloud call recorders. If going through the network cloud, no hardware or software needs to be installed in the organization itself, though cloud solutions remain logistic and integration challenging to both service providers and merchants.
The benefits of increasing the security around the collection of personally identifiable information goes beyond credit card to include helping merchants win due to
Controversies and criticisms
According to Stephen and Theodora "Cissy" McComb, owners of Cisero's Ristorante and Nightclub in Park City, Utah (which was fined for a breach that two forensics firms could not find evidence even occurred), "the PCI system is less a system for securing customer card data than a system for raking in profits for the card companies via fines and penalties. Visa and MasterCard impose fines on merchants even when there is no fraud loss at all, simply because the fines 'are profitable to them.'"
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."
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
Further, per PCI Council General Manager Bob Russo's response to the National Retail Federation: 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."
Compliance and compromises
According to 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." In 2008, a breach of Heartland Payment Systems, an organisation validated as compliant with PCI DSS, resulted in the compromising of one hundred million card numbers. Around this same time Hannaford Brothers and TJX Companies, also validated as PCI DSS compliant, were similarly breached as a result of the alleged coordinated efforts of Albert "Segvec" Gonzalez and two unnamed Russian hackers.
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. Though it could be that a breakdown in merchant and service provider compliance with the written standard was to blame for the breaches, Hannaford Brothers had received its PCI DSS compliance validation one day after it had been made aware of a two-month-long compromise of its internal systems. The failure of this to be identified by the assessor suggests that incompetent verification of compliance undermines the security of the standard.
Other 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, 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 over 80% of payment card compromises between 2005 and 2007 affected Level 4 merchants; they handle 32% of transactions.
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.
Industry best practice for PCI DSS compliance is to continually improve processes to ensure ongoing compliance, rather than treating compliance as a point in time project.
See
- Penetration test
- Vulnerability management
- Wireless LAN
- Wireless security
References
Books on PCI DSS
- A Practical Guide to the Payment Card Industry Data Security Standard (PCI DSS) (ISBN 9781604205855)
- PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance 4th edition (ISBN 9780128015797)
- PCI Compliance: The Definitive Guide (ISBN 9781439887400)
External links
- Official PCI Security Standards Council Site
- PCI SSC Data Security Standards Overview
- PCI Quick Reference Guide v3
- The PCI Compliance Report
- The Payment Security Report
Source of the article : Wikipedia
0 Comments