Version 2.0 of Payment Card Industry Data Security Standards (PCI DSS) went into effect on Jan. 1. But thanks to some recent procedural changes, validation against the previous version (1.2.1) will be allowed until Dec. 31. After Jan. 1, 2012, all assessments must be under version 2.0.
These global DSS standards — which apply to all companies that accept credit-card payments (or handle, store or transmit cardholder data) — have been around since December 2004. Noncompliance can result in penalties ranging from a fine from your acquiring bank to, in extreme cases, loss of your merchant account.
DSS and other PCI standards are developed and managed by the PCI Security Standards Council (SSC). The Council comprises five global payment brands: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa. The individual payment brands, not the Council, enforce compliance and determine noncompliance penalties.
Most merchants have already been through a few PCI DSS assessment cycles and have successful reports on compliance under their belts. But there have been a few recent updates.
Biggest change: new three-year cycle
The Council describes PCI DSS 2.0 as consisting of “clarifications” rather than significant changes. The most important change is that the PCI DSS implementation, feedback, review and revision process has been extended from a two-year to a three-year cycle.
The change gives merchants more time and more opportunities to submit feedback, as well as more “merchant-friendly” implementation start dates and longer sunset periods for existing standards.
SSC also moved the other two types of PCI Standards to the same three-year implementation cycle. These are the Payment Application Data Security Standard/PA-DSS (for payment applications developers) and the PIN Transaction Security (PTS) Requirements (for makers of devices/components that accept or process PIN numbers).
The chart above right, summarizes the new cycle and phases, which should result in better implementation procedures. These are some of the PCI DSS 2.0 changes.
-
The revised PCI DSS introduction clarifies that requirements 3.3 and 3.4, addressing protection of stored cardholder data, apply only to the primary account number.
The introduction language now aligns with the language in the PTS Secure Reading and Exchange of Data module. The introduction and relevant requirements have been revised to take into account server “virtualization.”
The definition and assessment of systems components now include and further define virtual components. For instance, requirement 2.2.1 now further defines the “one primary function per server” as it relates to virtual components. These changes are important. Make sure your IT team/service provider adapt and document procedures relating to virtual components as necessary.
-
The “scope of assessment” section now clarifies that all locations and flows of cardholder data must be identified and documented to prove that the report on compliance has been properly scoped prior to an assessment. For merchants, determining where cardholder data resides could require using data recovery tools, data leakage prevention measures and/or setting up a taskforce dedicated to this process.
-
Requirement 1 (“Install and maintain a firewall configuration to protect cardholder data”) now clarifies the secure boundaries between the Internet and the cardholder data environment.
-
Requirement 3.2 (“Do not store sensitive authentication data after authorization, even if encrypted”) now makes it clearer that card issuers do need to retain “Sensitive Authentication Data” (track data, CAV2/CVC2/CVV2/CID, and the PIN). In the past, misinformed qualified security assessors (QSAs) sometimes told card issuers that they were not allowed to keep this information, even though issuers are a special case.
-
Requirement 3.6 (“Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data”) now provides more flexibility in key-change processes. It also clarifies requirements for key retirement and replacement. (Virtually all security certifications require that the merchant understands the encryption techniques and key management processes being employed.)
-
Requirement 6.2, which requires having a process to identify newly discovered security vulnerabilities, now also requires ranking these according to their risk levels (and provides guidance on how to do this). This enables addressing highest risk vulnerabilities first, as opposed to just patching everything within a 30-day time period.
-
Requirement 6.5, requiring that applications/software development processes are based on secure coding guidelines and designed to prevent common coding vulnerabilities, has been rewritten. To eliminate discrepancies in secure coding procedures and requirements for internal and web-facing applications, a previously separate requirement (6.3.1) has been incorporated into 6.5, which now also specifies additional allowable security standards.
-
As previously written, the language of 12.3.10 in essence required prohibiting all personnel who access cardholder data through remote-access technologies from copying, moving and storing the data onto local hard drives and removable electronic media. Now the important words “unless explicitly authorized for a defined business need” have been added.
This means merchants now have the flexibility to limit these blanket prohibitions to personnel who are not authorized; and it provides authorized personnel with explicit guidance or justifications as to when they may copy, move or store cardholder data being accessed remotely.
The SSC’s guidance stresses that authorized personnel are responsible for ensuring that cardholder data in their possession is handled in accordance with all PCI DSS requirements, because that remote personnel’s environment is now considered a part of the organization’s cardholder environment.
The PA-DSS does not apply to payment applications developed by merchants in-house (those are covered by PCI DSS). But merchants and service providers using payment applications developed by third parties are responsible for ensuring that these applications meet PA-DSS requirements and are SSC-approved.
So be aware of some key PA-DSS changes:
-
This standard now extends to hardware terminals — a major omission in the previous language.
-
Requirement 4.4 (“Payment application must facilitate centralized logging”) has been aligned with, and eliminates, requirement 10.5.3.
-
Requirements 10 and 11, dealing with remote access and remote updating, have been revised and consolidated in a new #11: “Facilitate secure remote access to payment applications.”
Next steps, issues to be addressed
SSC’s revised guidance on data encryption formally recognizes that point-to-point encryption (P2PE) may simplify PCI DSS compliance. It reduces the scope of the cardholder data environment and eliminates the need to maintain PCI DSS compliance for specific systems (putting them “out of scope”). But it also says that the Council will release a further set of criteria in 2011 to help merchants validate the effectiveness of P2PE solutions.
Other front-burner 2011 Council topics include global inter-operation standards, encryption, tokenization and mobile payments, according to SSC general manager Bob Russo. And many hope that the Council will provide further guidance on virtualization in the near future.
The SSC has sanctioned “Special Interest Groups” to examine these topics and produce guidance documentation for consideration by the Council in the future. Any interested party is welcome to participate in the SIGs. (For more information, email [email protected].)
When it comes to customer data-protection practices, adhering to PCI DSS 2.0 is the bare minimum. PCI regulations apply only to credit-card data. Merchants should also make sure they’re protecting the many other types of customer data they store from hackers inside and outside the company.
The best approach is to enact and scrupulously maintain a carefully considered, layered approach to security. One big benefit of doing this is that PCI compliance becomes much easier to achieve and maintain.
Ernie Schell ([email protected]) is director of the consultancy Marketing Systems Analysis in Ventnor, NJ.
IMPLEMENTATION RESOURCES AVAILABLE
SSC general manager Bob Russo has stressed that the Council is committed to providing all stakeholders with the support and resources they need to implement version 2.0 of the standards. The Council’s new website (https://www.pcisecuritystandards.org) provides a wealth of documents and resources, including a summary of changes from PCI DSS 1.2.1 to 2.0.
The Council also reworked and reduced the number of questions in its self-assessment questionnaire to simplify compliance efforts for smaller merchants, and launched a microsite with information specifically geared to small merchants (https://www.pcisecuritstandards.org/smb).