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:
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.
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:
This additional compromise is more difficult than simply accessing the database.
What Are All the New PCI DSS 4.0 Requirements? Find Out Here!
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.
Like encryption, tokenization can be utilized to prevent access to data. In terms of obfuscating, the following options are compliant and recommended:
Implement TDE with Redaction for databases and GPG encryption for files on servers.
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.
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.
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:
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.