PCI DSS is going through a generational change. That change has nothing to do with the upcoming release of PCI DSS version 3.0 this fall. Instead, the generational change is in the security professionals I work with everyday, the people who are managing their organizations' PCI compliance. Most of these professionals are very qualified, but they are new to their job and often also new to PCI.
One result of this generational change is that I am being asked some of the same questions I was asked five or more years ago. The questions range from whether pre-authorization data is in scope (treat it like it is) to the feasibility of E-mailing card data (a seriously bad idea) to what constitutes effective network segmentation (think "air gap"). Fresh perspectives are always welcome, so the implications of this generational change for merchants and QSAs alike are generally positive. But with new compliance staff and assessors come fresh challenges and approaches that can impact every merchant and service provider.
With the release of PCI DSS version 3.0 this fall, the standard will be about seven years old by my calculation. Seven years is a lifetime—or maybe a couple of lifetimes—in the world of technology and data security. A great example of this fact is the PCI Scoping presentation the PCI Security Standards Council staff made at the recently completed RSA Conference.
The PCI Council's presentation was very good. But to someone who has been in the PCI trenches from the beginning, it didn't break much new ground. As it turns out, the presentation didn't have to. The scoping principles described differed little from what could have been presented anytime in the past few years. What was new was hearing some of the same questions from the audience and in the conference hallways that I first heard in 2006.
That fact tells me more merchants are, or should be, taking a fresh look at their PCI scope and not just accepting what they used the previous year (and may have been defined by the previous PCI team).
Let's start with network segmentation. The point made in the PCI Council's presentation was that for PCI purposes, network "segmentation" means "isolation." That is, if a system or device can initiate a connection into the cardholder data environment (CDE) or receive a connection from the CDE, that system or device is in the merchant's PCI scope. It does not matter if there is a firewall controlling the access. It doesn't matter if the connection is only for "a little while." If a connection is possible, then the network is not segmented for PCI purposes and all the devices are in scope.
A merchant's next-generation PCI team must consider each year the infrastructure and include systems that provide, for example, antivirus updates, patching and Internet domain name searches. A next-generation PCI team leader may not be aware that this issue of "connected to" was settled long ago and that a firewall—even a properly configured and maintained one—is not sufficient to achieve network segmentation. The result of such a misunderstanding could be incomplete scoping and increased risk of a reputation-damaging and expensive cardholder data breach.Another, more subtle point made by the PCI Scoping presenters was that just because a system is in the merchant's PCI scope, does not mean that every single PCI DSS control necessarily apples. There are roughly 280 controls in PCI DSS. A patching server, for example, will not store, process or transmit cardholder data, so many of the requirements (e.g., Requirement 3, Protect Stored Cardholder Data, among others) will not apply. Next-generation PCI team members need to know they have the leeway to consider carefully each requirement and to determine whether or not it is applicable to their unique situation.
This is not to say merchants may take a risk-based approach to PCI. The difference may seem subtle, but merchants do not get to pick and choose between which PCI requirements they will apply and which they will skip. That approach has long been declared taboo, and the next-generation PCI team needs to understand that and move on.
One issue a U.S.-based next-generation PCI team will face very soon is the impact of the migration to EMV chip cards. I was recently asked whether the introduction of EMV chip cards in the U.S. market would not be the silver bullet that eliminates the need for PCI compliance. Unfortunately, I had to disabuse the questioner of that notion immediately. The answer is that EMV is about authentication, not confidentiality, and that PCI will not go away. Those of us who have been in the industry for a while know we resolved this question a long time ago. The next-generation PCI team was not around to hear the answer, however.
I hope the next-generation PCI phenomenon will produce one very particular, positive result: a fresh look at the organization's PCI governance structure. Fresh people and fresh ideas present opportunities to improve how merchants and service providers manage their PCI compliance for the 364 days between yearly compliance validations.
For example, does your next-generation PCI team represent both the IT and the business side of the organization? Do the marketing and new product areas get their mobile commerce questions answered? Does the next-generation PCI team understand the impact of the new Wi-Fi system that the warehouse or fulfillment department is about to install? Are the EMV lessons from the organization's European or Canadian operations—and the PCI compliance lessons from the U.S. operations—shared with the next-generation PCI team?
The emergence of the next PCI generation presents many more opportunities than challenges. Yes, it makes some people (like me) feel old or possibly frustrated at answering the same questions we heard five years ago. The upside, however, is the opportunity to take a fresh look at the organization's PCI scope and PCI governance. These benefits will far outweigh any costs.
What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me.