Evan Schuman's StorefrontBacktalk

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 seems logical to expect that the effort a retailer expends validating its PCI compliance should lessen with each passing year. To some extent that logic holds, but only to a relatively small extent. Why is this the case? Why don’t assessments get a whole lot easier each year? Why is last year’s compensating control no longer acceptable? And why are practices assessed as compliant last year not compliant now?

The answer to all these questions is simple: Things change. And those changes are typically caused by one of three things: PCI DSS itself changes; the threat environment changes as the bad guys adopt new tactics; or, most often, the retailer’s own payment environment and, therefore, its PCI scope, changes. Think about it. How many times does a year go by in which retailers don’t expand their network, add new servers and expand the number of end users?

Let’s start with changes to the PCI DSS itself. The move from version 1.1 to 1.2 had some significant changes. Requirement 6.6, which sought either an application review or Web application firewall in front of public-facing Web applications, became mandatory. The PCI Council also clarified external vulnerability scanning and penetration testing requirements, and it set a sunset date for WEP as a means to secure wireless networks.

Although many changes are “evolutionary,” they will require additional work. For example, Requirement 6.2 tells merchants and processors not only to identify new security vulnerabilities but also to “assign a risk ranking” to each one. Then merchants need to reflect these self-developed risk rankings in both their applications (Requirement 6.5.2) and their internal vulnerability scans (11.2).

Another change affects merchants with in-scope wireless networks protected with WPA, which “is no longer considered strong encryption on its own.” These merchants need to either upgrade to WPA2 (and hope that remains adequate) or re-think their use of wireless.

The PCI Council can change the Self-Assessment Questionnaires (SAQs). It may introduce new ones that can make a merchant’s validation easier (e.g., SAQ C-VT). The Council can also make changes that increase a merchant’s validation work and cost. Many merchants face this situation as they grapple with the new SAQ C requirements. Of course, there’s also the looming mobile payment changes.

Because PCI is now on a three-year lifecycle, merchants, processors and assessors can anticipate a fair degree of stability, at least through 2013 (sans those imminent mobile payment changes). The same cannot be said about the bad guys, who are devising new attacks constantly. As such, merchants need to reflect these emerging risks in their risk analyses (Requirement 12.1.2).

This year, for example, most merchants will need to update their risk analyses to reflect the risk of their security vendor or service provider being compromised. I doubt many merchants (or processors) included this contingency in their risk analyses, but after the RSA experience, they now will need to do so. While there, make sure incident response plans are up to date with changes in national (or international) and state breach notification legislation.

I can’t tell you how often I look at an incident response plan that has out-of-date contacts, people who have moved to a different part of the company (or even left), and incorrect or missing phone numbers. It seems these details rarely get updated during the course of the year (at least judging by the dust that sometimes needs to be blown off the binder), so it can be like starting over each year.