An alternative to PCI
PCI is still a hotly debated topic nearly four and a half years after its initial release on December 15, 2004. You didn't have to visit too many after hours parties or exhibitors at RSA to see that.
Most of the criticism of PCI comes from people who really don't understand it, or understand how to use it to their advantage. And those people fall into two categories themselves; those who are green to PCI and are overwhelmed, and those who love their soap box.
Those in the former bucket just need time to get up to speed. PCI, like Rome, was not built overnight, and it requires weeks of study to fully grasp how it will affect your environment. There is training available from a couple of industry sources, though my personal preference is that any training on payment security should not stop at PCI. I have a solution for the card companies to address the latter group directly, but more importantly, address the industry at large to demonstrate that you really do focus on information security.
I propose that the founding members of the council (Visa, MasterCard, Amex, Discover, and JCB) consider two ways to demonstrate PCI Compliance. The first of which is to complete the PCI DSS just like they would do today. Nothing new there.
Here's the twist.
The second method should be met by demonstrating a mature ISO 27000 security program, potentially certified under BSI America. That serves two purposes. The first purpose is to accomplish the intent of PCI DSS, protecting the data. The second is to combat the nay-sayers who say things like "I can't wait until this PCI crap is over so I can get back to security1." In reality, those nay-sayers were doing a poor job at security before by only focusing on problems that interested them, not ones that were in the best interest of the customers, shareholders, and employees of the company.
If the card brands gave merchants and service providers the option, I think you would see the majority choosing PCI DSS, and only the most savvy choosing the ISO route. The best thing is that the card brands could fight the fires on two fronts. They can continue to coddle the laggards, and improve corporate information security for those that wish it. Most security professional agree (four out of five dentists?) that PCI is not the scariest thing out there, by FAR. But if you use what you learn from PCI and improve upon its required baseline, you can use the ankle-biting nature of PCI to also subdue his bigger, more ornery cousins PII and the State Data Breach Laws2.
_______________________________
1 This is an ACTUAL QUOTE from one of my retail contacts!
2 Sounds like a great name for a band!
Comments
Beautiful.... That is what it would be - ISO 27002 has a great deal of complete controls, and having run a few brilliant organizations through the process I must say it is quite good. I love the idea of ACCREDITED institutions and certified AUDITORS conducting these engagements. It eliminates a few of the conflict-of-interest (realities) perceptions, and provides a program that doesn't cause the "security-blinders" from coming up during an engagement.
Security-Blinders: When a manager or professional approves great security controls and prevention techniques, but only for the sub-systems and people that happen to handle a particular type of data that is in-vogue for being verified for compliance.
ISO 2700X allows for a true Program for a business that addresses the (shock) BUSINESS' risks from operating, and not only those that exist to the Card Holder Data.
PCI DSS gets the job done for the single type of risk for a particular set of threats, but for an enterprise it is only a piece of the pie. Leveraging audits conducted that sufficiently address the scope, safeguards, and intent of any (PCI) regulation/mandate is the shortest path to efficiency across compliance/audit/security teams worldwide.
Thank you for posting your thoughts,
James DeLuccia IV
**A timely point raised at RSA during my PCI DSS and Beyond session
Posted by: James DeLuccia IV | April 28, 2009 8:47 AM
How about a third plan:
Don’t let merchants store credit card numbers past authorization.
If you are the card brand and really concerned about the security of your precious data, don’t let anyone keep it.
I propose instead a method where customer swipes card, it is authorized giving the merchant a THING. This THING is valid for that customer and that merchant only. This way should the merchant need to do charge back, reoccurring payment, or the frequent purchase for that customer they can do so with this THING. Storage of CC data is eliminated, foiling hackers/cyber terrorists/evildoers/corporate spies/bad guys with dastardly mustaches, and the merchant can make the transactions easy for the customer if so desired.
Posted by: Kevin | April 28, 2009 12:01 PM
Ahh, but Kevin, this DOES exist! I did not provide the info I promised you when we met in Chicago, but here it is. The last card brand to put something like this together was Discover, and they released this in mid 2008. Here is a summary.
Remember it is up to your BANK to be able to handle that field in your processing and settlement, not a card brand. Please email me if you want to discuss more!
Posted by: Branden Williams
|
April 28, 2009 12:47 PM
Kevin, what you mention is tokenization and exists with many payment processors and payment gateways. Unfortunately, malware being used captures card data by sniffing COM ports, USB ports, network interfaces, and memory. These malware packages are now the norm and not at all exotic. The best defense a business has at protecting consumer information is to limit the use of such data, the systems it touches, and to protect the heck out of the systems that must handle it. There's currently no product or technology that removes the sensitive data completely or removes the risk.
Posted by: Lucas | April 28, 2009 12:50 PM
You would be surprised (Well maybe not) how many times we have offer transactions for inquiry resolution with major processors and gateways that request Card Numbers in the clear rather then reference numbers, LifeCycle Identifers, and the sort
Posted by: David Bergert | April 28, 2009 12:56 PM
Lucas, while I will agree that there is no way to remove the data from the process entirely, this methodology will limit the exposure drastically.
Brandon, up to my bank does not help PCI for everyone, and will not satisfy the house committee. There needs to be more effort to help re engineer the the payment process from what it is to what it should be.
I was also informed that this process could perform reoccurring same transactions, but not allow me to issue a new transaction of a different amount, basically letting me store the customers CC for easy checkout after they are authenticated. Is this incorrect?
Posted by: Kevin | April 28, 2009 1:32 PM
Kevin: You are absolutely correct in that leaving it up to your bank does not immediately help you. That's one of the unfortunate consequences of in-sourcing your payment systems where your bank is less than flexible or helpful. The customers that I have worked with that have the easiest ability to implement features like this are the ones that have the best relationships with their Acquiring banks.
I am unclear on your last question, but my bet is that the ID is tied to a single transaction and would not be able to be used for a monthly recurring transaction. That said, most acquirers have solutions that allow you to store tokens instead of the full card number to re-run the transaction on a monthly basis.
Are you sensing a theme here?
Besides, the best solution is to simply offload all the risk you can back to your bank and make them deal with it! :)
Posted by: Branden Williams
|
April 29, 2009 1:17 PM