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.It can be like starting over each year. On a related note, software applications can go out of date, too. Applications that were PA-DSS validated years ago may be past their PCI "sell by" date, meaning they are no longer acceptable for new implementations. Even existing implementations of the older versions may be so old they are no longer supported, and these must be replaced or upgraded. The same holds true for system software.
Compensating controls that were acceptable in the past might not be so today. For example, recent experience may cause a retailer's acquirer (or QSA) to reassess last year's compensating control. Sometimes the PCI Council will issue additional guidance based on its assessment of recent attack vectors. Alternatively, with some technology costs coming down, the business justification for a compensating control may no longer exist. Either situation can mean reassessing the compensating control or even abandoning it altogether.
The biggest source of change, though, is likely to be in the merchant's or processor's own environment. In the year between assessments, retailers have likely added staff, user accounts and stores, and/or changed the organization. Communications networks evolve and expand, and new routers and firewalls are added. Each of these events means the assessor (internal or external) needs to revalidate the scope of the assessment, in addition to updating internal documents and procedures. All of this takes time.
I should point out that changing the PCI compliance team will also impact the time and effort it takes to validate compliance. Having a new QSA or internal PCI leader can put a merchant back at square one as far as the assessment goes. If the QSA is new, he or she has to learn the merchant's environment, and this person may have different opinions than his or her predecessor on what is or is not compliant. Similarly, if the internal PCI leader is new, that person may lack the PCI knowledge, internal operational experience and/or organizational clout to get the evidence needed to validate compliance more efficiently than in the previous year.
A number of PCI requirements need attention throughout the course of the year—for example, six-month firewall rule reviews, quarterly internal and external vulnerability scans, installing security patches, updating antivirus software and daily log reviews. If a merchant has changed its internal PCI coordinator, documenting all of these activities will take as much time and effort this year as it took last year. This assumes all the activities actually took place, and the merchant and assessor don't have to scramble to develop compensating controls for things like missed scans or security awareness training.
In my mind, the biggest single reason compliance doesn't get easier with each passing year is that the merchant's own environment changes. Retailers and processors add new business lines, add and reassign staff, reconfigure their networks, expand or add databases, update firewalls and add or change any number of third-party relationships. With each change comes a potential change in PCI scope that has to be reflected in the assessment.
What do you think? I'd like to hear your thoughts. Does PCI compliance get easier each year? Either leave a comment or E-mail me at [email protected].