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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 11/19/2020
New Proposed DNS Security Features Released
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/19/2020
How to Identify Cobalt Strike on Your Network
Zohar Buber, Security Analyst,  11/18/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: A GONG is as good as a cyber attack.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25660
PUBLISHED: 2020-11-23
A flaw was found in the Cephx authentication protocol in versions before 15.2.6 and before 14.2.14, where it does not verify Ceph clients correctly and is then vulnerable to replay attacks in Nautilus. This flaw allows an attacker with access to the Ceph cluster network to authenticate with the Ceph...
CVE-2020-25688
PUBLISHED: 2020-11-23
A flaw was found in rhacm versions before 2.0.5 and before 2.1.0. Two internal service APIs were incorrectly provisioned using a test certificate from the source repository. This would result in all installations using the same certificates. If an attacker could observe network traffic internal to a...
CVE-2020-25696
PUBLISHED: 2020-11-23
A flaw was found in the psql interactive terminal of PostgreSQL in versions before 13.1, before 12.5, before 11.10, before 10.15, before 9.6.20 and before 9.5.24. If an interactive psql session uses \gset when querying a compromised server, the attacker can execute arbitrary code as the operating sy...
CVE-2020-26229
PUBLISHED: 2020-11-23
TYPO3 is an open source PHP based web content management system. In TYPO3 from version 10.4.0, and before version 10.4.10, RSS widgets are susceptible to XML external entity processing. This vulnerability is reasonable, but is theoretical - it was not possible to actually reproduce the vulnerability...
CVE-2020-28984
PUBLISHED: 2020-11-23
prive/formulaires/configurer_preferences.php in SPIP before 3.2.8 does not properly validate the couleur, display, display_navigation, display_outils, imessage, and spip_ecran parameters.