Tokenization as a companion to Encryption

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

(This article first ran in ITworld Canada in October 2014) 

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

(Also read my:  Toronto based PCI Compliance upstart brings single solution to Voice-Web-POS)

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
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
Blueline Tokenization Infrastructure and Tokenization as a Service 

PCI DSS Cloud Computing Guidelines - Overview

The PCI Security Standards Council  has just published (02'07'2013) an Information Supplement: 

 PCI DSS Cloud Computing Guidelines



According to their press release:

"One of cloud computing’s biggest strengths is its shared-responsibility model. However, this shared model can magnify the difficulties of architecting a secure computing environment," said Chris Brenton, a PCI Cloud SIG contributor and director of security for CloudPassage. "One of this supplement’s greatest achievements is that it clearly defines the security responsibilities of the cloud provider and the cloud customer. With PCI DSS as the foundation, this guidance provides an excellent roadmap to crafting a secure posture in both private and public cloud."

So, first things first: 

This is an information supplement, not intended to replace the PCI Data Security Standard (DSS), but rather to enhance the work done during the development of the Virtualization Guidelines in June of 2011. They have acknowledged the move toward Cloud Services, and have created a set of guidelines to allow businesses to remain PCI Compliant while moving their workloads to the Cloud.

To diferentiate roles and responsibilities between Cloud Customer and Cloud Service Provider, the PCI Security Standards Council leverages the definitions of Cloud Computing provided by NIST to outline the common deployment models:

• Private cloud. The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
• Community cloud. The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.
• Public cloud. The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.
• Hybrid cloud. The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds).

Within each of these you would have service models  (Software As A Service SaaS, Platform As A Service PaaS, and Infrastructure As A Service IaaS).

They then clearly define the relationships between Customer and Service Provider.  Of particular note:

The level of security responsibility across the cloud service models generally migrates towards the client as the client moves from a SaaS model (least client responsibility) to an IaaS model (most client responsibility). The greatest level of responsibility for the CSP to maintain security and operational controls is present in the SaaS service model.

  

They then thoroughly discuss the PCI related responsibility each side may have from the physical data center of the provider, through the network, storage, virtualization layers, Operating System, Application Stack, presentation layer, and finally data. The following table is one of the examples they provide:

As expected, considerable care is placed around the discussion of segmentation.

It is the Customer's responsibility to ensure that the Cloud Service Provider has adequately provided "an equivalent level of isolation as that achievable through physical network separation."  Critical to this discussion is the isolation of each layer (network, virtualization, Operating System, and Data)  from other Customers of the Provider. 

Once any layer of the cloud architecture is shared by CDE (Cardholder Data Environment) and non-CDE environments, segmentation becomes increasingly complex. This complexity is not limited to shared hypervisors; all layers of the infrastructure that could provide an entry point to a CDE must be included when verifying segmentation.

Recommendations for minimizing and simplifying PCI DSS scope in a cloud environment include:

Don’t store, process or transmit payment card data in the cloud.

Failing that:

• Implement a dedicated physical infrastructure that is used only for the in-scope cloud environment.
• Ensure Segregation of CDE and non-CDE environments
• Ensure Segregation of Service Provier Customers
• Minimize reliance on third-party CSPs for protecting payment card data.
• Do not transmit data in clear text
• Do not store data in clear text
• Maintain control of your encryption keys (isolate encryption/decryption/key management from your cloud)
• Validate PCI DSS controls regularly

  There are several case studies described in the document to assist in understanding the accountabilities/responsibilities in various Cloud Provider models.

All in all, this is a clear and concise read which go to great lengths to help assess the requirements to meet when selecting a Cloud Service Provider to support your PCI environment.