This is page 3 of:
Is Point-To-Point Encryption Ready For Prime Time?
Implementing tokenization on top of P2PE may not be easy. For example, is the acquirer capable of or even interested in providing tokenization? Alternatively, can or will the acquirer or the P2PE vendor send the cardholder data to a retailer’s preferred token vendor? What will that cost? What if the acquirer offers a tokenization product different from the retailer’s preferred vendor? How many more service providers are now storing cardholder data for the retailer, and is the retailer prepared to manage all of them?
Maybe we need to add these to my previous list of 10 tokenization questions, either the first five or the second five.
None of these issues is insurmountable. Some very smart vendors are active in this space, but we lack standards and guidelines. This means retailers need to make any decisions on P2PE (or tokenization, for that matter) with their eyes open. Maybe it is not like being a beta site, as some people have described it. But making a commitment now should definitely put you in the early-adopter category.
The PCI Council’s white paper identifies several future actions it “will consider,” including additional training and testing standards. The most interesting to me is the possibility that the Council would develop “tools for merchants, such as a list of qualified P2PE solutions and/or revised self-assessment questionnaires.” I don’t know if the Council is talking about the equivalent of a PA-DSS or PCI PTS for P2PE, but—if so—it could be a great benefit for retailers and merchants of all sizes. Implementing a new standard could prove a nightmare, so I would not count on it happening soon.
For now, we all will have to await the follow-up paper, tentatively entitled “Validation Requirements for Point-to-Point Encryption,” to be released sometime in 2011. The Council’s plan is to send this paper only to participating organizations (yet another benefit of being one of these companies), at least initially.
In the meantime, if you are contemplating P2PE, I’d suggest you start by finding all your cardholder data. After you do that, go back again and make sure you really have found all the data: paper forms, databases, CDs, thumb drives, call center recordings, laptops, logs, system backups, E-mail backups and the myriad other places where data can hide. Then address the 10-plus questions I have raised. Remember, no magic will make PCI go away. But this technology has great promise to reduce PCI scope. Oh, did I mention to be sure to find all your data?
What do you think? I’d like to hear your thoughts. Either leave a comment or E-mail me at wconway@403labs.com.
-Marc
October 14th, 2010 at 8:44 am
Another important consideration for some (but not all) retailers is how they would handle “fallback” or “stand in” processing when the payment processor is off-line in a P2PE architecture. By definition, the merchant must somewhere queue up those transactions even if they are at that point encrypted using the P2PE scheme. This now would seem to constitute card data at rest, and the guidance in the white paper appears to be explicit in that it’s addressing only card data in transmission – not when it comes to rest as is required in a fallback situation. For example, in one section the PCI SSC in saying what the white paper is not writes that it is not “an analysis of how P2PE components may affect stored encrypted cardholder data”. Now, I would argue that if the data is encrypted at the initial point of interaction and it needs to come to rest (in encrypted form) for a short time in the course of fallback processing it does not represent qualitatively any more risk than if it were simply moving through systems in real time. A network sniffer can just as easily capture (P2PE) encrypted card data while in transmission as someone can copy encrypted card data while it is at rest – and both should be equally useless. However, it appears that the initial intention of the white paper does not take this position (at least, not explicitly). This is something that will need to be discussed by the merchant community with the PCI SSC in the months to come to see if some accommodation can be made for fallback processing.
October 14th, 2010 at 9:02 am
If merchants are to go through the process of replacing all PINPads and other card-swipe devices so that they are P2PE capable, as is reasonable, they will want to do this exactly once (at least, within a reasonable time horizon). Visa and MasterCard have continued to delay providing the U.S. market with a “roadmap” as to what future technologies (if any) could/will replace the magnetic stripe cards we all use today. If Visa and MasterCard plan on moving to something other than magnetic stripe cards (such as EMV), they need to make that intention (or lack of intention) known now so that merchants can avoid replacing PINPads one time for P2PE and then a second time for a new card technology such as EMV. In my experience, large merchants will be quite hesitant to move ahead with the time/money/effort investment required by P2PE in an environment of such uncertainty. If Visa and MasterCard made their intentions clearly known, I believe this would clear another major hurdle that could otherwise impede the adoption of P2PE – to do otherwise would be unfortunate, as P2PE in my mind represents the potential for the largest increase in effective payment security we’ve ever seen.
October 14th, 2010 at 9:36 am
P2PE shows a lot of promise in combating the major threats to integrated POS environments – key loggers and memory parsers. However, the problem that has not been solved particularly well is determining which cards to encrypt. Merchants with integrated POS environments often process a variety cards such as loyalty, fleet, gift, house, that trigger specific POS operation when identified. Encrypting these cards breaks the POS functionality, and thus the added value the merchants are providing their customers. Until this conundrum is solved—and in a manner that delivers the eagerly anticipated PCI scope reduction needed to justify the expense—we may not see mass adoption of P2PE by merchants with integrated POS.
October 14th, 2010 at 6:30 pm
@Jim, Thanks for your comment and pointing out the issue with fallback/stand-in processing. Like manual key entry, a good solution would have to allow for this as the only alternative seems to be going dark (or at least no plastic) during outages. However, there may be a ray of hope: since the data are encrypted, and the merchant still has no ability to decrypt, even these data might be viewed as out of scope. Then, of course, you still have the issue of the storage of sensitive authentication data (mag stripe, PIN block) during that time. I’m afraid I don’t have an easy answer, either, but you will want one before committing.
Good point, too, on the hardware purchase. Without a clear technology roadmap it is difficult to ask merchants to make large purchase decisions – or even to ask the card brands for interchange incentives as they have done in the past.
@Ernie, a terrific point on trying to blend P2PE with an integrated POS. Using preferential routing can cause some complications. I can think of a few alternative approaches, but each has scoping implications and may reduce the expected benefits or cause operational problems…maybe you are giving me an idea for a future column!
October 15th, 2010 at 1:54 am
Manual card entry is indeed something that calls for some consideration – but in my experience would be something that many merchants might be willing to forego if they could otherwise relieve themselves of (essentially) all store-level PCI DSS scope. In fact, a significant number of merchants already do not allow this due to the potential for abuse. Of course, one could perhaps use the PINPad to perform manual entries – but then you are drifting into putting more substantial logic into the PINPad applications/firmware which raises its own sets of issues. If push comes to shove, old-school “knuckle-busters” (i.e., manual imprinters) provide a simple way to accept payment in those relatively rare instances of defective cards and many merchants keep at least one around today as a last-line-of-defense backup to their electronic systems.
October 15th, 2010 at 1:58 am
Ernie’s comments are indeed accurate – another of the non-trivial hurdles to overcome in order to implement P2PE in an integrated POS environment would be a fundamental re-architecting of the relevant protocols to not only handle the encryption aspects of P2PE but also the legitimate needs of the POS system for aspects of the card data they would no longer be directly privy to. At a minimum, the POS needs the last part of the PAN and perhaps the type of card in order to display this information on the customer’s receipt. If switching or routing of some sort is occurring at the site to support any of a variety of payment scenarios (e.g., certain loyalty programs, fleet cards, local cards, multiple payment processors, etc.) this re-architecting becomes even more significant. Note that the guidance provided by the PCI SSC appears to explicitly discuss this in section 5.2.3, saying that any entity performing “white listing” of certain card types (which I believe would reasonably include any type of card-type-based switching/routing) would still be subject to PCI DSS review. This would seem to have profound implications for retail architectures that employ store-resident payment switches or electronic payment servers and wish to implement P2PE to reduce their store-level PCI DSS scope.
My thinking is that the necessary paradigm would likely have to be one where any payment-related information required by the POS (whether to print receipts, make routing decisions, etc.) would have to be provided back to the POS from the payment processor(s), similar to how authorization codes are provided back today. And in certain circumstances this could now require multiple transactions to a single payment processor (or multiple payment processors) in order to complete a single purchase. It would not be easy to implement such a change in thinking, but if done correctly I think it could hold up as a fairly elegant approach – especially when considered against the benefit of essentially eliminating store-level PCI DSS scope.
October 15th, 2010 at 8:55 pm
Jim,
Are you suggesting encrypting everything? This may not always be desirable, and will require a paradigm shift in the system.
For now, the most likely short-term solution is a white-list. There are a lot issues with updating the white-list. The white-list should be used along with a black-list (BIN ranges that must be encrypted regardless of the white-list). One can only add entries to the black-list. If the encryption device is tamper resistant, meaningful authentication can be done when updating the white-list or the black-list. In case the white-list is not up to date the processor can recognize this. The processor can then send back the BIN and ask if the POS wants decrypted data.
Significantly reducing PCI scope is hard but should not be the only reason for P2PE. Actual merchant data security can be greatly improved with a reasonable P2PE solution.
October 18th, 2010 at 5:09 pm
The flexibility of selecting their tokenization vendor may be preferred by some retailers but acquirers that offer integrated tokenization solutions are very compelling from security, cost and convenience perspectives. Tokenization is destined to be a commoditized service and many retailers will not be willing to contract with a third-party gateway provider for it. In addition to the vendor management overhead, a gateway based tokenization solution would also introduce yet another single point of failure into the payment processing chain. This is an undesired side-effect since tokenization is intended to increase service reliability.
The integration of tokenization and payment processing on the same platform leverages the benefits of centralized data management, reduces the vendor relations that the retailer needs to maintain and provides a better level of security by reducing the number of service providers that store sensitive cardholder data. The retailers’ ability to move from one acquirer to another can better be addressed by token portability mechanisms, which are limited today. An easy-to-use token portability mechanism will practically enable retailers to enjoy the flexibility of changing their acquirer or payment processors without the concern of vendor lock-in due to tokenization.
October 21st, 2010 at 7:53 am
Actually, I am indeed suggesting the possibility of an “encrypt everything at the point of swipe” paradigm – as George says a major shift in philosophy, to be sure, but one that I think offers so much to many classes of merchants (especially, large ones with integrated POS systems – and doubly so in franchised business models) that its benefits could well outweigh the one-time effort involved in implementing P2PE across the entire payment processing chain. You are absolutely correct that, as I alluded to, there are a number of common scenarios (e.g., multiple payment processors, loyalty program recognition, fallback processing, etc.) that would need to be fundamentally rethought and their transaction protocols reworked to accommodate them. Although I would like to believe that merchants would choose to implement P2PE solely on the merits of it increasing the effective security of their environment (which it clearly does, dramatically) my experience working with major merchants leads me to think they simply will not undertake this without a significant carrot to justify the effort – and the only carrot I’ve ever seen that is big enough to entice them would be the elimination of store-level PCI DSS scope.
October 21st, 2010 at 9:26 am
As one small evidence of the challenges that many Level 3 & 4 organizations face and why I believe an “encrypt everything and take the store out of the PCI DSS compliance loop” approach could be so valuable, I offer some comments from Gray Taylor who is the Executive Director of the Petroleum-Convenience Alliance for Technology Standards (PCATS):
“PCI is simply too technical and complex, and the majority of our small retailers simply don’t have the expertise or resources to comply – and no amount of education will overcome this…to believe that mom and pop retailers can re-design local area networks, monitor rogue wireless access points and manage firewalls for security is absurd and shows how out of touch with small business PCI has become…”
The rest of the associated article can be found at http://bit.ly/atKA9W