Friday, June 23, 2006

A Better Mousetrap - Tokenization - Part 2

This is Part 2 of a three part series on tokenization and how it can be used to help secure payment processing. Part 1 described what tokenization is and how it is stronger than encryption for storing card information. This part details which sections of the various card association security programs tokenization addresses and how it simplifies compliance. Part 3 wraps it all up with real world examples on how tokenization is used.
Here I will detail three security programs (actually one or two depending on how you look at it, read further): Card Holder Information Security Program (CISP), Payment Applications Best Practices (PABP) and Payment Card Industry Data Security Standard (PCI/DSS). While other card associations may have their own security programs, most of the major associations recognize these three security programs as the standard.
I'll note that I am detailing the USA version of these security programs and where tokenization applies. There is also an International equivalent, Account Information Security (AIS). From what I have read, the programs are similar, but I have not directly compared the differences between the two but the same advantages should apply. Please note that the advantages described here are from the viewpoint of the POS application vendor or provider, though merchants reading this post will see the benefits of using tokenization techniques.
Card Holder Information Security Program (CISP)
CISP is an all-encompassing, ever-changing, security program. PABP and PCI/DSS are parts of CISP. I originally mentioned CISP as a separate program because of the confusion in the industry. Many people see "CISP" come in from one direction and "PABP" or "PCI/CSS" from another direction so in their minds, these are simply "Additional security mandates I must comply with." In reality, they are all requirements of the same program focusing on different aspects but with a common theme: cardholder information security.
Payment Applications Best Practices (PABP)
This part of CISP focuses on application and merchant security best practices. While these are called "best practices," in reality, they are requirements that the applications used by the merchant and the policy set by the merchant must meet or exceed.
For brevity, I will only detail the top-level requirements and I will highlight the requirements that tokenization either fully addresses or helps address. Each of these top-level requirements is a group of rules pertaining to the topic and I encourage you to read the complete PABP requirements. A fully certified Shift4 API addresses many of these requirements but, for the purposes of this article, I will only highlight the items addressed by tokenization
PABP Requirements
  1. Do not retain full magnetic stripe or CVV2 data.
  2. Protect stored data.
    Here is where tokenization excels. As I hope I have shown in Part 1, tokenization is stronger than encryption.
  3. Provide secure password features.
  4. Log application activity.
  5. Develop secure applications.
  6. Protect wireless transmissions.
  7. Test applications to address vulnerabilities.
  8. Facilitate secure network implementation.
  9. Cardholder data must never be stored on a server connected to the Internet.
    With tokenization, you are not storing card information so you are free to store tokens anywhere, either encrypted or plain text.
  10. Facilitate secure remote software upgrades.
  11. Facilitate secure remote access to application.
  12. Encrypt sensitive traffic over public networks.
  13. Encrypt all non-console administrative access.
Payment Card Industry Data Security Standard (PCI/DSS)
This part of CISP focuses on data center and merchant security. These rules are divided into 12 sections and are sometimes called the digital dozen. All merchants should strive to meet the requirements of these rules but only certain merchants (like processors and gateway providers, larger merchants and merchants that have been hacked) must undergo a third party audit for compliance, usually annually. As a merchant, if you are a widely known national or international merchant, I recommend that you have annual audits to offset some potential risks if your security is breached. With tokenization these risks are reduced even more, possibly eliminating the risk altogether.
For brevity, I will detail the top-level of the digital dozen and where and how tokenization addresses them. Each of these top-level requirements is a group of rules pertaining to the topic and I encourage you to read the complete PCI/DSS requirements. As I did when detailing the PABP requirements, I will highlight the requirements that tokenization either fully addresses or helps address. And just like with PABP, a fully certified Shift4 API addresses many additional requirements, but I will only highlight the items addressed by tokenization
PCI/DSS Requirements
  1. Install and maintain a firewall configuration to protect data.
  2. Do not use vendor-supplied defaults for system passwords and other security parameters.
  3. Protect stored data.
    Same requirement as in PABP so the same advantage - Here is where tokenization excels.
  4. Encrypt transmissions of cardholder data and sensitive information across public networks.
  5. Use and regularly update anti-virus software.
  6. Develop and maintain secure systems and applications.
  7. Restrict access to data by business need-to-know.
    Many of the "need-to-know" requirements are met if only the tokens are stored as they do not contain sensitive cardholder information nor can they be used to access this information.
  8. Assign a unique ID to each person with computer access.
  9. Restrict physical access to cardholder data.
    If only tokens are stored, then restricting access to cardholder data is moot - there isn't any cardholder information.
  10. Track and monitor all access to network resources and cardholder data.
    As with #9, the cardholder data side of this requirement is taken care of when using tokenization.
  11. Regularly test security systems and processes.
  12. Maintain a policy that addresses information security.
While the highlighted items don't seem like much, the non-addressed requirements are mainly common sense or most likely already addressed. The peace-of-mind in knowing that you are not storing cardholder information should be enough to justify the need for implimenting tokenization. Otherwise, throw in the cost of developing and implimenting need-to-know access levels, data usage monitoring and reporting to the POS application and helping merchants define user access policies as required by PABP and PCI/DSS, then the need for tokenization should be evident.
An additional marketing advantage of tokenization is a friendly explanation of how your application secures cardholder data. "The application does not store cardholder information and instead uses tokenization" is much easier to explain or put on a brochure than "The application uses 128-bit Triple DES to encrypt all cardholder data and the encryption keys are securely stored using a hard coded encryption key in the registry" (huh, how is that secure?). Or you simply don't mention key storage and hope no one asks!
I have shown you where tokenization fits in the CISP requirements and how it can simplify the compliance for POS vendors and merchants. Please check back for Part 3 of this series where I will give real-world examples of tokenization in action, with pictures! If you have any comments or questions on this topic, feel free to post them. Until next time…

Thursday, June 15, 2006

A Better Mousetrap - Tokenization - Part 1

Back in October 2005, Shift4 announced "tokenization" capabilities in its $$$ ON THE NET product and at the same time release the tokenization technology to the public domain (Shift4 Releases New Technology to Insure the Security of Its Merchants' and Partner's Payment Processing). Two months later, Dr. Heather Mark, Ph. D., CISSP, published a white paper on the difficulties and weaknesses of encrypting data and the benefit of using a "tokenization" technology (Storing Credit Card Data: A Look at the Business Needs, Regulations and Solutions Surrounding the Issue). In this posting, Tokenization - Part 1, I'll try to define exactly what tokenization is and the benefits it has over data encryption (the primary benefits were covered in Heather's white paper but here I'll try to provide a shorter version). Part 2 will cover how tokenization can ease the burden on POS vendors and merchants to comply with many of the payment security regulations like CISP, PABP, PCI/DSS, etc. Part 3 will give real world examples on how tokenization was implemented in POS and other applications and again reemphasize how tokenization is more secure than storing encrypted data. Other parts may follow based on the how these first three go...

Tokenization - Huh?
Webster's defines token as "Something serving as an indication, proof, or expression of something else". We are using "tokenization" as the process of substituting a unique identifier (a token) for a card number. This token, for all intents and purposes, is a random unique value and has no way to be deciphered to gain knowledge of the associated card information. Instead, the token is used to initiate payment requests or updates of an already existing payment transaction (voiding a sale, flagging an auth only transaction as a sale, etc.).

I use strong industrial strength encryption – Where's the weakness?
There are several very strong encryption technologies available: triple-DES, AES, Blowfish, RSA, etc. Ignoring any inherent known or unknown weaknesses of one encryption method over another, all these technologies have the same weakness: key storage. The theory behind securing data using encryption is simple: scramble the data to make it unusable for unauthorized use. Encrypting the data (making it unusable) and decrypting the data (returning the data to it's original & usable state) requires keys - a key to lock the data, a key to unlock the data. With most of the encryption techniques, the same key is used to lock and unlock the data. The problem is: How do you secure these keys in the POS application? Once these keys are compromised, the "secured" data is no longer secure.

This problem of securing the keys is very difficult in a compiled POS application and is all but impossible in a shared web-hosting environment that many web sites use. A common technique that POS vendor's use to secure the keys is to encrypt (a catch-22) these keys using a hard-coded password that "only the application knows". In a compiled application, obfuscation (hiding) techniques can be used to give a reasonable level of confidence that the keys are secure. On the other hand, most web sites use scripting languages and hiding the hard-coded encryption keys in these scripts is very difficult.

How is tokenization stronger?
The best way to secure data is to not store the data. This is the theory behind tokenization. The token can be used for initiating new transactions or modifying existing transactions, but beyond this context, it is useless data and there is absolutely no chance it can be used to gain knowledge of the real card information.

Let's assume a worst case scenario: Your Xyz Application data files are not secured in anyway, no encryption techniques have been used, and these files have been given to the world. Obviously, if full card information were stored in these files, you would be in a world of hurt with your customers, your bank, the card associations and quite possibly government and/or law enforcement officials.

Keeping with the worst case scenario: Even if Xyz Application encrypted the card information in these data files that were distributed worldwide, the card associations as well as several states have enacted laws that would require you to notify your customers of the breach because the data can potentially be decrypted. Sure, the data might be securely encrypted, but how confident are you that given enough attention by a dedicated hacker, the decryption keys won't be compromised? In other words, even if encryption techniques are used, merchant reputation wise, you are still in a world of hurt.

Continuing with the worst case scenario: Your Xyz Application stores the token instead of the sensitive card information and these data files are again distributed, it does not matter if they were encrypted or not, no card information was compromised. Your customers do not need to be notified of a breach based on the compromise of card information. Obviously, you may still have to notify your customers or officials based on other sensitive or personal information stored in these files, but not as far as the payment regulations are concerned.

Shift4 released the tokenization concept to the public domain in the hopes that other gateways and possibly even the card associations will embrace the technology, making for a more secure industry as a whole. This posting, part 1, is very generic and non-Shift4 specific. With parts 2 & 3, I'll try to be a generic as possible but they will most likely include sections that detail Shift4's implementation of tokenization.

Here I've tried to briefly describe what tokenization is along with how & why it is stronger than encryption when it comes to the storage of credit card or any payment information. If you have not already done so, I urge you to read the white paper by Dr. Heather Mark - she has a lot more experience writing on the topic of security so she might explain concepts better than I.

Please feel free to comment. Check back later for parts 2 and 3 and maybe more…

Wednesday, June 14, 2006

At last. I finally made the step to start my own blog. I have posted my unsolicited opinions on many forums and have now decided to create my own spot to spew forth these payment tidbits. Enjoy!