September 25, 2015 at 6:23 am
They wont be able to read the backup file in its raw format, but if they have also intercepted the master key, database key, certificates etc all they need to do is crack the passwords and they can restore the DB anywhere they like. Granted this needs the full backup to restore, and going beyond the original post, but still worth noting.
Granted this is beyond the capabilities of most people but if your dealing with an extreme hacking group they could do this.
Just take a look at the recent Ashley Madison breach, they managed to reverse AM's encryption on passwords, all it takes is time.
Hashing the data in the database and salting the hashes then getting the apps to do the same and comparing the hashes is a better option as the hash shouldn't be able to converted back to its raw format.
September 25, 2015 at 7:20 am
Steve-3_5_7_9 (9/25/2015)
Your direct question has already been answered, however the audit will probably turn up a couple of things:If they stole the diff backup, why wouldn't the full backup be stolen as well? Is the full backup off in another location?
Why isn't TDE being used? It protects data at rest and a text editor wouldn't be able to read the "string" as anything usable.
It also raises the issue that if someone with malicious intent has access to your backup files even if they can't steal information off them what can they do to your recover strategy?
September 25, 2015 at 7:32 am
From an audit/risk perspective, yes, they can read data in a diff file, as noted.
In terms of mitigating risk, you can use encryption, which isn't perfect, but nothing is. However encryption usually passes audits. You likely will store the encryption keys on the backup tape, so make sure there are strong passwords. This isn't perfect, but from a practical standpoint in disasters, you need the key.
If you use third party products, like SQL Backup from Redgate, the compression occurs before encryption, so things are small. If you use TDE, the pages are encrypted and don't compress.
Disclosure: I work for Redgate Software.
September 25, 2015 at 9:40 am
Regardless of industry, whether it's healthcare or adultery, table columns containing personal identifiers should be encrypted and then downstream applications, ETL processes, and backups should decrypt only as needed and just in time. That way you mitigate the issue of secure data suddenly becoming insecure simply because it's getting backed up or copied from production to QA.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply