Back to School with Database Encryption 101

The bad part of the equation, of course, is the cause of the attention. Namely, theft of sensitive data is increasingly grabbing headlines. For example, BJ's Wholesale Club suffered from the theft of thousands of credit card records earlier this year and is now facing claims from 10 to 15 banks that had to replace cards or reimburse customers.


For its part, database aggregator Acxiom lost data twice in one year. Then, in August, three men pleaded guilty to conspiring to hack Lowe's data network to steal credit card information.




To fend off such criminal manhandling of valuable data, database encryption should be one tool in an enterprise's arsenal. Recently, eWEEK.com held an eSeminar on the topic, which is now archived here for replaying.


The event generated some great questions from attendees that I promised I'd tackle more in-depth in the near future. The future is now, so here are some responses to those questions:


What are some industry-standard IT breach management strategies and/or a list of how to do database security right? Searching for industry-standard breach management strategies on the sites of large security groups such as CERT's Coordination Center is a fruitful way to get the basics on breach management.


There, you'll find two helpful checklists: one for intrusion detection and another that details steps to recover from a Unix or NT system compromise.


Beyond the basics you can pick up from such best practices lists, every enterprise has to concoct its own knowledge base of how to recover its particular database platforms. There are a zillion sources out there, from books to FAQs, to supplement the core knowledge DBAs should already have about their particular database platforms. This SQL Server programming FAQ has a plethora of links to articles on backing up and restoring SQL Server and is just one example of what's available.


Art Manion, Internet security analyst with CERT/CC, in Pittsburgh, told me that beyond learning such fundamental best practices, an enterprise has to decide on a per-site, per-business basis what level of encryption is required, if any, and tailor best practices to suit its needs. After all, encryption won't necessarily prevent a breach from happening, but it might prevent the party who orchestrated the breach from gaining any specific information from your database.


But that protection isn't free, of course, and implies dreaded performance overhead. So, of course, we need to address the question:


How do you minimize the performance overhead encryption implies? Application Security has a good white paper available, here in PDF form, on encrypting data at rest that tackles the overhead question.


In essence, though, limiting what you encrypt is the best way to reduce overhead. Here's what Ted Julian, vice president of marketing at ASI, had to say on this: "People are fascinated by encryption and usually start [their database security efforts] there. But it's one piece of the puzzle, at best."


If you look at other parts of the infrastructure, Julian told me, people do three things: One, most overlook vulnerability assessments. They don't do a thorough job of scanning the infrastructure to find databases, scanning for known vulnerabilities and then patching those vulnerabilities before they've even gone so far as to deploy the databases in question.


Next Page: File encryption versus database encryption.

Once deployed, you have to get databases up to standard levels. Sounds basic, doesn't it? "It's astonishing how few people have figured this out for databases," Julian told me. Everybody knows what server software they're running with xyz patches, what password policies are, etc.

But if you're not auditing databases on an ongoing basis, and making sure they're up to whatever level of update your enterprise has defined as being its baseline, you don't know how secure your database is, even if you're encrypting the entire database.


Next step, pre-encryption, is to harden systems so that they have secure configurations. That means securing default passwords and IDs to administrator and listener accounts, lest you leave the database wide open.





Some DBAs say they'll spend Labor Day weekend applying Oracle's latest, critical patch. Click here to read more.

Intrusion detection comes into play next, to provide real-time protection while you're busy patching all of those databases, serving to alert and shut down an attack before it can cause damage. That's why it's deployed on the network, and that's why it should be deployed on the database.

Encryption is your last line of defense, when there's no patch yet available and there's no signature for identity detection. It will keep somebody who's about to gain root access to your database from actually getting your customers' credit card numbers or Social Security (news - web sites) numbers, for example.

This is where you get into the question of what to encrypt, and there's no easy answer to that.

Is standard file encryption required with database encryption? When a file system is encrypted, whatever lives inside it—be it database table or text file—is encrypted. Database encryption experts will assure you that there's certainly overhead implied in either case, whether there's the abstraction layer of file encryption or not.


CERT/CC's Manion says they both imply different kinds and different amounts of overhead, depending on what file system you're talking about, what database you're using and what type of database encryption you're using. In other words, the question is impossible to answer without knowing the specifics of a given system setup.

But one way to avoid overhead is to encrypt at the column level in a database table, rather than encrypting anything and everything on a file system.

Securing directories versus securing the database. Depending on what's stored in there, it might make sense to encrypt a directory, Manion says. If you're talking about an internal server that contains internal phone and contact information for an internal staff, and it's not exposed to the outside world, it might not be worth the effort to encrypt it. Bear in mind, once you do choose to encrypt, you're adding another layer of logging on and/or passwords. These things don't come free.

Next Page: The tough question of estimating damages post-breach.

Another option is to sift out information that isn't accessed much and put it into a separate directory, thus giving yourself a lightweight directory that's available unencrypted.
Manion suggested a scenario in which you have an LDAP directory available via a Web interface, connected via SSL (Secure Sockets Layer). That's conceivably a decent amount of protection, with the database encrypted in the background.

It matters what the architecture looks like, obviously, Manion says. A more general question is, How sensitive is the data, and who should access it? If it's very, very sensitive, perhaps it doesn't belong in a globally available directory in the first place.

How can I estimate the damage done to my company's brand if I have to notify my customers of a data breach? People ask this when their goal is to assemble a business case for spending more money on securing customer data. It's a fair question to ask, but it's tough to find recent studies on the topic. I'm still searching, so if anybody knows of any good resources, please send them my way.

For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's Weblog.

Of course, it probably goes without saying that you should sit down with your finance department to get their input on this question. Talk to your marketing and/or sales department. Look at your company's history and at that of your competitors. Has your company in any way fumbled its reputation within the recent past? Have your competitors done so?

If so, take a look at revenue figures preceding and following the fumble. Ask sales reps or marketing personnel what kinds of experiences they had with customers. Ask them how long it took to regain their footing. Extrapolate.

Chances are, it wasn't a pretty sight. I'll let you know when I come up with a more specific formula, but in the meantime, tell your management that you'd rather not find out firsthand.

Most popular searches for W