The Payment Card Industry Security Standards Council today released version 3.0 of PCI DSS and the Payment Application Data Security Standard, marking not only the beginning of a new three-year compliance cycle for merchants and payment processors, but also upping the ante on payment card data security with nearly a dozen new compliance requirements.
The Payment Card Industry Data Security Standard (PCI DSS), widely seen as one of the information security industry's most important baselines for ensuring the security of sensitive data, was created in 2004 to help merchants protect payment card data wherever and however it's stored, processed or transmitted.
Updated for the first time since 2010, PCI 3.0 features changes across all of its 12 requirements, including notable modifications to the rules on penetration testing, service provider responsibilities, password and credential requirements, malware detection and change management, among others (see right sidebar). An additional change, which affects all requirements, is the relocation of operational procedure and security policy components, Requirements 12.1.1 and 12.2 in PCI DSS version 2.0, into each separate requirement.
PCI 3.0: More rigorous penetration testing
Perhaps the changes that have fostered the most industry discussion are Requirements 11.3 and 11.4, which, in addition to the existing mandated quarterly assessments by an approved scanning vendor, now necessitate that organizations implement a penetration testing methodology to verify the cardholder data environment (CDE) is properly segmented from other networks.
PCI DSS 3.0: New and updated requirements
Req. 5.1.2 - Evaluate evolving malware threats for any systems not considered to be commonly affected
Req. 8.2.3 - Combined minimum password complexity and strength requirements into one, and increased flexibility for alternatives
Req. 8.5.1 - For service providers with remote access to customer premises, use unique authentication credentials for each customer*
Req. 8.6 - Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) these must be linked to an individual account and ensure only the intended user can gain access
Req. 9.3 - Control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination
Req. 9.9 - Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution*
Req. 11.3 – 4 - Implement a methodology for penetration testing; if segmentation is used to isolate the cardholder data environment from other networks, perform penetration tests to verify that the segmentation methods are operational and effective*
Req. 11.5.1 - Implement a process to respond to any alerts generated by the change-detection mechanism
Req. 12.8.5 - Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity
Req. 12.9 - For service providers, provide the written, agreement/acknowledgment to their customers as specified at requirement 12.8.2*
*Denotes a future-dated requirement that is a best practice until 15 July 2015.
Troy Leach, the Payment Card Industry Security Standards Council's (PCI SSC) chief technology officer, called it one of 3.0's more significant changes.
"In the past, we've seen compromises where organizations thought they were doing the right thing, adequately segmenting off what they deemed to be their CDEs, only to find [the security controls were] never tested appropriately," Leach said.
Patrick Harbauer, senior security consultant and PCI DSS expert with Chicago-based mobile and cloud security services firm Neohapsis Inc., said the more rigorous penetration testing requirements will likely lead merchants to implement a common pen testing standard, such as NIST SP 800-115, and that Qualified Security Assessors (QSAs) will have to take a much closer look at pen testing processes to ensure organizations are following the new guidelines.
"The change takes the ambiguity out of what [has] been going on in the past with penetration testing," Harbauer said, "and having a formalized process will have the effect of more remediations that need to be done, especially around the requirement to validate your segmentation is actually effective."
Julie Conroy, research director with Boston-based Aite Group, said merchants may not welcome the new pen testing requirements because they will "without question" increase merchants' PCI DSS compliance costs, but they're still important and needed.
"With the threat environment moving so fast, the onus is being placed on the merchants to ensure that when new products are released, they aren't inadvertently opening up backdoors into their environments," Conroy said. "It reflects that the responsibility is on those holding that confidential data to deploy adequate controls."
PCI 3.0: Inspecting PoS systems regularly
Requirement 9.9 now mandates that merchants protect point-of-sale (PoS) devices that capture payment card data directly from customer cards. In most cases, this will require regular on-site inspection of PoS systems to identify tampering and device substitution.
Bob Russo, general manager of the PCI SSC, said card skimming at merchant locations remains a high-risk attack, especially during the holiday season when retail activity picks up.
"Merchants should keep an inventory of what payment devices they have in their stores and conduct periodic inspections," Russo said. "Know what the device is supposed to look like, and periodically look at the device to see if there are any more wires coming out of it than originally planned. If a device looks like it [has] been tampered with, say something."
Greg Rosenberg, security engineer with Chicago-based compliance and security services firm Trustwave Inc., said while many merchants have already implemented PoS inspections as a PCI DSS best practice, retailers commonly struggle with securing the systems. The solution, he said, is to implement broader security awareness training for employees who work at the point of sale so they can not only identify a security threat involving the PoS itself, but can also identify generally suspicious behavior in the retail environment.
PCI 3.0: Avoiding service provider non-compliance
Another high-profile change in the new PCI DSS involves service providers. Requirement 8.5.1 requires providers to use unique authentication credentials when remotely accessing customer environments, and Requirement 12.9 clarifies that providers must give customers written documentation stating they are responsible for the cardholder data in their possession. Providers that handle day-to-day IT functions for merchants may also be affected by several other changes, most notably Requirement 11.5.1, which requires a process be implemented to respond to change-detection alerts in the cardholder data environment.
Special coverage: PCI DSS 3.0
Highlights from SearchSecurity's special report on the debut of PCI DSS 3.0:
PCI DSS 3.0 is a step forward, says one QSA, but there are uncertainties that may cause problems during PCI assessments.
Compliance expert Mike Chapple reviews PCI's successes and failures in its nine-year history.
SearchSecurity's exclusive Visual timeline: This history of PCI DSS examines the key events in the history of PCI DSS, from Y2K to PCI DSS 3.0.
Harbauer said the changes in PCI DSS 3.0 will require service providers to develop more detailed contractual language, particularly in regard to responsibility for specific PCI DSS compliance functions.
"I think the SSC is really putting service providers on the hook with PCI DSS 3.0," he said. "Previously there wasn't much language around service provider roles and responsibilities, and that's much more of a focus now."
A key objective of the service provider-related changes, Harbauer said, is to avoid surprises during the compliance process. He said not long ago he worked with a client using a third-party service provider for disaster recovery services, and while the customer thought the provider had its compliance attestation in order, it soon discovered the provider hadn't been fully validated by a QSA.
"We had to validate all the services that the third party was providing -- building and patching servers, running the AV, logging and monitoring," Harbauer said. "It literally doubled our customer's cost of compliance this past year."
PCI DSS 3.0: Criticism includes cost of compliance
One of the areas the PCI DSS frequently receives criticism on is in the high cost of compliance, with costs often surpassing hundreds of thousands of dollars annually for the largest merchants. Despite such high costs, breaches are still a common occurrence, even among organizations that have made the investment.
PCI SSC General Manager Bob Russo and CTO Troy Leach discuss the final version of PCI DSS 3.0, explain why certain changes were made, and foreshadow what's next for the Security Standards Council.
Conroy said PCI 3.0 undoubtedly will increase compliance costs further, but believes those who complain about the cost of PCI compliance may not fully understand the purpose of the mandate.
"There's a reason those annual and quarterly assessments are not called audits; it's impossible for a QSA to spend 48 hours in a business and fully examine every element of its infrastructure," Conroy said. "PCI DSS 3.0 iterates forward the concept of getting organizations to embrace data security at a fundamental level."
Rosenberg said he was disappointed that PCI DSS 3.0 failed to offer new guidance on risk assessments or any guidance at all on mobile payments. He said the standard should encourage organizations to assess their risk profiles and take additional actions as needed, such as conducting more frequent risk assessments or using more stringent password requirements.
In the same vein, Rosenberg said the standard continues to ignore both mobile payment processing and mobile device security, leaving merchants who use or support mobile payment technology virtually on their own to determine how to maintain PCI compliance. He believes the five major card brands are reluctant to put security constraints on mobile technology for fear of losing out on the growing revenue expected from mobile payments in the coming years.
"I think that's a missed opportunity" for the card brands, Rosenberg said, because security could be a differentiator against upstart competitors.
Even making the tenants of PCI DSS "business as usual" for organizations, the SSC's central theme with the release of PCI 3.0, is seen by some as a near-impossible challenge. Kurt Hagerman, director of information security with Richardson, Texas-based cloud hosting firm Firehost Inc., said many firms lack the information security maturity to make this happen.
"The vast majority of companies that come under the DSS umbrella are small and midsized businesses that might not have an IT department, much less an information security staff," Hagerman said. "The new changes to PCI DSS add a burden to most merchants that lack the time, expertise or personnel to see compliance as a daily, business-as-usual component of how they run their organizations."
Because the changes may catch some organizations off-guard, Harbauer said organizations should strongly consider bringing in trusted QSAs 6 to 9 months prior to their first PCI 3.0 assessment in order to give themselves time to do a gap assessment and address any shortcomings that are found.
PCI DSS 3.0: Last-minute changes and future initiatives
Despite earlier reports that the final version of the standard would offer significant deviations from the preview released in August, PCI 3.0 was released with only a few unexpected changes.
Leach said Requirement 9.9 was adjusted to clarify best practices for inspecting PoS devices for tampering and for emphasizing the locations in which attacks commonly take place. He also said a proposal to specifically address memory scraping, an attack involving the collection of cardholder data as it resides in volatile memory, changed from a requirement to a best practice based on community feedback.
Most of the new requirements will go into effect as of Jan. 1, 2014, and organizations must transition to PCI DSS 3.0 by the start of 2015. However, a number of changes, including those involving penetration testing and service providers, will not go into effect until July 15, 2015, giving merchants an extra six-plus months to adapt.
"The reception that the 3.0 standard has received at the community meetings has been overwhelmingly positive," Russo said. "People are pleased with what they're seeing … most of which is making it a little more user-friendly, making it a bit more flexible, and focusing on security as a shared responsibility."