Vulnerabilities / Threats
05:07 PM
Connect Directly

A Peek At The Next Version Of PCI

Clarifications but no big changes -- and that's what concerns some security experts

The next version of the Payment Card Industry Data Security Standard (PCI DSS) won't feature any major changes, giving merchants a little breathing room in their efforts to meet the requirements for securing cardholder data. Instead, the specification, as well as its companion Payment Application Data Security Standard (PA-DSS), will feature more clarification than change.

The PCI Standards Council today released a summary of what's to come in late October, when the next major releases of PCI DSS and PA-DSS arrive, versions 2.0. Bob Russo, general manager of the PCI Standards Council, says the idea is to highlight what's coming up in the next version so merchants will have time to prepare. "We're trying to take as much pressure off of merchants, giving them as much time as possible to look at what's out there," Russo says. And part of that is clarifying the scope of the specs, he says.

Among the clarifications to PCI: The DSS now reinforces the need for merchants to use a "discovery methodology" to find cardholder data in their networks; the PA-DSS now includes centralized logging; and organizations will be able to consider specific risks apply to them when assessing and prioritizing vulnerabilities.

Russo says the clarifications are all based on input from the PCI community and don't represent any big changes to the specifications. "If you are compliant with 1.2, you shouldn't find it difficult to comply with 2.0," he says.

The changes and clarifications are more about the administration of the PCI compliance process, notes Joshua Corman, research director for the enterprise security practice at The 451 Group. He says the PCI Standards Council is grappling with striking a balance between its goal as a standard for securing cardholder data with the realities of implementation by the merchant and vendor communities. "This gives more lead time to the folks being audited, but none of this is about doing a better job of preventing breaches. It's more about the administration of the [PCI] process," Corman says.

Corman says PCI version 2.0 needs more teeth. "The standard in its current 1.2 and 2.0 forms is not sufficient to prevent attack from a determined adversary," he says.

Gary Palgon, lead chair for the PCI SSC Scoping Special Interest Group's tokenization working group, said in href="" target="new">a blog post today that the card brands themselves may be hindering PCI's success. "One critical area hindering industrywide standards adoption lies with the card brands themselves, as some continue to issue their own, independent standards for PCI compliance instead of conforming exclusively to PCI SSC-derived standards," he wrote. "Having a universal, singular standards set is paramount for easing compliancy requirements and reducing complexity for merchants and service providers alike."

Palgon says that while the new PCI changes clarify many of the PCI requirements, more specific guidance is needed for emerging technologies, such as encryption and tokenization -- both of which are due to arrive with the new spec this fall. "Overall, the industry is heading in the right direction, as the soon-to-be-released 2.0 versions of PCI DSS and PA-DSS demonstrate, but a more cooperative, aggressive approach is required for ensuring enterprise security standards in a timely manner," blogged Palgon, who is also vice president of product management at nuBridges, a tokenization vendor.

Meanwhile, the PCI Council's Russo says PCI DSS now reinforces the need for having a "scoping exercise" to find bundled cardholder data. "We're not endorsing any discovery tools. But before you bring in a QSA, you really need to use some kind of methodology to find where cardholder data is on the network," he says. "Before, we hadn't really talked about using any of these methodologies. We just said you should know where your data is. We are now encouraging people to reach out using one of these discovery methods."

The PA-DSS is also now more closely aligned with the PCI DSS, he says. The spec adds a requirement for payment applications to support centralized logging, which is part of PCI DSS, he notes. "Centralized logging is really important to us," Russo says.

Risk tolerance is now being encouraged in the PCI DSS: "We made it more of a risk-based approach so merchants can make decisions on their own on a vulnerability that might show up -- if their risk tolerance for a vuln is very low, then they can work in conjunction with the QSA" they don't necessarily have to address it if it's a low-risk problem, he says.

Another clarification addresses PCI DSS 3.3 and 3.4, which require that payment application passwords be made unreadable (encrypted) while being transmitted and stored. The clarification notes that this applies only to the primary account number (PAN).

The full description of changes and clarifications to PCI DSS 2.0 and PA-DSS 2.0 is here (PDF). The PCI Standards Council will hold meetings in Orlando and Barcelona prior to publishing the final standard on Oct. 28, where the community can discuss the proposed changes.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is Executive Editor at She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-07-06
Cross-site scripting (XSS) vulnerability in the template preview function in Foreman before 1.6.1 allows remote attackers to inject arbitrary web script or HTML via a crafted provisioning template.

Published: 2015-07-06
The Hospira LifeCare PCA Infusion System before 7.0 does not validate network traffic associated with sending a (1) drug library, (2) software update, or (3) configuration change, which allows remote attackers to modify settings or medication data via packets on the (a) TELNET, (b) HTTP, (c) HTTPS, ...

Published: 2015-07-06
Open redirect vulnerability in the Language Switcher Dropdown module 7.x-1.x before 7.x-1.4 for Drupal allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in a block.

Published: 2015-07-06
Multiple cross-site scripting (XSS) vulnerabilities in the Tournament module 7.x-1.x before 7.x-1.2 for Drupal allow remote authenticated users with certain permissions to inject arbitrary web script or HTML via an (1) account username, a (2) node title, or a (3) team entity title.

Published: 2015-07-06
Cross-site scripting (XSS) vulnerability in the Node Field module 7.x-2.x before 7.x-2.45 for Drupal allows remote authenticated users with certain permissions to inject arbitrary web script or HTML via unspecified vectors involving internal fields.

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report