eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Database security vulnerability is finally getting a level of attention approaching that which has long been targeted at networks, which is both a good thing and a bad thing.
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, BJs 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 Lowes data network to steal credit card information.
To fend off such criminal manhandling of valuable data, database encryption should be one tool in an enterprises 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 Id 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 CERTs Coordination Center is a fruitful way to get the basics on breach management.
There, youll 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 whats 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 wont 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 isnt 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. Heres 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 its 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 dont do a thorough job of scanning the infrastructure to find databases, scanning for known vulnerabilities and then patching those vulnerabilities before theyve even gone so far as to deploy the databases in question.
Next Page: File encryption versus database encryption.
File Encryption, Database Encryption
Once deployed, you have to get databases up to standard levels. Sounds basic, doesnt it? “Its astonishing how few people have figured this out for databases,” Julian told me. Everybody knows what server software theyre running with xyz patches, what password policies are, etc.
But if youre not auditing databases on an ongoing basis, and making sure theyre up to whatever level of update your enterprise has defined as being its baseline, you dont know how secure your database is, even if youre 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.
Intrusion detection comes into play next, to provide real-time protection while youre busy patching all of those databases, serving to alert and shut down an attack before it can cause damage. Thats why its deployed on the network, and thats why it should be deployed on the database.
Encryption is your last line of defense, when theres no patch yet available and theres no signature for identity detection. It will keep somebody whos about to gain root access to your database from actually getting your customers credit card numbers or Social Security numbers, for example.
This is where you get into the question of what to encrypt, and theres 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 theres certainly overhead implied in either case, whether theres the abstraction layer of file encryption or not.
CERT/CCs Manion says they both imply different kinds and different amounts of overhead, depending on what file system youre talking about, what database youre using and what type of database encryption youre 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 whats stored in there, it might make sense to encrypt a directory, Manion says. If youre talking about an internal server that contains internal phone and contact information for an internal staff, and its 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, youre adding another layer of logging on and/or passwords. These things dont come free.
Next Page: The tough question of estimating damages post-breach.
Estimating Damages
Another option is to sift out information that isnt accessed much and put it into a separate directory, thus giving yourself a lightweight directory thats available unencrypted.
Manion suggested a scenario in which you have an LDAP directory available via a Web interface, connected via SSL (Secure Sockets Layer). Thats 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 its very, very sensitive, perhaps it doesnt belong in a globally available directory in the first place.
How can I estimate the damage done to my companys 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. Its a fair question to ask, but its tough to find recent studies on the topic. Im 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 Seltzers 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 companys 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 wasnt a pretty sight. Ill let you know when I come up with a more specific formula, but in the meantime, tell your management that youd rather not find out firsthand.
Write to me at lisa_vaas@ziffdavis.com.
eWEEK.com Associate Editor Lisa Vaas has written about enterprise applications since 1997.
Check out eWEEK.coms Database Center at http://database.eweek.com for the latest database news, reviews and analysis.
Be sure to add our eWEEK.com database news feed to your RSS newsreader or My Yahoo page