There’s a bit of debate brewing in the comments on the latest post in our database encryption series. That series is meant to focus only on database encryption, so we weren’t planning about talking much about other options, but it’s an important issue.
Here’s an old diagram I use a lot in presentations to describe potential encryption layers. What we find is that the higher up the stack you encrypt, the greater the overall protection (since it stays encrypted through the rest of the layers), but this comes with the cost of increased complexity. It’s far easier to encrypt an entire hard drive than a single field in an application; at least in real world implementations. By giving up granularity, you gain simplicity. For example, to encrypt the drive you don’t have to worry about access controls, tying in database or application users, and so on.
In an ideal world, encrypting sensitive data at the application layer is likely your best choice. Practically speaking, it’s not always possible, or may be implemented entirely wrong. It’s really freaking hard to design appropriate application level encryption, even when you’re using crypto libraries and other adjuncts like external key management. Go read this post over at Matasano, or anything by Nate Lawson, if you want to start digging into the complexity of application encryption.
Database encryption is also really hard to get right, but is sometimes slightly more practical than application encryption. When you have a complex, multi-tiered application with batch jobs, OLTP connections, and other components, it may be easier to encrypt at the DB level and manage access based on user accounts (including service accounts). That’s why we call this “user encryption” in our model.
Keep in mind that if someone compromises user accounts with access, any encryption is worthless. Additional controls like application-level logic or database activity monitoring might be able to mitigate a portion of that risk, but once you lose the account you’re at least partially hosed.
For retail/PCI kinds of transactions I prefer application encryption (done properly). For many users I work with that’s not an immediate option, and they at least need to start with some sort of database encryption (usually transparent/external) to deal with compliance and risk requirements.
Application encryption isn’t a panacea – it can work well, but brings additional complexities and is really easy to screw up. Use with caution.
Reader interactions
One Reply to “Application vs. Database Encryption”
There’s some ambiguity how different experts see database encryption. in http://blog.imperva.com/2009/04/ambiguous-encryption.html I gave two examples of reports that were published at the same week (see some cut-and-text below). One recommended encryption, the other did not.
Working with customers I learned that “your mileage may vary” based on the configuration options which of course directly affect the level of security you get out of your solution. So it’s not just about the type of encryption solution, it’s also about how it is being used, configured and maintained.
–Sharon
Imperva
The RISK Team also highlights the need to protect BOTH the web application and the database.
To function properly, a trust relationship must exist between web applications and back-end databases. In this sense, a request from the application is similar to a request from a privileged administrator. The database obediently yields information requested by the application and cares not whether the command is valid or the result of an external attacker passing illegitimate strings.
Their conclusion is that database encryption is not useful to protect against application born attacks.
This is one of the primary reasons why encrypting databases is of limited effectiveness in preventing attack scenarios that do not involve physical theft or control of the system.
About the same time, the Symantec Global Internet Security Threat Report Trends for 2008 was released. It contains 110 pages of statistics, conclusions and suggestions (which of course hint for very specific implementation).
Symantec, like Verizon also highlight web applications and SQL injection as a primary attack vector but then, they recommend using encryption:
Encrypting sensitive data that is stored in databases will limit an attacker’s ability to view and/or use the data.
Encryption solutions are not born equal. There are different types of implementation options. Some require administrative rights which might allude to what Verizon hint.
What is right then? 3 letters: DID. Defense In Depth.