And Today’s Security Breach Is…
With a new incident of lost or stolen consumer financial data coming to light seemingly every day, it’s beginning to feel like it’s just something to be expected. But this latest incident, in which a database belonging to a credit card processing company was compromised, is particularly interesting, in that the database contained data that should not have been persitently stored in the first place:
“The official, John M. Perry, chief executive of CardSystems Solutions, indicated that the records known to have been stolen covered roughly 200,000 of the 40 million compromised credit card accounts, from Visa, MasterCard and other card issuers. He said the data was in a file being stored for "research purposes" to determine why certain transactions had registered as unauthorized or uncompleted. . . .Mr. Peirez of MasterCard said that the data inappropriately retained by CardSystems was particularly sensitive because it included cardholders’ three- and four-digit security codes, making it more attractive to potential thieves because it can double or triple the black-market value of a cardholder’s account.”
What’s particularly concerning is why CardSystems had access to data such as the security codes in the first place. I’m by no means an expert on credit card transaction processing, but according to this nice graphic by the Times, it seems the primary function of the processing agents is to route the transaction to the correct place. If that’s the case, it’s not clear why these agents need access to anything other than the card number; any other information (cardholder name, billing address, security code, etc.) would seem extraneous to the routing process.
At least in this case, then, it seems as though a protocol change would have prevented any important data from being compromised. The most obvious fix would be to encrypt various pieces of the transaction such that they could only be read by the parties who actually need access to them. For example, there’s probably no reason for anyone other than the cardholder’s bank (and potentially any contracted processing company, according to the Times’s graphic) to be able to see the cardholder’s billing address. So encrypting that data with the public key of the bank (e.g., with IBE, you could just use the first 6 digits of the credit card number, which identify the card issuer) would ensure that any misbehaving processing organizations in the middle can’t jeopardize the security of the really sensitive data.
In general, these types of protocols are so widely deployed that modifying them is next to impossible. But it will be interesting to see what sort of action, beyond requiring more frequent audits of the processing companies, the card organizations and banks take, as there seem to be far too many points along the transaction path at which an unscrupulous (or simply negligent) party can compromise data.