Companies often balk at encrypting large amounts of data because the mathematical algorithms used in encryption and decryption are computationally intensive. Hale says it can take six to eight hours to encrypt a 60GB to 80GB hard drive from scratch. But that is a one-time job for each drive. Once it is done, the day-to-day incremental encryption and decryption run in the background, unnoticed by users. "The files you bring up open very quickly," Hale notes.
While Moore's Law has taken a lot of the sting out of encryption, Hale says a server that processes many transactions against a large database can become unacceptably slow if care is not taken. The answer, he says, is not whole-disk encryption but selective encryption at the application or even data-element level. "We will encrypt Social Security [numbers], name, address - anything that is personally identifiable information," Hale says. In some cases, he says, it is possible to do that using the features embedded in commercial software, such as database applications.
But while going to that level of granularity saves processing cycles, it comes at cost: the effort required to inventory and classify applications and data. In fact, technology per se is not the hardest part of a broad encryption deployment, says Matt Haynes, a security architect at a major telecommunications firm that he declined to name. "The big effort is that you have to identify where the data is. It took us a quarter to do that. The second thing is figuring out policies and procedures: How do you live with this new thing called encryption?"
Haynes recommends tackling an encryption project with two distinct teams: "One to find and classify data, and the other to become experts on the encryption tools and processes themselves."
The work does not stop once encryption is in place. "There's process overhead, administrative overhead, and you obviously have to manage that system very closely," Haynes says.
And there is key management. "Once you've got a lot of data encrypted, you'd better damn well be sure you can get it decrypted and know who can get it decrypted," he says.
Still, there are technology choices that can greatly minimise the deployment effort, Haynes says. For example, some approaches to encryption require that applications be modified at each point where they access an encrypted database. "When we first started looking at encrypting data," Haynes recalls, "we understood that the need to make complicated and numerous application changes was going to turn the concept into a many-year, many-million-dollar project." But he was able to avoid such an undertaking by using the Ingrian encryption appliance. It sits between the database and the applications and is largely invisible to the applications. Application-level changes were "minimal", he says.
"Encryption is a strategic initiative," Massar says. "For the past year or so, we have been focused on some very tactical things - encrypting tapes, laptops, BlackBerries and so on. These are some quick-win situations. But what if I had taken a more strategic approach a couple of years ago?"
For example, if he had re-architected his applications so as not to store data in clients, then he might not have to encrypt the laptops. If the source Massar is backing up to tape had been encrypted to begin with, then he wouldn't need to encrypt the backup tapes. "Maybe if I had done a little work upfront," he says, "I wouldn't have to do these tactical things later on."
Now read: Encryption - the unexpected pitfalls