One of the things he stresses is that you must identify the threat the encryption is to protect against. I agree wholeheartedly. In the first chapter of Cryptography in the Database I talk about threat models:
A threat model is one of the most important tools to have when considering a database cryptosystem. The threat model shapes the design of the cryptosystem to ensure that it protects against the threats the organization ranks highly. Without a carefully crafted threat model, a cryptosystem can easily be built or purchased that protects only against a single class of low-priority threats.
Too many organizations are told that they need to encrypt some data, and off they go to encrypt without first deeply understanding the threats they are mitigating. The actual security value of such off-the-cuff encryption solutions is questionable. Always figure out what you want the system to protect against before going too far down the solution path.
Generally, people want encryption to make the data unreadable by folks who don't have a need to read the data. Seems fairly straightforward, but who are these folks? Your threat model should identify the threat agents you are worried about. Here's a list to get you started: system and database administrators, development staff, network intruders, application crackers, legitimate users, offsite backup-storage staff, and thieves.
Your encryption solution can be optimized to protect against different subsets of these threat agents. Protecting against all of them with a high-degree of security is exceedingly difficult and expensive. As you design your encryption strategy, select which of the threats it will address, and then cover the remaining threats with other mechanisms.
Your threat model will primarily influence two components of your cryptosystem: where to store the keys and where to place the encryption engine. The reason for this is straightforward. Encrypting information simply means that now you don't need to worry too much about protecting lots of little pieces of information (say credit card numbers), but instead you need to worry about protecting the encryption key (which, in turn, protects all the little pieces of information). Since the encryption engine is the only component that needs access to the key, you need to protect it and the place where the keys are stored against the relevant threats.
Another topic he mentions is the problem of tying your encryption solution to your access control system. A few vendors have referred to this as "transparent encryption." I talk about it in Chapter 2 (which is available for download--see section 2.7) of my book. As I say there: "The name itself should raise a few questions: what kind of security does transparent encryption provide."
In a transparent encryption solution, the system only decrypts data for authorized users. Depending on where the key is stored, this could be a viable solution if your threat model only consists of people stealing the database server or file (or a backup of the database). But against just about any other type of threat, transparent encryption is pretty much worthless.
Again, your threat model will help you determine the appropriateness of transparent encryption for your environment. I can't stress enough the importance of building a solid threat model to help you make informed security decisions. I'll talk more about threat models in a later post, but you don't need to build extensive attack trees and catalogs of vulnerability minutia. A simple list of the bad things you want to avoid, who might do them, and how they might be done will generally suffice.