.svg){kind=icon}
.svg)
Data storage that relies on disk encryption as the only means to protect data
Since the introduction of PCI DSS, disk encryption has been used to render cardholder data unreadable for the purpose of safeguarding data and achieving the intent of PCI DSS. It was even added to PABP and subsequently to PA-DSS. There are some challenges in using disk encryption to render cardholder data unreadable. It is related to key management, and without proper key management, the data is no more protected than if it is stored in clear text.
VikingCloud performs over 1000 assessments a year; many of these are Payment Service Providers (PSPs), of which a multitude use disk encryption to protect cardholder data.
The implementation of disk encryption is usually found where the application does not have built-in capability, and data is stored in files, either permanent or temporary when the data hits the disk during processing.
Disk Encryption
Pros
- Protection against theft: Disk encryption protects the data stored on a device from theft. Even if someone steals the device, they cannot access the data without the encryption key.
- Ease of implementation: No need to add data encryption at the application layer.
- Cost: Because key management doesn't have to be built in on the application layer, it will reduce the overhead and time of implementation.
Cons
- Only Protection against theft: Disk encryption really only protects the data stored on a device from theft, as the encryption of the data is transparent, and anyone with proper access rights will have access to the data in clear text.
- Hard to meet key management requirements such as:
- Key-encrypting keys are stored separately from data-encrypting keys.
- Usage of split knowledge and dual control.
- Performance impact: Disk encryption can cause a performance impact on a device. The encryption and decryption processes can slow down read and write operations, which can impact the device's performance.
One of the future-dated requirements in PCI DSS 4.0 that have been updated is the requirement that addresses the use of disk encryption. Once the requirement becomes mandatory, the use of disk encryption as the sole method to render cardholder data unreadable is only allowed if used on removable media.
This means that entities using disk encryption to render cardholder data unreadable on non-removable media can still use it to protect their data, but it can't be the only means of rendering cardholder data unreadable.
Common Scenario 1:
Settlement files containing cardholder data are transmitted using file transfer services like SFTP or FTPS, where the file transfer protocol protects the data during transport, but the actual file is sent in clear text. The file is received and put on disk for further processing. A processing service/script opens the file and processes the content. In this case, the data has been stored on disk for a period and needs to be rendered unreadable. This is a scenario where disk encryption has historically been used to protect cardholder data.
Potential remediation for this scenario would be as follows:
- Have the sending party encrypt the file at file-level and implement proper key management between the parties involved.
- Have the file transfer service temporarily hold the file received in memory rather than on disk and have the services/scripts process the data from memory.
Common Scenario 2:
Cloud-based solutions where the cloud service provider encrypts virtual disks as a service.
If your systems have relied solely on this type of service to render cardholder data unreadable, you will likely have to look at options to encrypt data on an application layer or use database encryption technologies.
Common Scenario 3:
The database is encrypted using Transparent Data Encryption, or TDE for short.
Multiple vendors provide TDE as a way to render cardholder data unreadable, and when analyzing the requirement, it specifically says that file-, column-, or field-level database encryption
is exempted. Oracle's TDE use tablespace encryption and MS SQL TDE use file-level encryption and should be acceptable as long as it's implemented correctly. This would include hardening, access management, as well as proper key strength and key management.
Conclusion
- Start your transformation to PCI DSS 4.0 as soon as possible.
- Plan to transform to PCI DSS v4 for applicable requirements no later than March 31st, 2024.
- Implement projects to implement controls for the future-dated requirements and have them implemented no later than March 31st, 2025.
- Identify any process that relies on disk encryption to protect cardholder data.
- Change process to process data in memory or utilize application-level or database-level encryption techniques.
Timeline
PCI DSS v4 was released in March 2022, and SAQs and supporting documents in April 2022, with a smaller update in December 2022. With the release of PCI DSS 4.0, the sunset date for PCI DSS v3.2.1 was set to March 31st, 2024, with future-date new requirements coming into play on March 31st, 2025. In the same capacity, you can exclude Future-dated requirements from validation up until March 31st, and you are expected to have the new future-dated requirements implemented on April 1st, 2025.
At first glance, this seems like a rather long transformation period. However, there are a few things to consider.
- New requirements that have long lead implementation times.
- Budgets needed to support implementation or improvement of controls.
- Resources needed to make the required changes.
For more information about VikingCloud's PCI Compliance solutions visit https://www.vikingcloud.com/compliance-risk/pci-compliance or contact the VikingCloud team.
.webp)
