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.