By: Charles Crawford
In a by-lined piece published in cio.com, well-respected security expert and author Ben Rothke wrote “…people don’t want to invest in long-term security plans. They want their security band-aid now, despite the fact they have never built security into their designs or processes.” He went on to praise the PCI Security Council’s vision: “The genius of the PCI DSS (and when PCI is compared to regulations such as SoX and GLBA, genius is indeed an appropriate term) is that it has sensible concepts such as an open formal feedback process, trend analysis, impact evaluation, guidance and much more built into the very fabric of the standard.”
I find myself usually agreeing with Rothke’s well-reasoned perspectives. Indeed, it is especially easy to agree that businesses should have a culture that promotes holistic security, must not consider compliance an end unto itself, and that the processes of security must evolve ahead of the threats.
Where I take issue with Rothke’s article, “PCI Debate Ignores Planned Improvement Cycle,” is in the apparent limitation of his perspective to traditional security remediation solutions. If the path to sufficient cardholder data security certainty can be achieved only through ratcheted, ever-more-effective and pervasive layers of encryption, firewalling, intrusion prevention and other hardening, then I suppose Rothke’s point is well taken, albeit worrisome. What follows logically is that merchants should “man up” and embrace a future of never ending “improvement cycles” that require lots of money, effort, time and discipline (notably external discipline) in their quixotic journey toward “breach-proof” data.
What is taken too lightly is the role innovation already is playing. Less costly and pragmatic ways of avoiding data compromise are fast gaining acceptance as viable alternative among recession-weary merchants.
The PCI Council got it right when they set as milestone #1 of their Prioritized Approach to Pursue Standard Compliance “Remove sensitive authentication data and limit data retention.” EPX, for one, provides merchants a pre-emptive solution with exactly that purpose: total elimination of cardholder data from merchant systems so that it can’t be lost or stolen.
Conventional thinking is for merchants to use matrix of remedial techniques, gambling that the data they hold will so be perfectly sequestered and disguised it might not get compromised – at least, if everything works as planned and criminals don’t get any more clever.
EPX, on the other hand, concluded that the surest way to avoid data loss is for the merchant never to have the data in the first place. Instead of keeping card data, EPX merchants operate normally using GUID transaction reference codes called BRICs. BRICs are used as card numbers would otherwise be, for transaction receipts, customer service returns, refunds, chargeback responses, follow-on purchases and all other operational and financial purposes. BRICs are not encryptions and not derived from credit card numbers, therefore have no street value if lost or stolen from the merchant.
For EPX, tokenization comes as no band-wagon initiative like we now are seeing from Paymentech, First Data and others. In fact, EPX started routinely processing with “replacement values codes” in 2001 …three years before the first PCI Standards were published. Our processes evolved over the years into the comprehensive, patent-pending suite of cardholder data security technologies we now call BuyerWall™.
As the Council and many others have said, there is no “silver bullet,” no single solution – even tokenization. We make no claim that EPX BRICs are such. Yet, properly constructed and managed tokenization also is no “band-aid” that Rothke so wisely mocks. When the card numbers are gone, they’re gone. There’s not much left for the merchant to safeguard. And, once implemented, EPX requires no extraordinary “improvement cycles” or investments to maintain the security of the data. In fact, security of the data becomes a responsibility for which EPX is well prepared, since, as a processor, we have always had to take special care with data and are subject to the PCI SCC’s most rigorous compliance requirements (Level 1).
Is it so, that “people want their…security now No doubt about it. But, I say “why not?” Merchants deserve pragmatic solutions that can achieve even a higher standard of security without costly and cumbersome techniques that may or may not ultimately prove effective enough.
Rothke says there is genius in the PCI’s process of ever-evolving standards. I think their real genius of the Council is its professed technologic agnosticism which, generally, is supposed to allow merchants to achieve card data security with whatever technology and processes work best for them. In that spirit, merchants have more to choose from than Rothke seemed to acknowledge.
—————————–
Charles Crawford is EVP of Strategic Development for EPX
[1] http://www.cio.com/article/495093/PCI_Debate_Ignores_Planned_Improvement_Cycle?taxonomyId=3000; June 2009
EPX Protects Payment Data During the Transaction Lifecycle, But Consumers Must Safeguard their Credit Cards and Debit Cards at All Times
Tuesday, January 12th, 2010Electronic Payment Exchange’s industry leading tokenization and encryption technologies protect payment data throughout the transaction lifecycle. Independent of EPX however, identity theft occurs constantly as a result of insecure consumer practices before any card data enters the transaction lifecyle. Therefore, it is important for credit and debit card users to practice high levels of safety when performing transactions.
Below is a list of important safety tips for credit and debit card users to follow:
If credit and debit card users would perform at least half of these suggested security tips, the number of identity thefts and fraudulent transactions happening each day would be reduced.
For additional information about identity theft, click here.
Tags: credit card, credit card processing, credit card processor, data breach, data breach victim, data theft, debit card, debit card processing, debit card processor, Electronic Payment Exchange, encryption, EPX, identity theft, payment processing, tokenization
Posted in EPX Commentary | No Comments »