By : Neil Weicher, CEO of Communication Horizons (www.NetLib.com)
Posted: 01/30/2002
Originally posted at sqlservercentral.com

To the editor:

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. 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 whose 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”. 

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, backup 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! “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 percent protection, i.e., in many cases you can’t protect against the DBA himself. Does that mean that no protection is better than 99 percent protection, or even 95 percent protection?  Does that mean we leave the back door to our house wide open because closing it will only stop 99 percent 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. 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 they do get to it (notice I didn’t say “if”).