Welcome back, and thanks for continuing to read our blog series on reducing PCI Scope. In our last blog we covered why reducing PCI Scope is so important.
Before we address common approaches to Tokenization, let’s recap what PCI DSS Tokenization is:
What is PCI DSS Tokenization?
PCI DSS Tokenization is a means for protecting credit card data by substituting a different, non-encrypted value for a credit card number. Usually this takes the form of random number (with some of the first digits and ending digits preserved) that appears to back end systems to be a valid credit card number.
It is important that the random elements of the token (that is the digits that are not preserved) are not in any way derived from the actual credit card number. [i] This randomized token is stored in a secure vault, which defines the mapping from the PAN to the token.
Common Approaches to Tokenization:
The first choice that merchants must make when embarking upon a path to scope reduction through tokenization is whether to build their own tokenization technology or to acquire it from a vendor (Intel/McAfee is of course such a vendor).
In the past merchants chose to build their own solutions as commercial PCI DSS Tokenization products are relatively new (with formal guidance from the PCI Counsel only appearing in late 2011).[ii]
In order to keep this blog post to a manageable length we will concentrate on the merchant data center rather than addressing both the point of sale locations and the data center in one post. The same principles that apply to the data center are applicable to the retail locations as well. I invite those interested in a subsequent article on point of sale scope to contact me.
Figure 1 below shows reference architecture for retail data centers. It does not represent any particular merchant’s data center, but rather represents a set of common components aligned in a typical architecture. Virtually every retailer has an authorization path for data, a clearing path (that is usually a mainframe with batch processing of results in TLOG or similar formats), and provisions at the point of sale to process transactions in case the internet is not available at the time of the credit card charge.
Figure 2 represents the typical PCI DSS Scope associated with this architecture. Please note that due to the offline requirement for processing credit cards (and therefore the need to store transactional data at the store server), typically most parts (if not all) of the retail locations are in PCI scope.
Figure 2: Typical PCI DSS Scope at a Retailer’s Data Center
Three Approaches to PCI DSS Tokenization Architecture:
There are three common architectural approaches to PCI DSS Tokenization.
1) Monolithic Approach
2) API Tokenization (sometimes called Toolkit Tokenization)
3) In-line Tokenization
The monolithic approach appeals to many as it promises to remove Points of Sale completely from PCI Scope and to bring the data center along for free. This typically involves upgrading and standardizing equipment at the retail locations to allow encryption at the PIN Pad or Register.
Often the acquiring bank is able to decrypt the results ensuring that there is no obvious reason why actual cleartext PAN data may be needed within the enterprise.
This theory is very appealing as it implies it may be possible to remove the entire enterprise from PCI Scope and therefore drastically reduce compliance costs.
Peeling back the onion on Monolithic Scope Reduction:
There are several challenges associated with implementing monolithic scope reduction. Some of them are listed below:
1) Cost Versus Benefit
2) Time to Value
3) Fragility to Change
4) Vendor and bank lock-in (what happens when it is time to renew the contract?)
Cost Versus Benefit:
As the value of monolithic scope reduction depends upon capturing the PAN data and protecting (encrypting or tokenizing) it at every retail device, all retail locations must be upgraded before real scope reduction is accomplished.
For a large retailer with thousands of locations this cost could easily mount to the tens of millions of dollars. Often this does not compare favorably with the value achieved by reducing or eliminating PCI Scope.
Time to Value:
Most large retailers upgrade retail locations on a rolling basis (often on a 5 year or more schedule). Deviating from this schedule is often very difficult.
Therefore, if each retail location must be upgraded (perhaps with new POS terminals and potentially with new software and registers) before significant business value is achieved, then expenditures begin on day one and benefits only begin to accrue at the end of a complete retail refresh cycle (usually measured in years).
Fragility to Change:
The monolithic scope reduction approach depends upon the assumption that the only places that PAN data enters the retailer are controlled directly by the retailer or the data protection vendor and that the only services that must consume the protected PAN data are in direct partnership with the data protection vendor (i.e. The Acquiring Bank has a partnership with the tokenization or encryption vendor such that it is able to derive cleartext PAN data from the protected PAN).
Therefore, no PAN data can make its way into the system in a way that the data protection vendor cannot control and no cleartext PAN data will ever be needed within the merchant’s data centers or retail locations.
Sadly, this is often not the case. Vectors of PAN data into the enterprise can often be sanitized using custom software development (at additional cost and project risk), but the data egress path is often much more difficult to solve.
Imagine that all of the input PAN data is tokenized at the point of sale or other entry into the system (including CRM input, FAX/OCR input, Web Site input, etc.). Now, the back end IT systems need to call out to a fraud detection service to ensure they should complete the transaction.
Commonly these fraud detection services do not accept encrypted or tokenized PAN data, but rather depend upon actual PAN data. Now the enterprise openly needs PAN data in the data center to satisfy this new requirement. PCI Scope is back in the data center. Depending upon where in the architecture PAN data is actually needed, the entire data center may re-enter PCI scope.
Perhaps the bigger risk to change is in the case of a merger or acquisition. Resolving one or more monolithic tokenization strategies with heterogeneous data centers and retail locations makes this problem nearly intractable.
Vendor and Bank Lock-In:
For monolithic scope reduction to function properly there needs to be close cooperation among at least the following entities:
1) The Point of Sale Terminal vendor
2) The tokenization or encryption software vendor
3) The merchant
4) The Acquiring Bank(s)
5) The vendor(s) utilized for credit card authorization.
If any partnership among any of these critical participants breaks down, the entire system may fall apart. What if the tokenization software vendor falls out with the point of sale vendor and the combined solution is no longer supported? What if the merchant wishes to change Acquirer?
This fragility to change has the potential to put a merchant at a large disadvantage during negotiations with any of these partners for new equipment or contract extensions.
Tokenizing at the Data Center:
One of the more common solutions to the difficulties associated with monolithic tokenization is to tokenize at the data center. This does leave the retail locations within scope, but can bring immediate value to the merchant rather than marginal value over a very large time frame associated with the Monolithic approach. Often it is much less expensive up front (as there is no retail hardware and software refresh mandated).
There are two common approaches to tokenizing in the data center:
1) API Tokenization
API Tokenization Explained:
API tokenization modifies existing systems to explicitly request token data from a tokenization vault when PAN data first enters the system. This is typically implemented with a custom SDK or over SOAP based web services. The system would reverse the process before outbound interface to payment gateway or to a payment processor.
Often a proxy server can be used on the front end of the web site to ensure that PAN data is tokenized before entry into Web Servers and that PAN data does not exist in at least some of the e-commerce server infrastructure.
For comparison purposes the architecture is unchanged from the previous example (including the fraud detection web service which requires PAN data).
Figure 3 shows typical PCI Scope for this retail architecture with API tokenization. The e-commerce engine, the authorization engine and the clearing engine have been modified in order to explicitly request tokens and PANs as necessary. Since all of them must have access to PANs (both for input and output for the clearing engine and authorization engine and for connection to the fraud detection web service in the case of the e-commerce engine) they are all within PCI Scope.
The scope reduction is small (the Web Servers and perhaps the E-Commerce engine may be removed from scope if there is no need for actual PAN data inside its bounds) as compared with the cost of the tokenization solution and the cost of modifying existing systems to explicitly request PANS and tokens. The downside of API tokenization is that each application that wishes to tokenize or de-tokenize data must be modified, typically with an SDK, which can mean additional development costs for the merchant.
An alternative is to take a similar approach to tokenization at the data center with one subtle (yet very powerful) change. What if instead of modifying existing systems to implement tokenization and detokenization, we simply add in-line proxies to the data flows that accomplish this same effect?
All back end systems still believe they are operating on PAN data, but actually work on tokens. Data on the way into the data center is tokenized by the secure, high speed proxy and data on the way out of the data center (where PAN data is actually required) is detokenized by the same high speed proxy.
All of the back end data center systems fall from scope immediately.
Please see Figure 4 for an illustration of how In-Line tokenization reduces PCI DSS Scope.
Please note, this same proxy that tokenizes and detokenizes the data often decrypts the PAN data. The proxy therefore can participate in PCI Scope reduction strategies at the retailer that involve encryption (symmetric or asymmetric) or other forms of tokenization at the point of sale.
This approach has many advantages over Monolithic tokenization:
1) Much faster time to value. In-line tokenization can be implemented in months rather than years and immediately begin reducing PCI Scope.
2) Much less expensive: No need to upgrade anything at the point of sale.
3) Much more resilient to change: There are no dependencies upon hardware or software at the point of sale or on specific financial partners (acquiring banks or payment gateways for example).
In-line tokenization is also superior to API tokenization:
1) Much more scope reduction in the data center.
2) Existing systems do not need to be modified as they do not change with In-line Tokenization.
3) Much shorter time to value as it is much quicker to put an inline tokenization solution in place than to modify existing, business critical systems.
4) Much less risk of breaking existing systems in the pursuit of saving money.
5) Often In-line Tokenization solutions are much less expensive (even in terms of lower licensing costs) than comparable API tokenization solutions.
The same proxy that is used to tokenize and detokenize data can also transform data to other formats and other protocols. This can be very important as during a merger, the proxy layer can make newly acquired stores appear to be the same as existing stores to the enterprise to the data center. This same technology can make the data centers of the new owner appear to be the same as the old data centers from the newly acquired retailer. This allows for very quick integration of newly acquired assets and for realizing economies of scale much more quickly after a merger.
In-line tokenization can also be used with existing bespoke tokenization solutions. Instead of having the proxy make a tokenization/detokenization request to its internal service, the proxy broker can simply make a call out to an external service to perform these activities.
This approach of utilizing the proxy to call out to non-native tokenization can even be used with API tokenization products to give them the same advantages of native In-line tokenization (except perhaps the smaller price tag).
There are two primary reasons most merchants evaluate PCI DSS tokenization options.
1) To reduce the cost of PCI DSS compliance (as cost is directly related to scope)
2) To decrease the risk of a data breach.
Given these constraints, we believe that the best option is often to begin at the data center where there is the most value gained with the least effort and then utilize this effort to inform the decision of how best to secure the points of sale.
I encourage you to read additional papers on the subject. At cloudsecurity.intel.com , please consider downloading this popular paper describing how a service gateway can help reduce PCI DSS Scope.
Alternatively, you may enjoy watching Webinar: 3 Core PCI DSS Tokenization Models – Choosing the Right PCI DSS Strategy
Please reach out to me with any questions regarding that arise in your pursuit of a solution for reducing PCI Scope in your organization.
Next I will cover expanding the in-line tokenization concept to general in-line data protection for securing other forms of data including Personally Identifiable Information (PII) and Personal Health Information (PHI).
Tom Burns serves in Intel’s Data Center Software group where he works with many of the world’s top retailers to help increase security and reduce PCI DSS Scope. Tom joined Intel in 2008 and holds a BSEE from Purdue University.
[i] Information Supplement: PCI DSS Tokenization Guidelines: PCI Counsel, August 2011 section 4.1
[ii] Information Supplement: PCI DSS Tokenization Guidelines: PCI Counsel, August 2011