Embracing Tokenization: Payment without Pain

By Larry Wine, CEO, Paymetric

Today, it’s expected that merchants accept electronic payments. It’s more than expected that those payments are secure. No data leaks or breaches of any kind. The reality is many companies don’t truly understand the security vulnerabilities that electronic payments present… nor the solutions on the market. They may think they are secure, but in fact are at great risk.


The Payment Card Industry Security Standards Council (PCI SSC) has tightened compliance requirements, initially with their Data Security Standards (PCI DSS). Ever tightening, the compliance rules will become more stringent again in 2010. As a response, the industry has been flooded with solutions claiming to provide heightened security for a merchant's data. Undoubtedly, and often blindly, merchants invest in these offerings. In most cases out of fear, uncertainty and doubt. What companies don’t get is that most of these solutions are not bullet-proof.

Since companies think they are compliant and are indeed not, they are at risk for a breach or an audit resulting in hefty fines that could bring them to their knees. Unfortunately, most find out the hard way.
What can help? In my view, tokenization is the answer. A solid tokenization solution can take companies into a safe harbor and remove all navigational stress from its shoulders.

According to the recent Gartner Group report, “Using Tokenization to Reduce PCI compliance Requirements,” “enterprises that have successfully implemented tokenization … have reduced the scope of …costly PCI compliance audits while keeping sensitive cardholder data more contained and secure.” So what is tokenization, really? The bottom line is that tokenization is a technology that leapfrogs the better-known, traditional encryption. Sensitive data is removed from enterprise systems and, as an added bonus, the technology is complimentary to legacy enterprise systems.

Drilling down, tokenization affords companies the opportunity to eliminate the storage of sensitive information. This cutting-edge technology works by intercepting cardholder data entered into an enterprise payment acceptance system like a Web store, CRM, ERP or POS, and replacing it with a surrogate number known as a “token,” a unique ID created to replace the actual data associated with a specific card number. Put more simply, tokenization is different from any other security solution dealing with PCI issues because it’s “waterproof” vs. “water resistant” (encryption).

Tokenization offers the following two key benefits:1. Software as a Service (SaaS) model ensures no customer card data resides within company systems2. cost effectiveness and savings

1. Benefits of SaaS: Get It Out of My HouseWith a tokenization solution outsourced via a SaaS model and a reputable vendor, cardholder data never resides in the merchant’s environment. The premise and theory behind encryption remains true – protect sensitive data with complex encryption algorithms wherever sensitive data is stored. Tokenization takes the same principle to a new level: protect sensitive cardholder data by removing it from merchant systems entirely. Quite simply, merchants do not need to encrypt what they do not store. Let someone else shoulder the information.

By eliminating the storage of sensitive cardholder data through a SaaS tokenization solution, merchants can realize a multitude of financial, operational and security advantages over traditional enterprise encryption solutions. A tokenization solution requires minimal upfront capital expenditure, if any. And it saves on the back-end, too, by preventing costly breaches. If thieves know you don’t have any valuable data they have no reason to break into your systems. And, let’s pretend the worst happens and someone figures out someday how to hack a token – the breach would be extremely limited. If an attacker somehow bypasses both the token and encryption, they will have access to only one card number.

2. Cost Savings: Protecting the Brand and the Bottom LineAccording to Gartner Group, a company with 100,000 customer accounts spends $6 per account to roll out encryption appliances. A separate encryption solution is required for each place where credit card data is stored. In a large enterprise, there can easily be 10 or 20 systems. Do the math -- that could add up fast.

In contrast, by transferring all card holder data out of your systems, a company eliminates capital expenditures. It’s a simple premise: The less data there is onsite, the less it costs to keep it secure. This will also reduce the complexity of a company’s PCI audit. Because the merchant no longer stores cardholder data, they will be removed from the scope of PCI Requirement 3, reducing the number of questions needed to answer on the audit.

All in all, tokenization greatly reduces risk of breach, operational expenses and bad PR – all of which ultimately saves money.

Finding the Shoe that Fits: Tokenization Solution
In conclusion, if a company carries confidential cardholder data, we strongly recommend getting it out of the system and onto a reputable vendor’s. To choose a vendor, make sure they have expertise and execution experience. Tokenization vendors must be thoroughly vetted, since they will become mission-critical business partners. There is no doubt there is a solution for every company. But you must pick the right partner that can fulfill all the company’s requirements while understanding its level of size and complexity.

With an eye towards the future, Paymetric’s Data Intercept Solutions for XiSecure On-Demand takes tokenization to the next level by ensuring that sensitive cardholder data never enters the enterprise payment acceptance system. Sensitive information is intercepted and tokenized at the the time of sale. The secure token then routes back to the merchant for authorization and settlement. Data Intercept Solutions, using tokenization, offer the ultimate breach protection, while dramatically reducing the cost and effort to achieve PCI compliance. And the process is entirely transparent to the customer.

Tokenization is the answer to security, cost savings and general peace of mind ... just be sure to ask the right questions.

Tokenization as a means of securing credit card numbers

By: Eric Bushman,Vice President of Solutions Engineering, Paymetric. Inc.

My previous blog post titled Securing credit card account numbers in SAP focused on implementing functionality provided by SAP for encrypting credit card numbers stored in the SAP ERP database. In an update I also included a brief reference to encryption functionality in the SAP CRM database. FAQ OSS notes mentioned in the post provide the necessary information to implement the SAP standard encryption functionality and thus secure the payment card and credit card numbers stored in your SAP applications.

At the end of the post I mentioned several items that you should be aware of when implementing the standard SAP functionality which may prevent compliance with PCI DSS requirements. I then alluded to Tokenization as a means of addressing the additional items. In this post I want to explore the differences between SAP's standard encryption offerings in each application and tokenization as an application independent encryption approach.

Many applications provide encryption functionality which is specific to that particular product. SAP's encryption offering for credit card numbers in the SAP ERP and CRM applications is one such example. The encryption functionality is designed to work only with that application - specifically by encrypting the credit card number data stored in the database. Should data need to be passed between applications, such as order data being replicated from the SAP ERP to SAP CRM system, the data must be decrypted in the source application passed in an unencrypted form (and therefore potentially logged in an unencrypted format) and finally encrypted in the target application. Using this application specific encryption approach has the following weaknesses:

• Encryption solutions on each application must be setup, maintained and managed
• Encryption keys in each solution must be managed independent of other solutions
• Encryption keys must be rotated independently of other solutions
• Increased number of encryption solutions require additional IT staff time for management and maintenance
• Disparate encryption solutions increase security risks if maintenance is not always kept current
• Encrypted data must first be decrypted before being passed to other applications and then re-encrypted before being stored by the target application

A typical enterprise with an SAP system, a web store and a payment application each storing encrypted credit card data locally using application specific encryption applications would have an architecture which look like this:

Implementing a solution which Centralizes and Tokenizes the credit card number data in a secure data vault would change the architecture to look like the following:

This solution would extract the unencrypted card numbers from the various applications, consolidate the application specific encryption functionality into a single, central solution and would simplify key management and key rotation functions. Centralization and Tokenization would specifically help address the following PCI DSS requirements:

Additional advantages to this approach would include the following:

• One centralized storage location of all encrypted credit card number data
• All applications would store tokens at the database level rather than unencrypted or encrypted card numbers - Security At Rest
• All application interfaces could pass tokens rather than encrypted or unencrypted card numbers - Security In Transport
• Rotation of encryption keys would be performed centrally and would be transparent to other applications as the tokens would remain unaffected
• Centralized logs can be kept of all decryption attempts from all source systems thereby providing a valuable audit trail
• If an external, third-party solution is used the risk of data loss in a breach of internal systems is greatly diminished - only tokens would compromised, not the encrypted data or encrypted keys
  

Finally, let's take a look at how the workflow of processing of a credit card authorization would look in an enterprise using SAP along with a Centralization and Tokenization solution:

As enumerated above, there are clearly many advantages and benefits to using a token-based solution for securing credit card details not only in SAP by across the enterprise. The token-based approach is currently not supported by standard SAP functionality, but is supported by solutions from third-parties like Paymetric.

As scrutiny increases surrounding how companies are securing sensitive customer data, such as credit card numbers, serious consideration should be made of token-based solutions. Merchants who choose to outsource the storage of this sensitive data have less risk of embarrassing data loss in the event of a system breach as only tokens would be stored locally. All encrypted data and keys would be stored by the external solution this greatly diminishing a Merchant's exposure and potential public relations nightmare.

Securing Credit Card Account Numbers in SAP

By: Eric Bushman, VP of Solutions Engineering, Paymetric, Inc.

You may have heard about or read the following stories in the news recently:
A major retailer's systems are infiltrated by hackers in a parking lot taking advantage of security weaknesses in corporate Wi-Fi networks and credit card data is compromised
Laptops containing records of credit card numbers, sensitive HR data or personal medical records have gone missing or have been stolen.

Disgruntled employees caught downloading databases of payment information (including credit card details) and selling the information through internet black market channels
While stories like these are likely to continue to periodically appear, there are steps which you can take in your SAP systems to protect your customer's sensitive data and mitigate your liability in the event a breach should occur.

Many of SAP's products contain business logic for processing payment cards. Each of these products stores a record of the credit card data used to process the authorization requests and also the details of the authorization response. This information, stored in the database of the SAP products, should be secured through some means of encryption or tokenization to prevent unauthorized users from gaining access to unencrypted credit card details.

A good first place to start is with the encryption logic offered by SAP in each product. In the R/3 system a good place to start learning about the credit card encryption functionality is OSS note 766703. This note is an FAQ describing the functionality provided natively by SAP for securing credit card numbers and is applicable for versions 4.6C, 4.7, ECC 5.0 and ECC 6.0. For SAP ERP 6.0 specifically, note number 1032588 describes additional functionality provided in this release related to masking of card numbers, security objects for viewing decrypted card numbers, logs of decryption events, migration and conversion programs for existing unencrypted credit card account numbers stored in various database tables, etc.

Application of these notes (and the additional notes referenced in 766703 and 1032588) and the setup of the appropriate SAPCRYPTOLIB security library as described in OSS note 662340 will allow you to activate the standard SAP functionality for securing credit card account numbers in R/3 or SAP ERP 6.0. The following functionality will then be active:
Ability to generate .pse (Personal Security Environment) files containing encryption keys with the SAPCRYPTOLIB security library.

Encryption, during Order Save, of credit card account numbers stored in table FPLTC and related to Authorization REQUEST and RESPONSE lines.
Encryption, during Accounting Document Save, of credit card account numbers stored in table BSEGCC and related to Authorization RESPONSE lines used for billing, copied to Accounting and staged for Settlement processing.

Encryption, during Customer Master Save, of credit card account numbers stored in tables VCKUN and VCNUM in relation to the Customer Master record.
Storage of the encryption strings representing the credit card account numbers in SAP table CCARDEC. NOTE: There will be 2 records added to table CCARDEC for each corresponding record in FPLTC, BSEGC, VCKUN or VCNUM.

Addition of Security Activities to various Security Objects used to control decryption of credit card account numbers while viewing payment information on Invoices, Accounting documents, Customer Master Records, etc. See OSS notes previous referenced for exact details.Implementation of these OSS notes and encryption functionality available in standard SAP will provide a merchant protection for credit card account information stored within the SAP database. However, a merchant should also be aware of the following:
The .pse ((Personal Security Environment) files need to be copied across all Application Servers and are accessible to anyone with access to the file system of the Application Servers.
The additional encryption string data stored in the CCARDEC table adds a significant amount of data to the SAP database and must be accounted for when sizing storage requirements.
Encrypted credit card account numbers must be decrypted prior to and Authorization Request, Settlement submission or replication of Order or Customer Master Data to a CRM system.
For key rotation activities, SAP's current conversion programs require full decryption of all encrypted records prior to generation of new .pse files and subsequent re-encryption of all records. This will require a maintenance window of perhaps several hours during which no Order Processing, Billing or Settlement submission activities should take place to avoid any decryption errors.

If Process Integration (PI) is used as a middleware for Payment Card Processing then the PI logs may be capturing unencrypted credit card account numbers in violation of the PCI-DSS rules.

Can these additional issues be overcome as well? Yes!

The next blog entry will discuss the concept of Tokenization of credit card account numbers and the advantages of Tokenization over the encryption logic currently available in standard SAP business logic.