From: Juan Castro (SAL-LA)
Sent: Tuesday, March 30, 2010 3:15:20 AM
Subject: NEWSBANK :: Why protecting payment card data is different – and the unique opportunities it creates
Auto forwarded by a Rule
Why protecting payment card data is different – and the unique opportunities it creates
In the years I have been focusing on data security (as opposed to general ‘information security’), I have spoken to hundreds of companies about the types of data they find valuable. Invariably, when asked about the kind of data they are concerned about, the company will reply, “Credit Card numbers and (insert other data type here)”. Almost without fail, every single customer says ‘credit card data’, and usually puts it first. I’m not a statistician, but I think that constitutes something significant.
A lot of that has to do with PCI. A lot of that has to do with the notification laws that have made losing credit card data a public relations nightmare as much as a security problem. Some of it is even because of responsible stewardship. But whatever the cause of any particular company’s desire to protect their customers’ credit card information, it is a good thing.
There are lots of ways we go about protecting card data, or any specific kind of data for that matter. First we have to know where that data resides within the enterprise. We have to have policies for who is allowed to access and use that data and under what conditions. And we have to have mechanisms to enforce those policies and audit compliance.
One of the most frequent ways companies now enforce policies for card data protection is through the use of encryption (either in applications or through data-at-rest). Key management, one of the most difficult hurdles preventing the widespread use of encryption, has been addressed with increasing success with dedicated key management products (such as RSA’s Key Manager). This improvement in technology combined with external regulations which mandate the use of encryption has led many companies to start encrypting card information.
Unfortunately, just because you’ve encrypted the data doesn’t mean you’ve removed all of the risk. In the case of a remote attack against a data store, the bad guy is going to try accessing the data through an application that decrypts the data as a part of its operation. What we soon realize is that encrypting data at rest prevents physical theft and limits potential vectors of attack. It also allows companies a “safe haven” to avoid notification laws if they lose a physical asset, such as a laptop or backup tape.
So that got us thinking about ways to mitigate more of the risk associated with payment card information. And we asked ourselves “why do companies keep card data to begin with?” It’s no big secret that card data is a valuable theft target, so why do companies continue to hold onto it? As I’ve discussed before, the myriad reasons boil down to two big buckets – financial and analytical.
Armed with that insight, we can argue that companies don’t need actual card data if they have a unique identifier they can use to support their internal business processes. This identifier is the token we provide as part of the tokenization process. To date, we’ve used card numbers out of convenience – they were available and fit our purposes. But there is no reason we can’t use a proxy in lieu of card numbers as long as it enables us to keep our business processes going.
Tokenization solves for a lot of problems that encryption doesn’t. Tokenization maintains the format of the original data, which limits the amount of changes that need to be made to customer applications or databases. It limits the vectors of attack on the real card information, because non-financial systems don’t need actual card information. And even financial systems don’t need the actual card number unless they are executing a financial action. Using tokens reduces the scope of the card data environment, which in turn reduces the scope of the PCI-governed card data environment, which in turn reduces the overall level of risk for the organization.
Tokenization can be deployed internally, but this still means that card data exists within the enterprise. That (smaller) card data environment is still subject to PCI. And that card data is still a target for cyber criminals. Without the proper controls in place to protect it, the customer can still be exposed.
And here’s where the fact that we are trying to protect payment card data creates a unique opportunity. Why does the organization who accepts the card need to retain the card data at all? A company can’t monetize a card number without using their payment processor, which means that the processor is the one who really needs the actual card data. The processor is in a unique position to both store the card data and issue the tokens. The company only needs to transmit the card number and can use a token to support their internal business processes. This insight led RSA to partner with the leading payment processor, First Data, on a tokenization service (TransArmor) that they provide to their merchant partners.
Credit card data is uniquely suited to this kind of service. Companies rarely communicate credit card data outside of their organization except to their processor - meaning that the data moves internally within a company, or vertically to their processor, but not horizontally to other companies. Other data types either should never leave the enterprise (such as trade secrets) or are shared horizontally with other companies (such as partnerships or other working relationships).
If we are successful in removing credit card data from the enterprise, I start to wonder what types of data companies will then tell me they are most interested in protecting...