Payment Card Industry Data Security Standard

From Wikipedia, the free encyclopedia

The Payment Card Industry Data Security Standard is a worldwide information security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC). The standard was created to help 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 which hold, process, or pass cardholder information from any card branded with the logo of one of the card brands.

The standard is maintained by the Payment Card Industry Security Standards Council, which maintains both the PCI DSS and a number of other standards, such as the Payment Card Industry PIN Entry Device security requirements (PCI PED) and the Payment Application Data Security Standard (PA-DSS).

Validation of compliance can be performed either internally or externally, depending on the volume of card transactions the organisation is handling, but regardless of the size of the organisation, compliance must be assessed annually. Organisations 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 self-certification 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 organisations. Thus, for organisations processing Visa or Mastercard transactions, compliance is enforced by the organisation's acquirer, while organisations 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 organisations, 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]

Contents 1 Requirements 2 History 3 Updates and supplemental information 4 Compliance and Wireless LANs 5 Controversies and criticisms 6 Other PCI standards 7 References 8 Updates on PCI DSS v1.2 9 External links

[edit] Requirements

The current version of the standard (1.2)^[2] specifies 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

[edit] 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 customers 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.

PCI is one of multiple data security standards that have emerged over the past decade; BS7799, ISF Standards, Basel II, Gramm-Leach-Bliley Act (GLBA), Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley Act of 2002,

Version 1.2 was released on October 1, 2008.^[3] Version 1.1 "sunsetted" on December 31, 2008.^[4] v1.2 did not change requirements, only enhanced clarity, improved flexibility, and addressed evolving risks/threats.

[edit] 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^[5]
• Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified^[6]
• Navigating the PCI SSC - Understanding the Intent of the Requirements^[7]

[edit] Compliance and Wireless LANs

The PCI DSS recognizes wireless LANs as public networks and automatically assumes they are exposed to vulnerabilities and threats. PCI DSS also provides two specific security guidelines to prevent breaches coming in from wireless networks used in any environments containing credit card data. They are:

• Firewall segmentation between wireless networks and the point of sale networks or any network that comes in contact with credit card information.
• Use of wireless analyzers (a.k.a. Wireless Intrusion Detection System) to detect any unauthorized wireless devices and attacks

[edit] Controversies and criticisms

It is 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^[8]

Still others believe 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, GLB, 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^[9]

Companies have had security breaches while being registered as PCI DSS compliant. In 2008 one of the largest payment service providers, Heartland Payment Processing Systems, suffered a data breach which has been estimated by some as exceeding one hundred million card numbers.^[10] Other notables include the Hannaford Brothers and the Okemo Mountain Resort, each of which was PCI compliant. It has been noted that this may be an indication of the limits of a snapshot certification; the evaluation cannot ensure that the target company will maintain the good practices seen in an audit.^[11] This explanation does not, however seem to explain the compromise of merchants such as Hannaford Bros Co, which received its PCI DSS compliance certification one day after it had been made aware of a two-month long compromise of its internal systems.^[12]

The definition of compliant has also been open to interpretation, especially regarding how temporary such a declaration might be. Declaring a company compliant appears to have some temporal persistence,^{[citation needed]} yet the PCI Standards Council General Manager Bob Russo indicates that liabilities could change depending on the state of a given organization at the point in time when an actual breach occurs.^[13]

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

[edit] 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

• 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

[edit] References

[edit] Updates on PCI DSS v1.2

• Summary of Changes
• Summary of Changes FAQ
• PCI DSS 1.2 Announcement, Oct. 1, 2008

[edit] External links

• PCI DSS Standard
• PCI Quick Reference Guide