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