In The Security Vs. Compliance Battle Of The Mind, Security Is Winning

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

If ever there was an argument where security trumped compliance, the debate about tokenization versus encryption is it. Readers have made that point abundantly clear following a recent column describing the PCI scope reduction benefits of tokenization versus encryption. The shift in emphasis from compliance to being secure is not new, but I was struck by how pronounced a perspective change retailers are experiencing.

Andrew Jamieson's comment emphasized security over scope reduction. He described how he would put more faith in the security of a tested and proven technology like encryption than he would in tokenization. I know Andrew as a PCI and crypto pro, and although we have never met, we have exchanged ideas and thoughts on PCI-related issues remotely for a couple of years.

Where we differ is that, based on my experience, not every merchant has the expertise to implement an encryption system as well as Andrew might. He works for a security firm. A retailer's IT department has a lot of other things to manage, and encryption may not be a core strength internally. Properly deployed, strong encryption can protect cardholder data and be PCI compliant. But compliance alone is not my focus. I look at minimizing PCI scope.

Where a merchant has the expertise (internally or through a partner), encryption can protect cardholder data. I believe the PCI scope will be broader than a similar implementation with tokenization. I agree with Andrew that if it is properly done, the encryption solution could be secure. I also believe we both would agree that either choice, properly implemented, would be more secure than the other if that one is poorly implemented.

Jeff Man got readers thinking about the process, drawing parallels between tokenization and encryption and pointing out that tokenization, too, is ultimately reversible. I know Jeff as a respected QSA and a crypto expert with impressive experience. He made the point that both processes are subject to compromise: Either the encryption keys or the token vault could be inadequately protected. To me, the most important part of Jeff's comment (and the one by Steve Sommers) is reinforcing the criticality of security for the tokenization engine and token vault. We both agree that this is the case whether the tokenization is managed internally or outsourced to a specialty tokenization vendor. I believe that PCI provides a good structure for how implementation can be done to be both compliant and secure, even if explicit details are not, as Jeff pointed out, contained in the PCI Council's guidance document.

Mark Bower raised the issue of maintaining—and continually proving—the security of the tokenization solution over its lifetime as networks, systems and people change. I know Mark as an encryption and security expert, and I respect him a great deal. His point, like the others, focuses on the need for security and not just scope reduction.

My response starts with the fact that the changeable nature of systems and environments is why every merchant revalidates PCI compliance each year, and part of that revalidation (or re-assessment) includes taking a look at all policies and the risk assessment. More to Mark's point, though, is the fact that although validation is once a year, actual compliance is what the merchant has to do every single day. If a merchant does not have the policies, procedures and internal culture to be compliant at all times, perhaps neither tokenization nor encryption is a good solution. Those organizations might be better served by not storing any cardholder data.

Lastly, I'd like to note the comments dealing with what the PCI Council terms "high-value tokens" and the confusion from that distinction. One commenter (who was on the Tokenization Special Interest Group) observed that a compromised high-value token could lead to fraud even though the PAN was never exposed, thereby implying that PCI is not designed to prevent fraudulent activity.

I have to take issue with that conclusion. My evidence is the high-value token designation itself. The fact that the Council's guidance all but decrees these tokens to be in scope tells me that PCI is definitely concerned with fraud even if PANs are not compromised. Nevertheless, having direct input from somebody who was on the SIG is extremely valuable.

Clearly, tokenization will continue to generate a great deal of interest and discussion. What benefits everyone—retailers and vendors alike—is emphasizing not just compliance and scope reduction but security. If a solution is secure, then compliance will follow whether you choose encryption or tokenization. On that I think we all can agree.

What do you think? Do you have other comments you would like to add? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].