You’re going the wrong way about data encryption if you’re not doing this

For the protection of sensitive data, tokenization is every bit as important as data encryption.

We are all very familiar with the requirement to encrypt sensitive data at rest as well as in transit.  We have many tools that perform these functions for us. Our database systems allow for encryption as granular as field, or as course as table or entire database.  Network file systems likewise allow for various degrees of encryption.  All of our tools for moving, viewing, editing data have the ability to transport data encrypted via SSL/TLS or SCP.

Encryption, however, is intended to be reversed.  Sensitive data is still resident in the filestore/database, but in an obfuscated  manner, meant to be decrypted for later use.  Backups of your data still contain a version of your original data.  Transaction servers working on this data may have copies of sensitive data in memory while processing.  Recently we saw in the Target breach, that memory resident data is not secure if the host is compromised.  Memory scraping tools are among the payloads commonly delivered in a malware incursion.

As long as the valuable sensitive data such as Personally Identifiable Information (PII) or Payment Card Industry (PCI) resides in your facility, or is transmitted across your network, there is reason for a malicious threat agent to want to breach your network and obtain that information.

Additionally, the cost and time involved in regulatory compliance to ensure and attest to the security of that sensitive data can be daunting.   For PCI data, there are 12 rigorous Payment Card Industry Card Data Security Standard (PCI DSS) requirements that have to be signed off on annually.

For the rest of this discussion, I’m going to focus on credit card (PCI) data, as it is nearest and dearest to my field of experience, but the process is similar regardless of the type of sensitive data.

Tokenization is not encryption

Tokenization completely removes sensitive data from your network, and replaces it with a format preserving unique placeholder or  “token”.  You no longer store an encrypted copy of the original data.  You no longer transmit an encrypted copy of the original data.  Transaction servers no longer keep a copy of the sensitive data in their memory.

With no data to steal, any network breach would prove fruitless.

The token value is randomly generated, but typically designed to retain the original format, ie: Credit card tokens retain the same length as a valid credit card number, and pass the same checksum validation algorithm as an actual credit card number, but cannot be reverse engineered to acquire the original credit card number.

Don’t get me wrong, the actual data does get stored somewhere, but typically in an offsite, purpose-built, highly secure, managed and monitored vault.

In the case of PCI compliance, this vault and it’s associated security mechanisms are the only infrastructure that requires review/attestation.  The rest of your network, including the transaction servers become outside the scope of review.

Neither Tokenization nor Encryption is a silver bullet in and of itself, but the appropriate mix of each will greatly reduce your overall risk exposure, and potentially keep your name off the next Breach Report.

Also Read:  PCI DSS Cloud Computing Guidelines – Overview


Securosis: Tokenization Guidance: How to reduce PCI compliance costs

PCI Security Standards Coucil: PCI Data Security Standard (PCI DSS)

Securosis: Tokenization vs. Encryption: Options for Compliance, version 2 

Cardvault: Credit Card Tokenization 101 – And Why it’s Better than Encryption

3 Core PCI-DSS Tokenization Models- Choosing the right PCI-DSS Strategy

Encryption and Tokenization

Data Encryption and Tokenization: An Innovative One-Two Punch to Increase Data Security and Reduce the Challenges of PCI DSS Compliance

Paymetric: Tokenization Amplified

Tokenization is About More Than PCI Compliance

Tokenization: The PCI Guidance


Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada
Michael Ball
Michael Ball
Over 25 years in IT, from hardware engineer through software developer and Network Administrator. From Security Architect to CISO at a prominent Canadian Insurance Company. I've managed very large teams, I've managed very small teams.. I've stood alone. But year after year, there's always been something great around the corner to keep me on my game. Specialties: Identity and Access Management Infrastructure and processes, Risk Management, Network Security Architecture.

Featured Download

IT World Canada in your inbox

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Latest Blogs

Senior Contributor Spotlight