Data encryption seems complicated, and in most cases it lives up to that complexity. This is especially true when encryption requirements go beyond the basics, such as names and passwords, to include highly confidential information like social security numbers, credit card numbers, and protected health information.
The Payment Card Industry Data Security Standard (PCI DSS) is a set of rules that help govern the way credit card information should be handled and protected. Its nomenclature can oftentimes be a bit confusing. So in a short series articles (starting with this one), we’ll break down the most important elements of the PCI DSS as it relates to data encryption.
PCI DSS Requirement 4
Requirement 4.1 of PCI DSS addresses the encryption protocols and instructs any entity that accepts, handles, transmits, or stores credit card data to “use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.” Let’s start with understanding what information is encrypted per Requirement 4. PCI DSS requires that all cardholder data (specifically the cardholder’s name, the card number, expiration date, and billing address) be encrypted when stored or transmitted.
Here are some common questions and answers about Requirement 4 to help developers navigate through it.
1. What encryption ciphers should be used for various classifications of data?
Different scenarios require different encryption methods and algorithm implementations. The types of data exchanged at various endpoints in your solution will determine the best method(s) for encrypting and storing/transmitting data. For most instances, symmetric key encryption is best suited for storing data. And 256-bit AES encryption is recommended for transmitting it. Symmetric key encryption is not always possible, and in these instances you must rely on the public key infrastructure (PKI) to establish SSL/TLS encryption between the customer-facing endpoints (such as a web server or application) and the customers’ systems. Most certification authorities accept key lengths up to 2,048 bits, which provides encryption up to 256-bit. However, this is not a guarantee that all traffic will be encrypted at that level. I highly recommended that you disable weaker SSL ciphers such as SSL1 and SSL2, and only allow SSL3 and TLS to operate with clients that support 256-bit encryption.
2. Will our encryption standard compromise the user’s experience or inhibit adoption of secure practices?
An example of this would be a system that is too slow to load, so users can write down confidential info, take it over the phone, or take shortcuts. Encryption oftentimes adds considerable overhead to a system that would otherwise operate smoothly. There are many hardware appliances available to accelerate the processing of encrypted data. Depending on different load scenarios, it may be necessary to consider additional hardware to maintain application scalability. In addition to the impact on infrastructure, customers with older systems may not have the software necessary to support 256-bit encryption. These are extremely sensitive issues because this directly impacts the number of users who are able to conduct a transaction at an endpoint (whether it’s a hardware kiosk, such as an ATM machine or vending machine that accepts card data, or online via a website or application).
3. Will the hosting provider support the encryption requirements?
If “yes,” are there cost implications, and could it be found cheaper somewhere else? Hosting resources are always important because, for all intents and purposes, most hosting environments meet the PCI DSS classification of a public environment. Even with dedicated server, data transactions commonly occur over common network equipment, which could constitute a breach of both the data and the keys themselves. When working with your hosting provider it is extremely important to map out the various data sources and their destinations and ensure that traffic only traverses hardware dedicated to your company. In what is widely considered a deprecated architecture, most secure dedicated solutions include dedicated servers, switches, firewalls and physically isolated network design. This is oftentimes very expensive and not a requirement that hosting providers are willing to accommodate. Virtualized environments are often best suited as they allow on-demand scalability, while also providing network isolation through the use of technologies such as VMWare’s vShield virtual switching. Breakthroughs in homomorphic encryption are also expanding possibilities in both virtualized and cloud-type systems, but these innovations are several years from being applicably useful.
4. How long should data be stored, and how to track the age of encrypted data?
Data can be stored for as long as it is required. It is a best practice to dispose of data when it is no longer useful. However, keeping data for extended periods of time often means that the data must be altered when the keys used to encrypt the data are retired and replaced. This often happens on a schedule resultant of a key policy, but can also result from the exposure of a compromised key. These types of transformations must occur across all data, including data that has already been archived. This process is often cumbersome, and obviously becomes more so proportionate to the amount of data being stored.
Other Considerations
It is often not the responsibility of the developer to maintain an encryption key infrastructure. However, the developer must uphold the standards the IT department has established for developing strong keys and pairs, the secure storage of those keys, and the protected distribution of keys in transit to other endpoints. In addition to making more resources available to the application, it is also a requirement that all encrypted sessions are automatically disposed after a specific period of inactivity. The ability to establish or re-establish a secure connection should also be tightly controlled.
Conclusions
The ultimate goal of PCI DSS Requirement 4 is simple: fraud prevention. Studies and real-life results prove end-to-end encryption (E2EE) to be one of the best ways to achieve this. The E2EE process starts with proper infrastructure and planning, and continues with developers who are responsible for implementing the actual encryption policies. Those developers also make sure it meets the highest protocols and security standards set forth in PCI DSS. Coding on top of (or around) encryption requirements is an art that often involves compromises or adjustments to business logic code. So it is critically important to establish up front business logic, encryption and data management standards when developing web applications that will handle credit card data. Achieving compliance with Requirement 4 doesn’t have to be cumbersome or overwhelming. But it does have to happen. Understanding how to make this process simpler by breaking apart the various pieces can help developers reach PCI DSS security standards with less questioning and more clarity, which will help produce a secure environment.
A version of this article was published in eCommerce Developer on May 19, 2010.
This entry was posted on Wednesday, May 19th, 2010 at 1:00 pm and is filed under Compliance, Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
