As a merchant your goal is to protect stored credit card numbers (PAN), as well as other card data such as card-holder name, service code, and expiration date. You need to protect these fields from both unwanted physical (e.g., disk, tape backup, USB) and logical (e.g., database queries, file reads) inspection. And detect and stop misuse if possible, as well.
Our goal for this paper is to offer pragmatic advice so you can accomplish those goals quickly and cost-effectively, so we won’t mince words. For PCI compliance, we only recommend one of two encryption choices: Transparent Database Encryption (TDE) or application layer encryption.
There are many reasons these are the best options. Both offer protection from unwanted inspection of media, with similar acquisition costs. Both offer good performance and support external key management services to provide separation of duties between local platform administrators, storage administrators, and database administrators. And provided you encrypt the entire database with TDE, both are good at preventing data leakage.
Choosing which is appropriate for your requirements comes down to the applications you use and how they are deployed within your IT environment. Here are some common reasons for choosing TDE:
Transparent Database Encryption
- Time: If you are under pressure to get compliant quickly – perhaps because you can’t possibly see how you can comply by your next audit. The key TDE services are very simple to set up, and flipping the switch on encryption is simple enough to roll out in an afternoon.
- Modifying Legacy Applications: Legacy applications are typically complex in function and design, which makes modification difficult and raises the possibility of problematic side effects in processing and UI. Most scatter database communication across thousands of queries in different program areas. To modify the application and deal with the side effects can be very costly – in terms of both time and money.
- Application Sprawl: As with hub-and-spoke workflows and retail systems, you could easily have 20+ applications that all reference the same transaction database. Employing encryption within the central hub saves time and is far less likely to generate application errors. You must still mask output in the applications for users who are not entitled to view credit card numbers and pay for that masking, but TDE deployment is still simpler and likely cheaper.
Application Layer Encryption
Transparent encryption is easier to deploy and its impact on the environment is more predictable, but it is less secure and flexible than employing encryption at the application layer. Given the choice, most people choose cheaper and less risky every time, but there are compelling arguments in favor of application layer encryption:
- Web Applications: These often use multiple storage media, for relational and non-relational data. Encryption at the application layer allows data storage in files or databases – even to different databases and file types simultaneously. And it’s just as easy to embed encryption in new applications as it is to implement TDE.
- Access Control: Per our discussion in Supporting Systems earlier, application layer encryption offers a much better opportunity to control access to PAN data because it inherently de-couples user privileges from encryption keys. The application can require additional credentials (for both user and service accounts) to access credit card information; this provides greater control over access and reduces susceptibility to account hijacking.
- Masking: The PCI specification requires masking PAN data displayed to those who are not authorized to see the raw data. Application layer encryption better at determining who is properly authorized, and also better at performing the masking itself. Most commercial masking technologies use a method called ‘ETL’ which replaces PAN data in the database, and is complicates secure storage of the original PAN data. View-based masks in the database require an unencrypted copy of the PAN data, meaning the data is accessible to DBAs.
- Security in General: Application layer encryption provides better security: there are fewer places where the data is unencrypted, fewer administrative access points, better access controls, more contextual information to determine misuse, and one less possible platform (the database) to exploit. Application layer encryption allows multiple keys to be used in parallel. While both solutions are subject to many of the same attacks, application layer encryption is more secure.
Deployment at the application layer used to be a nightmare: application interfaces to the cryptographic libraries required an intricate understanding of encryption, were very difficult to use, and required extensive code changes. Additionally, all the affected database tables required changes to accept the ciphertext. Today integration is much faster and less complex, with easy-to-use APIs, off-the-shelf integration with key managers, and development tools that integrate right into the development environment.
Comments on OS/File Encryption
For PCI compliance there few use cases where we recommend OS/file-level encryption, transparent or otherwise. In cases where a smaller merchant is performing a PCI self assessment, OS/file-level encryption offers considerable flexibility. Merchant can encrypt at either the file or database levels. Most small merchants buy off-the-shelf software and don’t make significant alterations, and their IT operations are very simple. Performance is as good as or better than other encryption options. Great care must be taken to ensure all relevant data is encrypted, but even with a small IT staff you can quickly deploy both encryption packages and key management services.
We don’t recommend OS/file-level encryption for Tier 1 and 2 merchants, or any large enterprise. It’s difficult to audit and ensure that encryption is being applied to all the appropriate documents, database files, and directories that contain sensitive information. Deployment and configuration is applied by the local administrator, making it nearly impossible to maintain separation of duties. And it is difficult to ensure encryption is consistently applied in virtual environments. For PCI, transparent database encryption offers most of the advantages with fewer possibilities for mistakes and mishaps.
Transparent encryption is also easiest to deploy. While integration is more complex and more time-consuming, the broader storage options can be leveraged to provide greater security. The decision will likely come down to your environment, and you’ll find that in order to meet some part of the PCI specification, you will likely need to choose one or the other, depending on your architecture.
Reader interactions
3 Replies to “Data Encryption for PCI 101: Selection Criteria”
Apologies for showing up late. I’ll go a little to the extreme with my response since it’s a bit more fun.
I am saddened that TDE is given so much credence here. This post gives us a great example of why compliance != security. The problem I have with it is that in the eyes of PCI, “encryption” is a binary, it’s a checkbox and TDE meets that requirement while doing little to help or worse (putting availability of data at risk). The overall security posture suffers. According to the Verizon DBIR, 98% of records were lost to external entities and an almost equivelant loss through malware and hacking techniques. With only 1% of the threat being physical (that TDE shines with).
Since TDE is “transparent”, it is just as transparent to the application as malware or hacking attempts. In other words it is (in my estimation) 98% worthless with the 2% as achieving the PCI check.
Having said all that, I have recommended TDE in limited situations for the exact reasons mentioned here. We need that compliance checkmark and often code modifications are impossible (legacy/OTS). I weep a little on the inside everytime I have to recommend TDE to meet PCI compliance.
@jml – In hindsight the description is a bit ambiguous. What I mean by that is log files, rollback files, data cache and other files get copies of content. That includes credit card numbers if they are being stored, so you get data leakage if you don’t encrypt those file as well. TDE is now commonly applied to an entire schema or database, rather than a column or table, to deal with this.
You are correct that the primary use case is for media protection.
-Adrian
While I understand how TDE offers “protection from unwanted inspection of media,” I’m less clear on how TDE “prevent[s] data leakage.”
My mental model has TDE in more or less the same place as encrypted backup media; performing as a control against bulk-loss, but I don’t see how “data leakage” is really being controlled against when the entire database is unlocked/unencrypted upon startup, and remains operationally unlocked until shut down. Perhaps I’m not working with the same sense of the term “data leakage” as you are.
Could you clarify?
-jml