Database Encryption
Transparent Data Encryption
A lot of the information in this section comes from an excellent, SQL Server specific, article by Simon McCaullife. Since the original article is now only available via the wayback machine I've taken the liberty of including some of the key points here. I've also added information relating to other database management systems.
Should I install TDE? Probably “No”. Only if you’re forced to. If arguing will lose your job; probably “Yes”. (1)
Simon McCaullifeIssues:
A database engine can encrypt the key that encrypts the data but ultimately one "key" will need to be held in some unencrypted (or obfuscated with a known algorithm) form otherwise you wouldn't be able to transparently decrypt the data (1,4).
TDE affects performance - for SQL2008 this appears to be somewhere between 2% and 12% (2)
“Encrypted data compresses significantly less than equivalent unencrypted data. If TDE is used to encrypt a database, backup compression will not be able to significantly compress the backup storage. Therefore, using TDE and backup compression together is not recommended.” (3)
Whilst TDE does result in the data being encrypted in the backup file, if this is your main aim consider that backup encryption is often available as a separate feature without the performance overhead.(4)
There are many situations in which TDE becomes effectively null and void. Unless great care is taken to avoid these the false sense of security is likely to lead unwary users to expose sensitive information that would have otherwise been protected with other more straightforward security methodologies. (1)
TDE & PCI-DSS Compliance
One of the requirements that gets a lot of flak is 3.5.1.2 which is the disk level encryption; in other words, technology like TDE being used to address encryption requirements. This is no longer a get out of jail free card because after March 2025, you will need to implement (on top of TDE, if you still insist on using it), if you are not using it on removable media – the 4 horsemen of the apocalypse – Truncation, Tokenization, Encryption or Hashing. And before you get too smart and say yes, you are using Encryption already, i.e transparent or disk-level encryption; PCI is one step ahead of you, you Maestro of Maleficant Excuses, as they spell out “through truncation or a data-level encryption mechanism“. (6)
https://www.pkfavantedge.com/it-audit/recap-on-pci-v4-0-changes-in-the-12-requirements/The new standard maintains that organizations use more robust encryption algorithms and key lengths as per 3.2.1. Key management more or less remain as it is, but the biggest issue in v4.0 is the doing away with full disk or transparent encryption. (7)
https://www.pkfavantedge.com/risk-management/pci-dss-v4-0-vs-v3-2-1-deepdive-part-1/Another control that had problems in its interpretation/implementation was the control related to the use of disk- or partition-level encryption. By using this mechanism, data is encrypted during storage but is automatically decrypted once the system is running or after successful authentication of a user, so its effectiveness is valid only while the storage medium is offline, protecting the entity if the media is physically removed in an unauthorized manner.
Although it was well known that the use of this type of encryption is only applicable when the PAN is stored in a removable electronic medium, since this restriction is not explicitly stated in control 3.4.1 of PCI DSS v3.2.1, many entities used this mechanism to protect the PAN when it was stored in databases without any additional control (Transparent Data Encryption - TDE is a good example of this), exposing them to unnecessary risk.
To avoid this ambiguity in the interpretation of the control, in version 4.0 requirement 3.5.1.2 clarifies that the use of disk or partition level encryption can only be applied to removable storage media or, if used on other types of media (including server hard disks, hot-swappable drives, bulk tape-backups, etc.), an additional protection mechanism included in control 3.5.1 (hashing, encryption, truncation or tokenization) must be used. (8)
https://www.advantio.com/blog/analysis-of-pci-dss-v4.0-part-3-requirements-3-4Memory Encryption
For PCI-DSS compliance, there is no requirement to encrypt data in memory (9)
Bibliography & References
(The Anatomy and (In)Security of Microsoft SQL Server Transparent Data Encryption (TDE), or How to Break TDE )
https://www.brentozar.com/archive/2020/07/a-one-slide-summary-of-the-differences-between-tde-and-always-encrypted/(2) https://www.databasejournal.com/features/mssql/article.php/3815501/Performance-Testing-SQL-2008146s-Transparent-Data-Encryption.htm(3) https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption(4) https://matthewmcgiffen.com/2018/01/03/how-secure-is-transparent-data-encryption-tde-and-how-to-prevent-hacking/(5) https://docs.oracle.com/database/121/ASOAG/introduction-to-transparent-data-encryption.htmhttps://www.mysql.com/products/enterprise/tde.html
https://www.vikingcloud.com/pci-dss-v4-are-you-using-disk-encryption/(6) https://www.pkfavantedge.com/it-audit/recap-on-pci-v4-0-changes-in-the-12-requirements/(7) https://www.pkfavantedge.com/risk-management/pci-dss-v4-0-vs-v3-2-1-deepdive-part-1/(8) https://www.advantio.com/blog/analysis-of-pci-dss-v4.0-part-3-requirements-3-4(9) https://d30000001huxdea4.my.salesforce-sites.com/faq/articles/Frequently_Asked_Question/Should-cardholder-data-be-encrypted-while-in-memory
Thales CDP - CipherTrust Database Protectionhttps://thalesdocs.com/ctp/cm/2.11/admin/cdp/index.htmlhttps://thalesdocs.com/ctp/cm/2.7/admin/cdp/index.html