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
References:
https://www.pcisecuritystandards.org/security_standards/index.php
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
Paymetric: Tokenization Amplified
Tokenization is About More Than PCI Compliance
Tokenization: The PCI Guidance
