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.

Conclusion
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…