PCI Database Security Primer

I have written a lot about compliance in that past three months, but most of the guidance has been generic. Now I want to talk about database security specifically in relation to the Payment Card Industry (PCI) Data Security Standard, and consider compliance more from an architectural standpoint as opposed to a tools- or policy-based perspective.PCI is, at this time, the biggest motivator to fund data security projects. And to be totally up front, no sizable merchant or payment processor is going to store credit card and primary account number (PAN) data outside of a database. Database security to meet PCI may not be a primary discussion point in the standard, but it is a focal point of the security around the credit card data use and storage.

As a merchant trying to figure out how to comply with PCI for the first time, the learning curve always consists of four phases: trying to understand how the PCI-DSS standard applies to you, engaging security vendors to acquire missing security technologies, your first QSA engagement or audit, and then the realization you would have done things differently knowing what you know now.

Security product vendors know this, so each and every one of them provides a checklist showing how his firewall, assessment, encryption, or [fill in the blank] product covers the 12 PCI-DSS sections, with corresponding assurances of how easy it will be to get compliant with his predefined reports and policies.

Unfortunately it's never that easy, and this is the wrong approach to take. Understanding how to synchronize security tools and practices is one part of the learning curve, as is knowing how a PCI audit will be conducted and how your auditor interprets the standard. But this tactical formula to meeting the standard -- cobbling together technologies to meet each line item in PCI-DSS -- does not account for the strategic business processing model. The result is re-engineering the entire effort down the road to fix early mistakes.

I want to avoid too specific a focus on tools or even the individual DSS requirements, but instead consider two different architectural approaches to setting up a database for credit card data based on the data-processing requirements of the business. Solving PCI in a more top-down manner, you need to ask yourself the critical question, "Do I absolutely, positively need to stored credit card numbers to support my business?" The answer shapes your technology choices.

If you want to keep credit card numbers to use purely as a reference for transaction dispute resolution, data analysis, and customer identification and tracking, then you probably don't need the original credit card numbers at all. In this case I recommend tokenization of the credit card data through an outsourced service, typically provided by your payment processor. In this model you will receive a token in lieu of the credit card, which looks and acts like a real credit card number, but cannot be used fraudulently in any financial transaction.

If you need to keep credit card numbers as part of your internal business model -- for example, if your credit card processor requires you to do so to manage monthly payments -- then you will want to minimize the internal number of servers, applications, and users down to the minimum possible subset and use obfuscated data for every other purposed. Tokenization of credit card data through an external service will remove much of the associated risk of fraud and theft. By using a random token that looks like a credit card number to your database, changes to implement are minimal. You will need to make alterations to some applications to use the tokens, as well as alter some of the payment and dispute resolution processes. And you cannot totally get away from database security because you will still need to assess and audit the platform. Further, existing credit card numbers will need to be transitioned out of your systems through a data obsolescence plan. Regardless, moving forward you need to greatly reduce the scope of a PCI audit, complexity of security systems, and the associated costs of both.

In the next post I will examine the cases where credit card numbers cannot be completely replaced by tokens, and discuss a couple of different security strategies to reduce exposure of credit card numbers in order to comply with PCI-DSS.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.