Protecting the Database With Encryption

To encrypt or not to encrypt? When it comes to SQL Server database encryption, the question more frequently asked, now that companies fear the disgruntled DBA as much as the malicious outsider, is “Where should I encrypt?”

Related: Using Transparent Data Encryption, June 2012

Column-level encryption vendors exhort you to encrypt at the column level, while database-level encryption vendors assure you that database-level encryption will save your job. If both sides don’t exactly cancel each other out, they can still leave your head spinning.

NetLib offers both column-level and database-level encryption for SQL Server with its NetLib Encryptionizer. Who better to cut through the maze of white papers encircling the database-level versus column-level question?

The key, says NetLib CTO, Neil Weicher, is to focus on customers’ needs and help them find an easy-to-use solution. “I listen to what their needs are and between the two products, see what makes sense,” adds Elisabeth Stonehill, NetLib vice-president of product development.

“People automatically assume that column-level encryption is better and then become interested in whole database encryption,” says Weicher. Why do many companies choose column-level? “It’s simply a policy their company has.” Perhaps, he adds, because some believe that column-level encryption is part of Payment Card Industry (PCI) data security standard (DSS) compliance requirements. However, “whole-database encryption does meet PCI compliance,” Weicher says.

“Our end-users are split about 50/50,” Stonehill says. Column-level encryption creates a five-percent performance hit. “The more columns you encrypt, the more of a hit.” Whole database encryption has two advantages, she says: “It’s transparent to an existing application, so no changes need to be made, and on a multiprocessor machine, there’s no impact on performance.”

However, Weicher says, if you have system admin access to SQL Server, Microsoft gives people read-access to the whole database, and with whole-database encryption, anyone who had sys admin rights, still has them. “Our customers often go back to Microsoft to review sys admin rights and not assign them so broadly,” Weicher says.

What should you consider when selecting a database encryption product? Pretty much what you consider with any product: Ease of use, cost, and service. “If a product is too difficult to deploy, it won’t be used,” says Weicher. And when talking cost, consider also “the cost of implementing and administering it,” Stonehill says. "Other products, because they’re Cadillacs, their minimum sales is a million dollars; our sweet spot is the SMB and departments within Fortune 500 companies. They’re looking for solutions that cost less and cost less to maintain and keep.”

“Another area is providing service—people aren’t going to trust their corporate data to just any product,” Weicher says. “Has the company been around for a long time? Does the product have an evaluation phase?”

Compared with the crowded SQL Server auditing and monitoring product arena, there are far fewer database encryption products. One reason, says Weicher, is that only in the past couple of years have businesses thought about protecting the database, especially from internal attacks. “The real danger are these repositories of information—I think the industry is starting to realize that. It’s right to trust your employees but you still don’t leave out the jewels.”

To learn more about NetLib Encryptionizer, visit NetLib's Web site.