Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


05:05 PM
Adrian Lane
Adrian Lane

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?

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. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
4 Security Tips as the July 15 Tax-Day Extension Draws Near
Shane Buckley, President & Chief Operating Officer, Gigamon,  7/10/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...