Townsend Security Data Privacy Blog

Every few years since its inception in 2006 the Payment Card Industry Security Standards Council (PCI SSC) has revised and updated the the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA DSS) to improve security for the payment card industry worldwide. These revisions, clarifications, and new points of guidance are based on considerations and recommendations by experts in the field of data security as well as over 700 organizations that process cardholder data. At the end of their review period, the PCI SSC concluded that revisions needed to be made based on these problematic themes in the payment card industry:

• Lack of education and awareness of how to implement and maintain PCI standards - a major problem since the improper implementation of PCI standards leads to data loss and breaches
• Weak passwords and authentication
• Lack of consistency of responsibility when implementing necessary third party security features
• Slow detection of threats
• Inconsistency of PCI assessments¹

Since the release of v3.0 in November 2013, many organizations affected by PCI DSS and PA DSS are asking: Are there new revisions regarding encryption and key management in v3.0, and what do I need to do in order to meet new recommendations, regulations, and best practices? Luckily, much of version 3.0 hasn’t changed from 2.0. However, many important clarifications have been made. In section 3 of PCI DSS (the section pertaining to encryption and management of encryption keys), version 3.0 makes clarifications regarding these aspects of encryption and key management²:

• Stricter controls around the protection and deletion of authentication data
• Key management procedures must be both implemented and documented
• The requirement of PAN masking
• The critical use of dual control and split knowledge
• The mandate that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

Version 3.0 has also split requirement 3.5.2 into two separate requirements to emphasize the importance of both storing encryption keys in a secure location (3.5.2) as well as in the fewest possible locations (3.5.3)²

Based on the themes they found and the revisions made, it is clear that the PCI SSC is moving toward making their regulations stricter. What’s even more interesting is that in this last review, more than half of the recommendations were taken from experts and organizations outside of the United States. This is likely because the United States is farther behind other countries such as the European Union in terms of credit card data security, and since the PCI SSC sets worldwide regulations, they must set standards that meet the highest expectations.

We recommend all organizations worldwide look to the highest standards and follow best practices and recommendations (whether they are required or not) since these evolving requirements are based on current conditions and threats in the data security world and indicate future hardened regulations.

To learn more about encryption key management best practices download NIST Special Publication 800-57 “Recommendations for Key Management: Parts 1, 2 & 3” 

¹ PA-DSS & PCI DSS change highlights

² PCI DSS 3.0 summary of changes

I recently returned from 5th Annual PCI Security Standards Council vendor expo in Scottsdale, AZ.  And rather than returning with a sunburn - after all it was 106 degrees there - I returned with a much better appreciation of what companies are doing to help protect cardholder data.  Every major company that accepts credit cards was at this event.  As a consumer at many of these companies, it made me feel good to know that they take this job seriously and are doing everything they can to keep my information and all of their customers’ information secure.

This was my first time at the event and I enjoyed meeting new people and learned a lot of interesting things. I met with QSA audtiors, customers, potential customers  and vendors.   When asked who Townsend Security was,  I recited my elevator pitch and said “we provide certified encryption and key management solutions to help mid-market customers meet compliance requirements.”  That message was well received, however, as the expo continued, I discovered that people “get” encryption and were more interested in discussing encryption key management.  Many knew key management was something they needed to do and for those that said they were doing something, they wanted to know how they could automate the process.

I spoke with one QSA auditor and asked his opinion on why so many people might be inquiring on this topic and his response, “I have yet to see key management done correctly.” And for companies working on staying compliant,  I think one lady’s response about key management at her organization may sum it up best -- a long pause, accompanied with a rolling of her eyes and a heavy sign saying “it’s not good.”

We know encryption key management isn’t easy, but it is necessary for compliance and to be honest, it is really a best practice for protecting data.  If you are going to go through all the work of encrypting data, then you really should make sure the keys safeguarding the data are also secure.  I talked a lot about our encryption key management solution, Alliance Key Manager (Enterprise and SQL Server editions), at the Expo and thought it would be worth recapping some of the discussion for those who couldn’t be there and are facing encryption key management requirements of PCI DSS.

1) Manage and store encryption keys on a certified appliance.  Our encryption key management solution ensures encryption keys are stored away from the encrypted data, it allows you to satisfy PCI requirements for dual control and separation of duties.  QSA auditors will look to make sure the same person who has access to encrypted data doesn’t have access to encryption keys (dual control).   It is important to restrict access to certain keys by certain users or groups (separation of duties).  You don’t want the same person who has access to encrypted data to have have access to keys that unlock that data.

2) Rotate encryption keys. PCI DSS states that you need to periodically rotate the encryption key. This can be a very time consuming task if done manually and may even be overlooked because it can be a very complex project, depending upon your encryption code. Our encryption key management solution allows you to schedule regular key rotations and enforce your internal security policies while meeting PCI requirements.

3) Log all encryption key activity.  Alliance Key Manager has built in logging, which allows administrators to track all key retrieval, management, and system activity. Reports can be sent automatically to central log management, alerting facilities, or SIEM products for a timely and permanent record of activity.

4) Certification.  Our encryption key management solution is FIPS 140-2 Level 1 certified, ensuring you are effectively managing keys to industry standards.   

5) Don’t let cost be a barrier to meeting compliance requirements. If you have looked at key management solutions, you know they can be costly.  Alliance Key Manager (enterprise and SQL Server editions) are priced with the mid-market customer in mind. I think this was the fact that resonated with people I spoke with the most.  They were happy to hear about a solution that is easy to implement, as well as cost-effective.

We handed out this useful PCI DSS and Key Management matrix at the conference, several people found it useful. Download your copy to learn more about key management requirements. And if your company knows you need an encryption key management solution, give us a call. We are happy to spend a 15-minute technical overview with you and your team to find out how we can help you.

The generation of tokens is an important part of the new PCI SSC guidance on tokenization. Tokens can be generated using a number of techniques including random number generation, encryption, sequential assignment, and indexes. Using tokens to recover the original credit card number must be “computationally infeasible” according to the new guidance.

In this area, I think the tokenization guidance could be much stronger. To the cryptographic community it is well understood how encryption and proper random number generation can produce results that can’t be feasibly reversed using computational methods. The use of indexes and sequential assignment is a lot more “iffy” in my mind. Here is an example: I have a table sorted by the credit card number that contains 100,000 rows. I read the table and assign tokens in a sequential manner.  Are these tokens as strong as tokens generated by a random number generator? Obviously not. Merchants and QSA auditors need to be very careful about a tokenization solution that uses indexes or sequence numbers for token assignment.

The use of encryption to generate tokens should also give merchants some pause for extra thought. First, using encryption may produce tokens that are indistinguishable from normal credit card numbers. The guidance discusses distinguishability of tokens, and if you use encryption to generate tokens you are probably going to have additional work in this area. Secondly, it is not clear yet if tokens generated in this manner will be subject to additional encryption and PCI SSC guidance. The work released today holds open the likelihood that there will be additional guidance for these types of tokens. In other words, the jury is still out on the use of tokens generated by encryption. Lastly, tokens generated by an encryption method almost certainly have to meet all of the PCI DSS requirements for encrypted PAN. It is hard to imagine any other outcome. Merchants will want to be extra careful when deploying a solution that uses encryption to generate tokens.

Lastly, we can expect to see an increase in the number of cloud based tokenization solutions coming to market. The new guidance only touches on this in a tangential way when it discusses the need to carefully review all aspects of a tokenization solution. Since most clouds are based on virtualized environments, I suggest that you read the PCI SSC virtualization guidance from the PCI SSC. It is very hard to see how any of the most popular cloud environments can meet the recommendations of that guidance.

Big kudos to Troy Leach and the members of the tokenization SIG and Working Group who’ve been laboring on this document! The council and advisory committees also deserve praise in nurturing this process. The stakeholders are a diverse community with sometimes conflicting interests. The result speaks well to the management team. I know that we’ll be seeing more work from this group in the future.

Click here for more information on Alliance Token Manager, our tokenization solution and learn how we can help your organization with a certified and comprehensive tokenization technology.

-Patrick

Today the Payment Card Industry Security Standards Council issued some long awaited guidance on tokenization as a method of protecting credit card information (“PAN”, or Primary Account Number in PCI language). This guidance has taken a number of months to produce, and will be very helpful to merchants who want to deploy tokenization solutions to reduce the scope of PCI compliance efforts, for those who have already deployed solutions and need to assess if they meet minimum requirements, and for QSA auditors who have been looking for some guidance in this area.

The link to the guidance is here.

Here are some first thoughts on reading the guidance.

As I’ve been saying here before, a tokenization solution is always in scope for PCI DSS compliance. This means the merchant is responsible for insuring that a tokenization solution itself meets all of the PCI DSS requirements. Whether you create your own tokenization application, or you acquire one from a vendor, it is in scope for PCI DSS compliance and you are responsible for it. The guidance makes this point very clearly. In fact, the guidance makes the observation that tokenization solutions are likely to be the targets of attack because they become a centralized repository of credit card information. Merchants should be very careful that their tokenization solutions meet all PCI DSS requirements and are sufficiently hardened. In my opinion, there are very few merchants who would be up to the task of creating such a solution in-house.

Following on the previous point, a tokenization solution must have encryption and key management capabilities that meet PCI DSS requirements. This means special care in the deployment and implementation of key management. You should be very sure that your key management solution implements proper Dual Control, Separation of Duties, Split Knowledge, and separation of keys from protected data. When acquiring a vendor solution for tokenization look for FIPS-140-2 certification of the key management system – that should be a minimum requirement to indicate the proper implementation of encryption and controls.

Download a recent webcast I recorded that discusses the importance of tokenization and PCI compliance.

Today’s announcement by the PCI Security Standards Council on tokenization is certain to raise awareness about the importance of selecting the right tokenization solution for your organization and ensuring it meets the PCI DSS requirements.  I will be post another article Tuesday that will discuss more thoughts on this new guidance.

I hope you find this helpful.

Patrick