How to protect a credit card database

Richard Hollis
Hollis says deleting data is the best protection

Databases with credit card information are one of the most sensitive risk points of modern business. If cyber crooks can lift the data and steal from the customers it can wreak havoc with a company's reputation and possibly land it in the courts, but according to Richard Hollis too many are not doing enough to protect credit card details.

The CEO of The Risk Factory, a consultancy for information management services, describes the danger of database theft as "the biggest threat you can transmit on the web", and that black market prices for the data show it is growing.

"The going price 10 years ago for name, address, card number and expiration date was about £10 per record - so 10,000 would bring £100,000 - but now it's down to 50 pence and that's just supply and demand," he says.

PCI standards

The Payment Cards Industry Standards Council provides a framework of controls for protecting the data - 288 of them, extending into areas such as configuring firewalls, how to use antivirus software and security policies. While Level One merchants - those that handle more than one million transactions per year - need third party verification to show they comply, others can carry out a self-assessment that is signed off by a director.

But Hollis says it can be expensive to comply with the standards, even for a small company; one that uses a web facing architecture to process payments can easily pay in excess of £10,000. It can also be very time consuming, and if any of the process is outsourced the standards should be enforced at all stages.

He believes that full compliance is very rare, but sees the solution in simplifying the approach to managing credit card data, and advocates a five step approach that he claims can save money while reducing the risk.

"Number one is discover and document," he says. "You have to conduct an inventory of your card data. You can't shrink what you haven't measured.

"Draw a network diagram depicting your card data like a heat map, writing down all your devices to show where the data resides. For example, the data is on this server, that laptop, that desktop, etc.

"The next step is destroy and descope. If you don't need it get rid of it, whether it's hard or soft copy.

"Take your time and use your map. For example, if you have card data in Outlook because it's been sent to you by email, the web server is 'in scope' and all the 288 controls apply to it. So you have to ask 'Why do we need it on Outlook, why is it on memory cards, and then delete, delete, delete.

"Also, any third parties connected to your system are in scope. If you are connected and they don't need access to card data, take them out of scope.

"Third is outsource and oversight. If you can outsource that website and make it their responsibility you transfer the risk. You make sure you've got a contract that makes clear who is responsible.

"For instance, when somebody wants to buy your product, I can give them a payment gateway and they can go to a payment processor. You just contract for PCI compliance with the payment processor.

"Then if you can't do that, separate and segment. The 288 controls only apply to the architecture that facilitates the processing, storage and transmit of that data. Separate any device that is not involved in this, so it will move out of scope and you can save money."

Tokenisation

Hollis describes the final step as "tokenisation", taking the credit card numbers out of the process as much as possible. A web server can send credit card data to a token server, which disguises the credit card number and pushes a token – a different 16 digits - through the rest of the system for authentication.