The futility of transparent encryption of data-at-rest

I was recently involved in an IT audit of a solution that I had architected for security. I was part of the delegation that was to provide requisite information to auditors and my responsibility was to handle any questions related to security of the solution in question. While there were many questions related to security, one particular conversation stood out for me. It was related to encryption of data-at-rest.

Although I made this post look conversational, I’m not quoting the auditors here as I don’t recall their exact words. But this is generally how this conversation flowed:

Auditor: “Is data encrypted at rest?”
Me: “No, but technically yes”
Auditor: “What do you mean?”
Me: “Our data is hosted on Amazon RDS and we use TDE.”
Auditor: “Transparent Data Encryption?”
Me: “Yes. Is that good enough?”
Auditor: “Of course!”

Now, this is where my interest was piqued. I decided to dig further and understand why the auditor felt TDE is enough, because in my mind TDE does not protect against any real risks….Ok maybe it does, but the probability of that risk materializing is minuscule (almost non-existent). Let me explain.

After the audit was complete, I caught up with the auditor to pick his brain:

After some initial pleasantries, I began by asking, “Why do you think TDE is adequate? What type of risks do you think TDE protects against? He said, “Well, even if a hacker breaks into the application, he will only find encrypted data. Also, if an administrator, deliberately or inadvertently, logs into the DB , the data will still be encrypted and he won’t be able to view it.”

This understanding is entirely inaccurate. In both the situations that the auditor noted above, data will be available in clear text for the hacker or administrator to view (or edit, depending on permissions). TDE transparently encrypts and decrypts the data. If you are logging in as a valid / authorized user of the DB, then the data is automatically decrypted and made available to you; that’s why it’s called transparent. Same will be the case of a hacker breaking in as the account used by the application to connect and retrieve data from the DB is a valid / authorized account. There is no way for the DB to tell that the application was hacked. The DB will simply and transparently decrypt the data and present it to the application, as requested.

According to me, the only risk that TDE protects against is when the physical medial (hard drives or backup tapes) of, in this case, Amazon RDS, are stolen. Attackers can attach these drives to another system / DB and browse the files / data. Now, what is the probability of an attacker breaking into Amazon’s data centers or for that matter any data center to steal physical media? I don’t recall a single such incident in recent times. Is the probability of media theft higher than that of an attacker sitting in front of his / her PC from the comfort of home and hacking into the application over the Internet and performing all of this anonymously and rather quickly? I don’t think so.

Further, here’s something interesting. AWS Docs on Oracle TDE says “Oracle Transparent Data Encryption is used in scenarios where you need to encrypt sensitive data in case data files and backups are obtained by a third party or when you need to address security-related regulatory compliance issues.” What’s the point of implementing a security control just to address regulatory compliance requirements? I read this as “this control has not real security benefit but it will help you keep the auditors satisfied”. Here’s additional links that pretty much say the same thing – here, here and here.

Please don’t get me wrong here. I’m not against transparent encryption, in fact I recommend it. But it’s important to understand the real risks that this control is protecting against so that we’re able to design additional controls (e.g., application-level encryption) where required. Always remember, in security, there’s nothing more dangerous than a false sense of security!