PCI 2.0 Changes: The Good, The Bad And The Hashing

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

IT and business executives reading PCI DSS Version 2.0—slated to be released Thursday (Oct. 28)—will notice that it focuses on clarifications and additional guidance instead of providing a lot of new requirements. There are, however, two "Evolving Requirements" that, together with several clarifications, may impact how many retailers approach PCI compliance. Rather than taking the entire document apart piece by piece, we'll highlight five items that caught this QSA's attention, along with the implications of each for retail IT executives.

The short version: You can expect to spend more time at the beginning of your assessment, and some of the approaches and technologies you may recently have put in place may no longer make the grade.

Last April, StorefrontBacktalk took a look at what to expect from PCI DSS Version 2.0. The new version includes most of the items identified in that column&38212;including the minor prediction that the new version would be called 2.0.

The first thing readers will notice when they open PCI Version 2.0 is an expanded section defining PCI scope. Version 2 requires merchants and processors to identify explicitly all the locations and flows of cardholder data annually before they begin their assessment. The specific instructions are to make sure that no data has leaked outside your defined cardholder data environment and, if you find any, that you either eliminate the data or include it in your assessment.

The PCI Council stopped short of requiring merchants to use an automated data discovery tool to find all their cardholder data, even though security-conscious retailers and processors use such tools already. From the Council's perspective, not mandating a specific technology makes sense, I guess, but the group might have mandated the procedure without naming a specific tool. From a risk perspective, it is difficult to see how a merchant can be certain that cardholder data hasn't leaked into other systems or employee laptops by just asking users whether they store cardholder data or not. As a point of interest, the Council is instructing QSAs to report how the PCI scope was validated in the Report on Compliance (ROC).

In my perfect world, I would like to see the PCI Council mandate the use of automated discovery tools. I am convinced that such a move would eliminate at least some data compromises by removing hidden or unknown stores of cardholder data. But I will take this increased emphasis on thoughtful scoping before the assessment as validation of what I previously referred to as "PCI Requirement 0."

Although there are no completely new requirements, two closely related "Evolving Requirements" will have an impact on retailers and processors who develop payment applications. Interestingly, each is considered a "best practice" until June 30, 2012, after which both will be required. Where Requirement 6.2 used to say, "Establish a process to identify newly discovered security vulnerabilities," the PCI Council has appended "and assign a risk ranking to newly discovered security vulnerabilities."Where before retailers and processors could review, say, CERT bulletins, they now need to consider their own rankings and take actions based on their own risk assessment. The guidance says, "At minimum, the most critical, highest risk vulnerabilities should be ranked as High."

The other related "Evolving Requirement" is a new 6.5.6. This sub-requirement is part of a revamped Requirement 6.5 that in PCI Version 2 addresses all software applications not just Web-facing ones, as was the case previously. The new requirement says you develop applications to avoid or prevent those high-ranking vulnerabilities you identified in Requirement 6.2.

The risk in each of these quasi-requirements is that some merchants and processors may be tempted to identify and rank only those vulnerabilities that will cause their servers to catch fire as "high" and rank everything else "low." I really hope I'm wrong on that one.

Sometimes it isn't what Version 2.0 says that is interesting, but what it doesn't say. For example, Requirement 2.1.1, which addresses wireless security and was re-subdivided, no longer contains any reference to WPA or WPA2. Where it used to say, "Firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks (for example, WPA/WPA2)," it now says just to "Verify firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks." The reference to any specific encryption technology has been removed.

The reason for eliminating the reference to WPA in particular is in the Summary of Changes document: "[The PCI Council] removed reference to WPA, as this is no longer considered strong encryption on its own." The previous version eliminated WEP as an option for protecting wireless networks and, because WPA has been regarded as inadequate for some time, it looks like WPA has bitten the dust, too. The two messages for retailers with in-scope wireless networks seem to be either implement WPA2 fast or give some serious thought to whether wireless networks are appropriate for transmitting cardholder data. You may want to include wireless in your risk analysis (Requirement 12.1.2), too.

Requirement 3.4 provides new guidance on hashing. The text of the new requirement states that if hashed and truncated versions of the same PAN are present in the cardholder data environment, "additional controls should be in place to ensure that the hashed and truncated versions cannot be correlated to reconstruct the original PAN." Unfortunately, there is not much information on what those controls should be.

The reason for this revised requirement is that if the bad guys get both a truncated PAN and the hashed version of that same PAN, fairly trivial techniques can be used to reconstruct the PAN. Depending on how you're using these pieces of data, it may be a significant challenge to separate them and add sufficient "additional controls." I can only hope that the Council will release some formal guidance on what these controls should be.The clarification to Requirement 11.1 is a sensible one that may make compliance easier for retailers with a large number of locations. That requirement also dealt with wireless security and formerly instructed retailers to "test for the presence of unauthorized wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS." The requirement now states, "methods that may be used in the process include, but are not limited to, wireless network scans, physical site inspections, network access control (NAC) or wireless IDS/IPS." That means you don't necessarily have to carry a wireless analyzer. A little physical observation and war-walking might do the trick. Don't let this be a throwaway; rogue wireless devices are a very real threat, and you should take these (at least) quarterly inspections very seriously.

Going beyond the changes to the actual PCI DSS, the Council announced a number of initiatives to improve communication with merchants and processors. These initiatives include a new Web site (with special sections for small merchants), a new "Navigating the PCI DSS Document" and revised Self-Assessment Questionnaires (SAQs). There may even be a new SAQ or two, if I understood some of the hints at the Community Meeting.

At the risk of being picky, there is one area that I wish had been addressed and one statement in the PCI DSS that I believe is incorrect and needs to be changed.

The area that didn't get addressed is Requirement 12.8. It seems uniquely unfair that retailers need to get their service providers to acknowledge in writing their responsibility for the security of the retailers' data in their control, but there is no corresponding requirement for the service providers to actually give that acknowledgement. I pointed this out during one of the sessions with the PCI Council and the group noted it thoughtfully, so maybe we will see this reflected in an updated version.

The change that didn't get made is the definition of the scope of external vulnerability scans. Both the previous and new documents state that "Scan[s] must cover all externally accessible (Internet-facing) IP addresses in existence at the entity." I had hoped the PCI Council might update it to specify only IP addresses in the cardholder data environment. This specific issue was raised at last year's Community Meeting, and the response was that scanning only applied to the cardholder data environment. Given that a lot of retailers and processors can have thousands of IP addresses, I would have thought this definition might be corrected. At least, I hope it's a correction!

There are many other clarifications, some small and some large. Which items caught your attention? What changes did you want to see? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].