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