PCI Scope Reduction by Using Tokenization

PCI Scope Reduction by Using Tokenization

Tokenization techniques are rapidly evolving to address PCI scope reduction efforts and securing cardholder data from breaches.

PCI scope reduction is integral in simplifying PCI compliance and reducing risk overall in the environment. Effectively minimizing attack surface area and limiting the number of systems assessed to PCI standards, scope reduction is crucial. The issue of PCI scope and maintaining PCI compliance persists as long as credit cards are accepted, irrespective of the payment method.

Scope Reduction Potential of Tokenization

Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply. – A quote from PCI SSC

Replacing cardholder PAN data with tokens in business systems prevents hackers from accessing tables containing both customer information and PANs. Tokenization ensures that, in the event of a breach, a hacker can only retrieve customer information and meaningless tokens. In typical implementations, PANs are securely stored in a Vault system with encrypted credit card information. The only conceivable attacks involve breaching the tokenizing system to retrieve PANs for each token or inducing the system to respond to a query for PAN, both highly challenging for hackers. Properly segmented, the tokenization system and connected systems are the only ones in scope, simplifying PCI compliance and enabling scope reduction.

How Tokenization Works

When cardholder data is received by the merchant and needs to be stored, the system initially processing the data makes a call to a tokenization system supplying the cardholder data as parameters. The tokenization system may be local or remote to the merchant’s systems. A pseudo call might look like this:

Token = CallFunctionGiveMeaToken(PANnumber);

The calling system receives a token from the tokenization system and subsequently uses it, based on the PAN number parameter passed into its code titled CallFunctionGiveMeaToken. The tokenization system takes the sensitive data and either stores it and associates the storage cell with the token (called “vault” storage) or the tokenization system can use an encrypted value of the sensitive data as the token.

To retrieve cardholder data, a system can make a query to the tokenization systems by providing the token parameter. The tokenization system then returns the sensitive data. The tokenization system either retrieves the data from its secured storage or decrypts the token, derives the data, and returns it to the calling system.

Tokenization systems are complex and secure operation is key to success in tokenization. Clearly, any system querying for sensitive data must undergo authorization and authentication. Additionally the system, communications channels, querying system, encryption, key rotation and data store must be secure. Beyond just the application logic, addressing many security factors is essential. Therefore, third parties that specialize in creating these systems typically produce and manage most tokenization systems.

Tokenization Concepts

• Tokenization — It utilizes a “token” to replace cardholder data records, referring to the sensitive data. Encrypt and store the data in a separate, secured location referred to as a “vault,” or store the data in an encrypted form by systems utilizing tokens.
• Vault Based Tokenization — It stores encrypted data that corresponding tokens can index.
• Encryption Based Tokenization — Mathematically reversible tokenization provides a secured function that can encrypt the PAN and return a token or accept a token and return the PAN data. The system does not store sensitive data or encrypted data. The tokenization system is an “encryption engine”.
• Tokenization Reduces Cardholder Data Exposure:
  • Tokens widely replace cardholder PAN data, significantly reducing the attack surface area.
  • Systems use tokens in place of sensitive cardholder data, retrieved when customers input data.
  • Cardholder data retrieval is possible from the tokenization system for business operations.
  • Vaults, if used, become primary attack targets, demanding secure communication and meticulous design.
  • While risk surface areas decrease, they still exist, emphasizing the importance of network segmentation for PCI Scope.
  • Applications require adjustment to handle tokens, and processes for cardholder data retrieval should be defined and implemented.
  • Rekeying tokens is crucial for PCI compliance but can be technically challenging.
  • When employing multiple “vault” architectures, consider issues related to duplicate tokens and potential problems.
  • Switching tokenization systems is time-consuming and costly, with challenges once chosen.
  • “Single-use tokens” represent PAN data in a single transaction, while multi-use tokens span multiple transactions.
  • PCI DSS prohibits tokenizing CVV, track, or PIN data for compliance.
  • Tokens cannot resemble PAN, having the same length but not permitted to pass a Luhn check.
  • Tokenization systems must provide a method for deleting old data (tokens and PAN) to comply with PCI data retention requirements.

Implementation Types

1. Local Merchant Tokenization– cardholder data is stored by the merchant – not the tokenization service provider’s systems.

• A system can retrieve PAN data by submitting the token to the local tokenization API through an integrated “request” with the merchant applications.
• Properly authenticate and authorize API calls, ensuring their execution over a secured internal communications channel.
• Local tokenization provides more merchant control over the processes and cardholder data storage.
• No external communication is necessary, thus minimizing risk and exposure.
• The ideal architecture is to have one tokenization system to limit risk areas and secured information synchronization is simplified.
• Include the merchant’s development processes within the scope.
• The merchant can change the tokenization systems at will.

2. Tokenization Service Provider (TSP)– utilizes an external service provider to store and process the PAN.

• When submitting cardholder data, the external tokenizing entity returns a “token” (often referred to as a “Reference ID”) to the business entity requiring a reference to the cardholder data but avoiding storage of the actual data.
• The merchant or business entity uses the token in their applications.
• For later business operations, the business entity can optionally request the cardholder data by submitting the token in a request to the remote tokenizing service provider.
• The organization must securely communicate with the TSP outside the organization.
• Authentication and authorization must be secure and adds complexity.
• The merchant has to monitor and adapt to the third party tokenization system changes and updates.
• The TSP must provide good implementation and management documentation.
• Once the merchant’s systems are filled with tokens instead of cardholder data, the third-party lock-in poses challenges for changing tokenization systems.

Tokenization Conclusions

Recommend reducing the PCI scope by minimizing the attack surface of cardholder data through tokenization. Utilize this approach in conjunction with proper network segmentation to achieve significant PCI efficiencies and enhance network security. Although tokenization systems are complex, they usually have an exceptional return on investment due to reducing PCI compliance effort all the while of minimizing loss in the event of a breach. Finally, it sure would be nice to only have to worry about a few systems at night opposed to an entire data center.

Written by: John Elliott
John has been a security consultant and security software programmer since graduating with honors from the University of Colorado. Since joining DirectDefense, John provides world-class security consulting services to DirectDefense clients while providing development skills for our application assessment services.

Prior to joining DirectDefense, John worked for Accuvant and Trustwave LABS. While there, he focused his efforts on application security by performing comprehensive PA-DSS application assessments, code reviews and PCI DSS assessments. Before that John has worked for Hewlett Packard, PentaSafe (acquired by NetIQ) and Peregrine Systems designing and developing security tools.

   By: John Elliott   03.28.16