Vulnerabilities / Threats
8/12/2010
05:07 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

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="http://blog.nubridges.com/nublog/2010/08/pcidss-padss-maturing-but-more-to-do.html" 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 DarkReading.com. 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
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-4440
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 generates weak non-tty passwords, which makes it easier for context-dependent attackers to guess the password via a brute-force attack.

CVE-2013-4442
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 uses weak pseudo generated numbers when /dev/urandom is unavailable, which makes it easier for context-dependent attackers to guess the numbers.

CVE-2013-7401
Published: 2014-12-19
The parse_request function in request.c in c-icap 0.2.x allows remote attackers to cause a denial of service (crash) via a URI without a " " or "?" character in an ICAP request, as demonstrated by use of the OPTIONS method.

CVE-2014-2026
Published: 2014-12-19
Cross-site scripting (XSS) vulnerability in the search functionality in United Planet Intrexx Professional before 5.2 Online Update 0905 and 6.x before 6.0 Online Update 10 allows remote attackers to inject arbitrary web script or HTML via the request parameter.

CVE-2014-2716
Published: 2014-12-19
Ekahau B4 staff badge tag 5.7 with firmware 1.4.52, Real-Time Location System (RTLS) Controller 6.0.5-FINAL, and Activator 3 reuses the RC4 cipher stream, which makes it easier for remote attackers to obtain plaintext messages via an XOR operation on two ciphertexts.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.