Are Your Protecting Your DB Backups?

Brian Kelley, 2012-11-27

tapes by twicepix, on FlickrFolks have cited the recent InformationWeek article on how South Carolina’s Department of Revenue was hacked because the SC state government basically said, “It’s the IRS’ fault for not telling us we should encrypt social security numbers.” I’m not going to touch that. It stands on its own for its foolishness. However, I did key in on how the hack happened and how the data was obtained. I found this bit to be particularly interesting:

“But with more work, by Sept. 12, 2012, the attacker had successfully located and begun copying 23 database backup files, containing 74.7 GB of data, to another directory. Soon, the attacker compressed the data into 15 zip files, transferred them to another server, sent the data to an external system — outside the state’s control — and deleted the zip files to help hide the data breach, according to Mandiant’s report.”

In other words, the attacker, once inside the trusted network, located the database backup files, zipped them up, and then copied them offsite. That’s how the data was lost. The database backups were attacked.

The article does point out that the stolen credentials allowed the attacker to use the system and query the DB. That makes me think that any encryption could have been beaten, because access would have come through a “trusted” app. However, by just copying the backups off, encrypted fields would have stayed encrypted. Which raises the question:

What are you doing to protect your database backups?

One of the questions I have is whether a “normal user” was compromised or was it a privileged user like a DBA or a system administrator? If it wasn’t the latter, then the fact that the attacker was able to get to the database backups gives me pause. Password dumping utilities were used, but to what extent and what accounts were compromised wasn’t listed in the Mandiant report. If a privileged account was not obtained, if the database backups were obtained via an end user’s login, that’s a serious security no-no. However, I can see it happening. All it takes it someone creating a share, which defaults to Everyone having Read access and then checking for Everyone to have Modify access instead. Obviously, that shouldn’t ever happen, but we know that all too often it does.

It’s not just SQL Server that we have to protect. We have to protect the backups, too. You could use TDS and if you do, the backups are already encrypted. You should be ensuring that wherever the backups get written to, that only a chosen set of accounts can access that location. Certainly, if your backup software supports encryption, any database backup containing PII or any other sort of sensitive information should use that feature.

When I look at what happened, I have to shake my head. You aren’t going to stop the end user from clicking on a link and getting infested with malware. But you can stop the attacks that happen afterwards. That’s what’s most disappointing. The SC DOR got beaten by techniques we’ve known about for years. It didn’t have to happen.






Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

Robert Davis


1,567 reads

Networking – Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I’d like to talk about social networking. We’ll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let…

Andy Warren


1,530 reads

Speaking at Community Events – More Thoughts

Last week I posted Speaking at Community Events – Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I’ve got a few more thoughts on the topic this week, and I look forward to your comments.

Andy Warren


360 reads