GuestView: PCI’s A Lot More Useful Than Some Perceive
Written by Evan SchumanGuest Columnist David Taylor is president of the PCI Alliance and a former E-Commerce and Security analyst with Gartner.
The headline of a recent entry in the Securosis blog by Rich Mogull, former Gartner analyst and noted security curmudgeon, was a pointed "Is PCI Worthless?"
Rich argued that PCI is flawed because compliant companies can still be breached. I think I can safely speak on behalf of the 100+ members of the PCI Knowledge Base and the PCI Alliance when I say that we strongly disagree with his conclusion. But before we assemble the groups in the backyard to head over to Rich’s house for a good old fashioned ass kicking, we need to consider his arguments.
First, Rich argues that PCI DSS was established to transfer risk from the card brands to the retailers and processors. However, I’ve worked with a number of retailers on PCI projects over the past few years and, believe me, retailers already own the risk of a breach. It’s their brand on the line and they don’t need the card brands or their acquiring banks to tell them that.
PCI DSS, by providing a checklist of specific controls and technologies, draws heavily from ISO 27002 and adding an enforcement process lacking in the international standard, provides very useful direction to many merchants and a very handy tool to help security managers justify the purchase of security technologies they had been trying to get for years.
Second, Rich argues that the assessment process is flawed, such that ASVs (he means to say QSAs) are not accountable for the quality of their assessments. There is a real issue here: QSAs do a "point in time" assessment and the PCI process only requires this be done once a year. But a lot can happen in a year. Heck, a lot can happen in a day, such as implementing new applications, changing firewall rules, or re-tuning the IDS.
Any of these things, and many more, can essentially "invalidate" the value of a "Green ROC." But the accountability for these changes has to rest with the retailer who makes them. That’s why we need to have sufficient security staff who actually understand the implications of the day-to-day operational changes. No company can simply buy some security software, bring in a PCI assessor for a month and expect that they are "done" with security until next year, then hang any problems in the interim on the assessor.
Third, Rich argues that assessors should not be allowed to certify their own remediation work. On this, we’re in complete agreement, and many (but not all) of the retailers and assessors in the PCI Knowledge Base would also agree that this is risky. We wrote about this very problem two weeks ago in this column. We still recommend that retailers ask the same set of qualifying questions of a group of assessors, find two that agree on the interpretation of certain "key" PCI standards, and then use one for the assessment, and the other for the remediation.
The more retailers understand the liability, the more they will realize that PCI and other compliance needs to be "baked" into business operations, not dumped on IT security management.
If you want to discuss this column or any other security or compliance issues, please send me an E-mail at David.Taylor@PCIAlliance.org or visit www.KnowPCI.com to join the PCI Knowledge Base.
-Marc
March 22nd, 2008 at 12:09 am
PCI is flawed for more reasons than Rich lists, too. The key flaw is that it leaves critical decisions regarding security implementations in the hands of non-cryptographers.
Obtaining consensus among retailers may have driven the PCI Alliance to be vague in their prescriptions, but this uncertainty has led to thousands of amateur implementations of security. The rush to tokenization without understanding the implications of implementation is just one glaring example of misunderstood security.
The embedded encryption in today’s PIN pads is the only current step in the right direction, but it does not go far enough in that no PIN pads today encrypt the actual track data all the way back to the banks. Even if they did, though, copyable account numbers and easily cloned mag stripes are never going to be perfectly secured. Retailers, banks and networks will continue to make mistakes in encryption, in storage, and in processing. Waitresses will continue to clone cards. And bad guys are champing at the bit waiting for the next weakness.
What is really needed to ensure security of access to credit and debit accounts is a completely different approach. Rather than trying to secure the data that defies securing, we need to render that data useless to thieves. The best news is that we can start now, and it can be done in stages.
The simplest first pass at a solution is to require customers to key a PIN for every transaction, not just PIN debit. The best thing about selling this solution is it eliminates the need for signature pads, so you’ll immediately make every signature capture equipped cash register about $400 cheaper. (If you want to get a merchant’s attention, talk price cuts.) It’s a low-impact approach that immediately devalues most stolen card data. And many merchants today already have PIN pads and PIN encryption in place using acceptably strong mechanisms like DUKPT and 3DES; as a result PIN data is at much less risk than mag stripe data is today.
But secure-looking PIN pads can be faked, and dishonest merchants and thieves can theoretically place hidden cameras over them to view the PINs as they are being entered. PIN pads are only a stop-gap measure. There is more that can be done.
The ultimate answer to PIN security is to distribute smart tokens to the customers, either with their credit cards or embedded into the cards themselves. The purchasing step changes a little: the customer must first key the PIN into their own smart token, at which point the token displays a unique number in response, then the customer enters the displayed number into the merchant’s PIN pad. (RSA sells these kinds of SecurID tokens today, although they’re incredibly pricey.) The security here is derived from the fact that the encryption at both ends of the transaction are owned by the same entity (the issuing bank), and by no one else in the middle. It’s a simple principle: if the keys are never given to the merchants, web sites, or networks, then the merchants are incapable of leaking the data.
It’s also 100% backward compatible with today’s deployed hardware. Even better, the merchant’s PIN pads no longer have to be certified and trusted devices, because the PINs no longer have to be kept secret. The PINs generated by the token are valid only for a single transaction — copies are useless. Because the tokens include clocks synchronized with the bank’s clocks, they’re also valid only for a limited time. You can’t generate a PIN now and hope to use it 10 minutes from now. The mag stripe card data continues to identify the customer’s account, but without a current, valid PIN the data is utterly useless.
It also translates perfectly well to web sales. Encrypted pages aren’t even needed for the security of the transactions (other than for personal privacy reasons.) Any browser that the user can type their account number and PIN into will work.
Transferring the security and encryption burden to the customer’s token also stands the theft model on its ear. No longer can a thief harvest a database — they would have to steal a token or a transaction at a time, and that kind of theft is hard to scale. Because the account number is still a part of the transaction, unique keys can be assigned to each customer’s token and kept by the bank, thwarting efforts to reverse engineer a token and recover some “master” bank key. The only databases of PINs and keys are at the banks, not the retailers. And it’s much easier to secure a single bank who lives by offering security rather trying to secure a thousand merchants who live by inviting customers to come inside.
Are there weaknesses to this plan? Sure — a man in the middle attack could hijack a legitimate authorization request for a soda to a conspirator in a jewelry store to purchase a diamond, or a token could be stolen and falsely used. There are encryption protocols that need to be designed to mitigate those kinds of risks. But the idea of end-to-end protection of the authentication mechanism is the Holy Grail of a secure protocol, and we do have the technology available today.