Being in the security industry we’re constantly confronted with the problem of protecting data in transit and data at rest. Of course, everyone has a different way of describing data traveling somewhere and data staying somewhere semi-permanently, but I digress. In any case, data at rest or data’s primary place of residence has been a nasty little problem these days. Many will tell you that it solves the worlds problems. It protects data from bad guys and from good guys we don’t trust (which is sort of an oxymoron isn’t it?). At least that is the perception. Various forms well-intentioned, but wholly uninformed pieces of legislation are attempting to mandate the implementation of encryption at rest. I hear of products for database encryption, filesystem encryption, whole-disk encryption and others.
Many people have fallen victim to the “Use encryption and your data will be protected” fallacy. The have made the mistake of equating the use of encryption with the mitigation of a broadly defined set risks or risks are not defined at all. Sure, it makes people sleep well at night, but only because they think their understanding of the situation is complete and correct. Unfortunately, this is not the case and the sleepful nights should be coming to a close.
Encryption at rest solves one problem. Physical compromise. Yes, it’s true and I know it is hard to believe. It does reasonably well if someone walks into your data center, home, office or what not and walks off with your computers. I must add, though, that this too only works if your data is not currently “decrypted for use”. If it is, you fall victim to the usual attacks. So, to clarify it solves the physical compromise problem as long as your data is actually encrypted at the time of attack. In all other cases encryption at rest is useless. It is useless against a successful attack against an application and associated components that process the information. It is useless against a successful compromise of a system hosting your information. It is absolutely useless against the administrator you’re not sure about. Here’s why..
The application attack is aimed at the unencrypted data stream and therefore not protected by encryption at rest. The application (I’m using the broad definition here) processes the “real” data at many points so it is a grave mistake to presume that encryption at rest protects data as it is being processed.
The system attack is aimed at gaining access (usually elevated). It is a small step on many systems to get privileges that enable you to retrieve keys, passphrases and other material that is required to decrypt the data at rest. Nevermind those pesky out-of-band crypto-machines. The unencrypted stream has to get there for it to work.
Administrator trust issues? Yeah, you have serious issues if you don’t trust these guys. Sorry to say this, but if you don’t trust your administrators you trust them implicitly. Game over. If you have elevated privileges on a system or software the game is over. See the system attack for a sampling. The best you can do here is detect, but even that is problematic in the administrator game. Since they are “god” on systems and software they can potentially control entry and exit points.
The list can certainly be expanded and elaborated. Even this sketch is a compelling case for why people who use encryption at rest are not solving the problems they think they are. They shouldn’t be sleeping well at night, because their data is no more protected than it was prior to shelling out hundreds of thousands of dollars on products and services.
Again, encryption at rest is useful for the physical threats. The usual threats are laptop thefts, tapes falling off of trucks, DVDs being thrown away, etc. Laptops, mobile media and even servers with data being shipped across the country are all cases where this solutions works well. Using it for anything else is big money sink that could have been used to enhance all of the other relevant controls that can support the protection of data at rest.