Update: My opinions on this have changed due to the comments written below. Feel free to read this post, but make sure you read the follow-up post as well where I change my tune a bit.
Steve Duplessie wrote a blog post inspired by the RSA hack . His post isn’t about that hack at all. But for the record, I agree with this guy who says “RSA Silent About Compromise For 7 Days – Assume SecurID Is Broken.“
Steve’s blog post said that the lesson we should learn from the RSA hack is that anyone can get hacked. I would agree with him. He said that your security system should be based on that assumption. I would agree with that. He said:
Your security strategy should be based on the assumption that you WILL lose your backup tapes. You will be hacked. You will have your customer’s name, SS numbers, and bank account information published on a website.
He then goes on to say, “…if your binary data is going to go missing, it had best be encrypted. Encrypt it at rest, in flight, on the truck, on the disk, in the lab, in the warehouse, everywhere. Encrypt it so when you lose it, it gets stolen, or Chuck leaves the tape on his dashboard while at the bar, it can’t do you any harm.”
Let me start where I do agree. Encrypt your backups tapes. Encrypt your backup tapes. Let me say it again: Encrypt your backup tapes! With in-drive encryption built into any tape drive worth its salt, it’s a no-brainer. (You do need to make sure you have a good key management system.)
Where I don’t agree with Steve is when he recommends that you should encrypt your disk drives. (BTW, I respect Steve a lot and I’m sure he’ll appreciate this blog post as much as the next guy.) I will go with his assumption (that you’ve been hacked) and explain why encrypting data on disks at rest wouldn’t help.
If the host storing the data has been hacked. The hacker is accessing your system like any other user. Data encrypted at the drive level is automatically unencrypted for the host that is reading the data. It’s as if you aren’t encrypting — otherwise the apps reading the data wouldn’t be able to read it. Data encrypted at the application level doesn’t protect you if the server has been hacked, either, because the hacker can just become the appropriate user that runs the app, and voila! He sees the data unencrypted. What if the server isn’t hacked, but the SAN is? If the SAN is hacked between the host and the encryption device (assuming in SAN encryption, not host-based encryption), such as via WWN spoofing or the like, then they will be able to read the data as well, so you’re not protecting against that.
Let’s say you didn’t encrypt, and someone grabs a disk out of RAID array and runs off with it. They would only have part of the picture and they wouldn’t be able to read any data off that. (Update: Greg pointed out that this doesn’t apply if we’re talking single disk solutions, or one half of a mirrored double disk solution. He is right. This comment only applies to RAID 0+1,10, 5, 6, etc. where multiple disks are required to create a volume.)
The ONLY scenario that encrypting data at rest on disk protects you from is someone literally walking out of your datacenter with the entire disk array on their back and no one seeing it — AND that same person being dumb enough NOT to bring the (much smaller) system that can unencrypt the data with him. Yeah, that’s gonna happen.
Should every laptop hard drive be encrypted? Yup. Should every backup tape be encrypted? Yup. Should your smartphone have remote wipe and a really good way to prevent people from accessing it as well? You bet. They are way too mobile and have way too much sensitive data on them.
But I’m still not sold on storing data at rest on disk in encrypted form. But I honestly would love for someone to explain to me why I’m wrong.