Choosing Between Hardware and Software Encryption

As an increasing number of enterprises seek to protect their data at rest, they are turning to database encryption technologies to help them shelter their assets. However, in choosing between the numerous encryption options in this space they face a dilemma. Many businesses find themselves grappling with the decision between hardware-based and software-based encryption. Vendors selling database encryption appliances have been vociferously hawking their wares as a faster and more-powerful alternative to software database encryption. Many organizations have bought into this hype based on their experiences with hardware-based network encryption technology. But database and network encryption are two different animals. Many of the hardware vendor's claims are nothing more than marketing myths, easily refuted by years of evidence to the contrary.

Let's end the debate: Are hardware-based tools or software-based tools the best way to encrypt and decrypt databases?

I think that might be the wrong question to ask. The right question would be about the topology. What is the right topology to use for database encryption? Remote encryption or local encryption? The topology is crucial. It will dictate performance, scalability, availability, and other very important factors. So I think the topic is important but the question is usually not well understood. Usually, hardware-based encryption is remote and software-based encryption is local but it doesn't have anything to do with the form factor itself. Instead, it is about where the encryption is happening relative to your servers processing the database information.

Why are some people asking the wrong question?

It is because they are trying to apply what they've learned from other areas of IT. For example, from network encryption they've seen that software doesn't perform as well and that hardware is the best way to accelerate encryption. So they say, "Oh, hardware is the answer, that's the way to offload processing requirements." And they jump to the conclusion that this must be true for database encryption as well.

Why don't these principles apply to database encryption?

When you have, say, credit card data, you have to remember that databases usually operate on the field level. So you cannot send more data than one credit card number at a time. You encrypt it and then you need to give it back to the database immediately because it is sitting there waiting to send the next one. This is particularly a problem with decryption. For example, when someone is searching data and can't wait for slow response times. When you compare this process between local and remote encryption,