This blog entry is also being hosted over on the ITWorldCanada site.
Thank you ITWorldCanada.
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
With no data to steal, any breach would prove fruitless.
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
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
Also Read My: PCI DSS Cloud Computing Guidelines – Overview
No comments:
Post a Comment