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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-10-30
Unspecified vulnerability in the kernel in HP HP-UX B.11.31 allows local users to cause a denial of service via unknown vectors.

Published: 2014-10-29
The Internet Service Monitor (ISM) agent in IBM Tivoli Composite Application Manager (ITCAM) for Transactions 7.1 and 7.2 before IF28, 7.3 before IF30, and 7.4 before IF18 does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof s...

Published: 2014-10-29
Buffer overflow in the date_from_ISO8601 function in the mkgmtime implementation in libxmlrpc/xmlrpc.c in the XMLRPC extension in PHP before 5.4.34, 5.5.x before 5.5.18, and 5.6.x before 5.6.2 allows remote attackers to cause a denial of service (application crash) via (1) a crafted first argument t...

Published: 2014-10-29
Integer overflow in the object_custom function in ext/standard/var_unserializer.c in PHP before 5.4.34, 5.5.x before 5.5.18, and 5.6.x before 5.6.2 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via an argument to the unserialize function ...

Published: 2014-10-29
The exif_ifd_make_value function in exif.c in the EXIF extension in PHP before 5.4.34, 5.5.x before 5.5.18, and 5.6.x before 5.6.2 operates on floating-point arrays incorrectly, which allows remote attackers to cause a denial of service (heap memory corruption and application crash) or possibly exec...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.