The new PCI-DSS 4.0 standard includes subtle changes to the types of encryption implementations available to organizations.
Requirement 3.5.1.2, although not necessarily new, explicitly prohibits using disk encryption for online systems. The standard correctly states that disk encryption only protects the removal of the hard drive and, therefore, would not prevent a malicious actor from removing data from an online system. See below:
3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:
- On removable electronic media
- If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.
Many QSAs (including Intersec) initially interpreted this requirement as prohibiting Transparent Data Encryption within the database. Guidance and applicability notes within the standard suggest that column and field-level encryption within the database is acceptable, but databases that encrypt entire partitions (disk) are prohibited.
Understanding the Challenges with Transparent Disk Encryption (TDE)
Implementing Transparent Data Encryption (TDE) within a database is a relatively easy and proven process. The issue with TDE is that, like Disk Encryption, anyone with access to a table or column can still see the data in the clear without any additional actions. Therefore, if the database is compromised, a malicious actor will have immediate access to all data stored within.
Figure 1 below illustrates what Transparent Data Encryption looks like when implemented and how it would appear if the database were compromised. Should an attacker successfully gain the credentials of an authorized individual, all they would need to do is log in to the database, and all the information is in the clear and ready to be exported. If the database has not been patched, a malicious actor may be able to execute a successful exploit and compromise the database without needing valid credentials.
Figure 2 below illustrates an encryption implementation without Transparent Data Encryption. As shown below, an application server is responsible for obtaining an encryption key from a secure vault or HSM, encrypting the data, and then storing it in the database. If the database or authorized credential is compromised, only encrypted data is accessible.
To obtain data in the clear, the malicious actor would now have to:
- Figure out where the application server is
- And how to attack it to obtain the encryption key
This additional compromise is more difficult than simply accessing the database.
What Are All the New PCI DSS 4.0 Requirements? Find Out Here!
Exploring the Use Cases for Transparent Data Encryption (TDE)
Given the cost of TDE, often tens of thousands of dollars per processor, why should organizations rely on it? Implementing column or field-level encryption is often expensive and time-consuming or may only be possible in some cases. The following list exemplifies organizations' typical struggles with implementing column/field-level encryption.- Legacy applications with poor data architecture
- Vendor-provided application
- Performance considerations
Vendor applications represent another challenge for many organizations. For whatever reason, usually cost or complexity, a vendor has chosen not to implement encryption within their application code. This results in the vendor recommending TDE or Disk Encryption to maintain simplicity within their code and/or reduce costs.
Finally, many encryption implementations may suffer significant performance degradation when encryption is implemented. This is usually solved by purchasing larger systems, but may not be scalable financially for many organizations.
Intersec's Recommendations for Enhanced Data Security
Organizations relying on Transparent Data Encryption to comply with the PCI-DSS standard should do so only as a last resort.
Intersec anticipates that at some point in the future, TDE may be deprecated for use (deemed non-compliant) due to changes in the threat landscape or acknowledgment that TDE provides little value in protecting stored data.
Intersec also strongly recommends using Redaction (Oracle / SQL) or Column Masking(DB2) with TDE to limit overall access to data to only those applications and individuals authorized to interact with it.
For example, a Database Administrator (DBA) responsible for maintaining a database will be able to view data encrypted with TDE due to their administrative database permissions. With Redaction or Column Masking enabled, the DBA would be unable to see the data as it will appear redacted (‘************’). In most cases, DBAs do not need to interact with the data they are tasked with managing. While the DBA can easily disable Redaction and Column Masking, required audit controls may be leveraged to generate critical alerts when this activity occurs.
Wondering how to update your current policies and practices to accommodate PCI DSS 4.0 requirements? We've got you covered. Explore our resource for a comprehensive overview of the changes and how to adapt.
Evaluating Data Obfuscation Options
Like encryption, tokenization can be utilized to prevent access to data. In terms of obfuscating, the following options are compliant and recommended:
Good (Enough)
Implement TDE with Redaction for databases and GPG encryption for files on servers.
Better
Implement encryption or tokenization on application servers interacting with data and store sensitive data in files or databases in obfuscated formats. With this solution, the encryption key or tokenization agent typically sits on the application server.
Best
Implement encryption or tokenization on dedicated hardware, preferably an HSM. This may be a standalone server or, in the case of an HSM standalone appliance, installed as a card within the server. All encryption key management, encryption and decryption occur within a server or appliance that performs this activity.
Key Takeaways and Tips to Ensure Transparent Data Encryption Compliance
Navigating the intricacies and challenges of encryption compliance can appear daunting, especially with the new PCI-DSS 4.0 standards. However, with a knowledge-rich and proactive approach, organizations can effectively mitigate potential security risks.
Keep the following in mind:
- Disk encryption for online systems is explicitly prohibited by Requirement 3.5.1.2 of PCI-DSS 4.0.
- Transparent Data Encryption (TDE) can present vulnerabilities, as a database compromise can lead to immediate data access.
- TDE should be considered as a last resort for compliance with PCI-DSS.
- The use of Redaction or Column Masking with TDE can limit data access to authorized individuals and applications.
- Tokenization can be a viable alternative to encryption for data obfuscation.
- Implementing encryption or tokenization on dedicated hardware, preferably an HSM, represents the highest level of security.
PCI 4.0 Transition Plan
The QSAs of Intersec Worldwide have analyzed the PCI-DSS 4.0 standard to identify transitional impacts to our clients’ compliance programs as they migrate to the new version.
We've been working diligently with our clients to get them on the path to PCI compliance success, and now we want to share our expertise and implementation plan with you!
Our PCI DSS 4.0 Transition Plan and Implementation Guide offers detailed insights, including 26 critical priorities every organization should act on. Read, share, and download a PDF of the contents to get started today!
Delays in implementation and understanding will likely lead to missed compliance dates due to failures to meet compliance objectives. Let us help you with our free transition plan!
Questions? Reach out to our team today.
