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.

Perimeter

4/20/2010
05:05 PM
Adrian Lane
Adrian Lane
Commentary
50%
50%

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3656
PUBLISHED: 2019-12-10
JBoss KeyCloak: XSS in login-status-iframe.html
CVE-2013-0293
PUBLISHED: 2019-12-10
oVirt Node: Lock screen accepts F2 to drop to shell causing privilege escalation
CVE-2013-1793
PUBLISHED: 2019-12-10
openstack-utils openstack-db has insecure password creation
CVE-2013-2095
PUBLISHED: 2019-12-10
rubygem-openshift-origin-controller: API can be used to create applications via cartridge_cache.rb URI.prase() to perform command injection
CVE-2019-19698
PUBLISHED: 2019-12-10
marc-q libwav through 2017-04-20 has a NULL pointer dereference in wav_content_read() at libwav.c.