PCI: Data Token Alternatives

When a merchant cannot -- or will not -- replace credit card numbers with tokens provided by its payment processor, how does it secure it database to be PCI-compliant?Based on the understanding that every organization subject to PCI requirements is going to be using a database to store Primary Account Number (PAN) and associated credit card data, there are three primary options to choose from, all of which use a single central database with credit card numbers and share obfuscated copies to all other systems:

1. Internal Tokenization: In this model a single database holds the original credit card numbers. All other systems will substitute the real credit card number with a token facsimile. The token service might reside within the credit card database, or it might be a separate server. The token server creates a token for each new credit card transaction, and distributes the token to other database systems. All other servers will continue to function as normal because the token looks just like a real credit card, but cannot be used to commit fraud.

The database that stores credit cards must be highly secure, used by only a handful of approved users and for only a finite set of discreet credit card processing tasks. If other systems with tokenized data are allowed access to the database storing real credit card data, then it is through the token server acting as a proxy, mapping tokens to credit card numbers for credit card transactions without disclosing the original number.

2. Masking and Bastioned DB: Very similar to the previous model, a single database holds the original credit card numbers. All other systems replace real credit card data, as well as all personal information, with masked data. The database with CC#s will be highly secured, excluding all users except a very select group. All functions will be restricted to a simple set of discreet credit card operations and some reports. All other data, processing, and applications will be excluded from the credit card database.

Further, you should embed credit card functions into stored procedures within the database that have been reviewed, tested, and approved. In this model only prebuilt and preapproved functions can be used to access or use credit card numbers, and ad-hoc queries are excluded. This helps ensure proper usage and protects against SQL injection, buffer overflow, and similar attacks. Periodically customer and credit card transaction data will be extracted, masked, and then imported into supporting systems, ensuring all other systems use only a masked or obfuscated copy of the original data.

3. Masked Database Interfaces: This is for smaller firms that must retain credit card numbers, but have only a small number of supporting processes that rely on a masked interface. In this model all queries go to the central credit card database. A select group of users are allowed to access the credit card numbers, with all others being directed to a view with masked information. In this case the database handles the segregation of data for you. It's clearly not as secure as the other options, but far simpler to implement.

Most of the PCI articles you read talk about how a particular tool meets a specific section of the PCI-DSS requirements. But if your goal is to be secure and not just get PCI-compliant, then trust me when I say you are going to need just about every security tool in your arsenal to safeguard the data. That's a given, so a discussion of which tools you need can be misleading. Further confounding the issue is when you review the PCI-DSS specification, the majority of controls and advisements are built around network security.

But the database is where the data is stored, and any meaningful strategic discussion about credit card security must address database use for data processing and storage. A discussion of tools is meaningful only when it is placed into context of your data security strategy. And as far as strategy goes, replacing the numbers with tokens is your best best, though the options discussed here can offer a highly secure alternative.

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