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.

Risk

8/27/2010
02:01 PM
50%
50%

Four Best Practices For Tokenization

Going beyond Visa's best practices guide

With Visa releasing its tokenization best practices guide earlier this summer, security professionals and encryption vendors have debated the strengths and weaknesses of the guide. As one of the most debated topics in encryption-land, tokenization still has a long way to go before it achieves any kind of true standardization of best practices.

Even so, security experts say there are some practices that you can adopt that go beyond Visa's recommendations (PDF). While there is room for discussion about any one of these tokenization suggestions, experts recommend these tips to achieve the best possible security posture for data protection:

1. Randomly Generate Tokens

According to many security experts, the only way to guarantee that tokens are not able to be reversed is if they are generated randomly.

"If the output is not generated by a mathematical function applied to the input, it cannot be reversed to regenerate the original PAN data," Adrian Lane, analyst for Securosis, recently on the topic. "The only way to discover PAN data from a real token is a (reverse) lookup in the token server database. Random tokens are simple to generate, and the size and data type constraints are trivial. This should be the default, as most firms should neither need or want PAN data retrievable from the token."

2. Avoid Homegrown Solutions

While tokenization may seem simple on its face, Ulf Mattsson, chief technology officer for Protegrity warns that "there are more ways to go wrong with tokenization that traditional encryption."

"It's a little bit of rocket science because first you need to generate the tokens, manage the tokens in a good way, protect your token server in a good way and then on top of that you need a normal encryption system with key management that should be compliant that's protecting your token server," Mattsson says.

Mattsson has heard a number of horror stories about homegrown deployments of tokenization that were easily cracked due to the reversibility of the tokens and lack of security around the system in general. "There are homegrown systems out there that are called tokenization and they do not meet the security level of tokenization; in many cases they don't even meet basic security levels for encryption," he says.

3. Protect the Token Server

The Visa standards did start out with a note about the importance of network segregation and keeping tokenization systems PCI compliant, but the importance of securing the token server bears repeating. If organizations fail to secure this server, it can put the whole balance of the token system at risk and render an organization's tokenization investments moot if it is not properly secured.

"In the corner somewhere you have to have a token server which can reverse the (tokenization process)," Mattson. "That server will need to be encrypted with traditional key management and strong encryption. If it's PCI data that it holds, the server needs to be PCI-compliant."

4. Create An Encryption Ecosystem

Over the last year or so, experts have debated whether an organization should choose between end-to-end encryption or tokenization. Many within the card processing world, however, believe that organizations shouldn't be choosing between the two. Each type of technology serves a different purpose: The strength of tokenization is its irreversibility and its ability to play nice with the database infrastructure. Meanwhile, end-to-end encryption helps fill in the gaps as the cardholder data and PANs travel across the rest of the IT infrastructure.

"We believe that tokenization is a prudent strategy when used in conjunction with end-to-end encryption," says Steven Elefant, CIO for Heartland Heartland Payment Systems, which expects to provide tokenization services to its customers later this year as a complement to the encryption services it announced to its customers last fall.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 6/1/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-5334
PUBLISHED: 2020-06-01
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none.
CVE-2019-5335
PUBLISHED: 2020-06-01
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none.
CVE-2019-5336
PUBLISHED: 2020-06-01
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none.
CVE-2019-5337
PUBLISHED: 2020-06-01
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none.
CVE-2019-5409
PUBLISHED: 2020-06-01
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was in a CNA pool that was not assigned to any issues during 2019. Notes: none.