Database encryption is like a home repair project- either it’s really easy and goes exactly as planned, or about five minutes in you realize you might not want to make any weekend plans for the next 2-3 years, and perhaps you should take a trip to the flower store before trying to explain why your family will be living with exposed wall studs and dangling wires for a while.
Database encryption (and encryption in general) was one of the first technologies I covered when I first became an analyst. Early on I realized something didn’t smell right; I had vendors talking about using encryption to prevent attacks and to “enhance” access controls. But their products were completely linked to access controls, which didn’t really add any value. Also, most attacks against databases involve compromising user accounts or running queries within the privileges of the user, so how would encryption add any value? Encryption doesn’t do a darn thing against many SQL injection attacks or abuse by authorized users.
This led to a lot of introspection and the eventual development of the Three Laws of Data Encryption. We can thus divide database encryption into two categories:
- Encryption for Separation of Duties: In this case we will almost always use encryption to protect against our own administrators or other privileged user access, since we can more easily and efficiently use access controls for everyone else. The example is encryption of credit card numbers, with the keys stored outside of the database, to allow stored numbers for credit card processing but to eliminate the possibility of administrators or users accessing the numbers.
- Encryption for Media Protection: Here we encrypt database objects (tables/columns), database files, or storage media to prevent exposure of information due to physical loss of the media.
As you can imagine, encrypting for media protection is much easier than encryption for separation of duties, but it clearly doesn’t offer the same security benefits.
Thus, the first thing we need to decide when looking at database encryption is what are we trying to protect against? If we’re just going after the PCI checkbox or are worried about losing data from swapping out hard drives, someone stealing the files off the server, or misplacing backup tapes, then encryption for media protection is our answer. I’ll discuss it more in a future post, but it’s a fairly straightforward process with manageable performance implications.
If we want to encrypt for separation of duties, then life gets a little more complicated. Databases are complex beasts; far more complex than most people give them credit for. Just go try and teach yourself relational calculus or indexing. They like structured data, and once we start mucking with that by randomizing our data through encryption we start messing with performance. That’s not even counting the normal performance impact of encryption itself.
As with encryption for media protection I’ll talk more specifically about encryption for separation of duties in future posts, but as a general rule of thumb it’s not overly difficult to build encryption into a new database, but if you are encrypting a legacy database accessed by applications (legacy or otherwise) you are sometimes looking at a 2-3 year project due to the required database and application changes. We run into problems with indices, range searches, referential integrity, application integration, connection pooling, key management, and … well, there’s a lot to talk about here.
To close this post out, the first thing to look at when considering database encryption is what threat you are trying to protect against. If it’s loss of the database files and media, look towards media protection. If you want to limit regular user access, look to access controls or other internal database security features. If it’s separation of duties for discrete data (again, we’ll talk more later) then consider column/field encryption, and make sure you can store the keys outside of the database.
As you’ve probably figured out by now, this is one of those multiple-post series things I like to do. In the next one we’ll talk about encryption for media protection and why you might want to combine it with database activity monitoring. After that, I’ll dig into field (or other object) encryption for separation of duties, then we’ll close with more detailed recommendations and a discussion of key management.
BTW- I’m going in for some minor shoulder surgery on Monday which will slow me down for a little while. I’ll have some guest posts for next week, and should be back up and running fairly soon.
<
p style=”text-align:right;font-size:10px;”>Technorati Tags: Database encryption, Database Security, Encryption, Tutorial
Reader interactions
6 Replies to “Introduction To Database Encryption”
Pls, I need an handout on Introduction To Database Encryption
@Kevin,
I consider that “physical or virtual loss”. That’s how I usually discuss it, and I suspect I should have edited the post better before putting it up. I do mention that case slightly lower, but clearly neglected it in the numbered list. Sorry, and thanks for catching that.
Amazing post.
I’‘ve enjoying your blog for some time now and I look forward to reading the series on database encryption. I’‘m curious why the second category of encryption is limited to physical loss. How do you categorize loss of the database files themselves?
Kevin Kenan, author of “Cryptography in the Database”
Great post Rich. Look forward to the next in the series. Good luck with the surgery.
Mogull’s applying that to database security today, saying, “Thus, the first thing we need to decide when looking at database encryption