SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

SQL Server Encryption Best and Worst Practices

By Neil Weicher,

I read Steve Jones’ article “Worst Practices - Encrypting Data” with great interest, being a database encryption software vendor myself.

It may surprise you that I have come to the same conclusion as Mr. Jones: few DBAs would want to encrypt the database. Why would they? I’ve known many DBAs in my professional career. (Dare I say it… some of my best friends are DBAs.)  The last thing that any of them need is more administrative overhead.  Especially for something that is not really their responsibility.

 The DBA may “own” the server and software, but someone else “owns” the information: usually the CEO and the CIO; ultimately the stockholders. If the “bad guys” get through to the information, the DBA might have a red face, but his job is still secure. After all, he used all generally agreed upon “best practices” for security, right?  The ones who really pay are the CEO and CIO. They might be waking up with nightmares. Unfortunately for them, the person who’s job it is to deploy data security (usually the DBA and/or Network Administrator) is not the person who suffers if information is compromised! The decision-making responsibilities for protecting information need to be moved into the hands of the person who owns the information.  This may be more difficult than it sounds, because the DBA is usually the only person in the company that the CEO is terrified of!

DBA’s have focused tremendous resources on such tools as firewalls and physical security, because these measures protect their servers and their software. But these measures only (partially) stop people from getting to the information. And they do nothing to protect the information once the perimeter is breached. Dr. Peter Tippet, Executive Editor of Information Security Magazine, dealt with this topic in an excellent article called “The Crypto Myth” in which he takes the industry to task for focusing on the dangers of “sniffing packets off the net” and leaving data on servers unprotected.  In it he says:

“The number one [eSecurity] problem has always been the insecurity (both physical and electronic) of servers and databases storing this information”. 

You can read this article by going to our web site www.netlib.com (aren’t we the crafty ones?) and clicking on the read link next to the quote.

Why this is so becomes more obvious when you consider what Visa found in their research.  In an internal study, Visa found that “70 percent of fraud can be attributed to internal compromise.”

Don’t forget, there are many more opportunities to get to information from the inside than from the outside. And information resides in many different places: web servers, corporate servers, bacup media, etc. Sure, the backup operator can encrypt backups on a tape, but then every backup operator knows the password. In fact, it is probably taped to the backup console! According to Neil Weicher, CEO of Communication Horizons and self-proclaimed industry expert,

“Business and government are spending all their effort preventing the ‘bad guys’ from getting to their databases and almost no effort into protecting their information when they do get to it.”

Look at it this way: banks have armed guards, silent alarms and strong vaults. So why do they still put red dye in the moneybags? To make the money unusable when the “bad guys” get to it. Is the information “capital” of a company any less valuable than the green kind?  In most cases, it is more valuable.

Apart from the administrative burden on the DBA, one of the articles major complaints about encryption is that it can’t provide 100% protection.  I.e., in many cases you can’t protect against the DBA himself. Does that mean that no protection is better than 99% protection, or even 95% protection?  Does that mean we leave the back door to our house wide open because closing it will only stop 99% of the people who might try to break in?

Anyway, this is exactly why we try to reach the CEO or the CIO with our message. It is unfair to charge the DBA with this responsibility. If I may be permitted to interject a commercial note, we believe we have a solution that will please everyone: the CEO and CIO because it protects information and is fairly inexpensive.  It pleases the DBA because it requires no programming, no administration, and is lightening fast.  We have not left the developers out either. (Did I mention that some of my best friends are developers?)  An API set allows the developer to build encryption into their custom or commercial applications.

In conclusion: of course we need to keep thinking of ways to stop the “bad guys” from getting to our critical data. However, we need to think beyond that and plan for minimizing the impact of when (notice I didn’t say “if”) they do get to it.

Total article views: 6681 | Views in the last 30 days: 1
Related Articles

SQL Server Data Encryption Options

SQL Server Data Encryption Types Businesses today have a greater need than ever to protect their ...


SQL Server Encryption - Protecting Files at Rest

You have a few options for protecting your SQL Server data at rest. So far I haven't seen anything t...


Optimizing Protected Indexes (was Indexing Encrypted Data)

Why bother encrypting? Riddle me this batman? Why bother to Encrypt? As a SQL Server DBA I am pr...


SQL Server Encryption

Encryption is a methodology used to hide confidential information from any illegitimate user is such...


SQL Server 2005 encryptation

SQL Server 2005 encryptation