02:01 PM

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
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: just wondering...Thanx
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.