Yet another intrusion with data theft. Yet another chorus of yells for encryption. I could be referring to the eBay intrusion from last year (or the Sony incident from November 2014…or any number of recent data loss incidents) with the subsequent hysteria over their not encrypting certain personal information at rest.
It has become quite fashionable these days to say "if only the information had been encrypted." The problem is not that simple, either from a privacy or security perspective. From a privacy perspective, the motivation is “don’t let someone who doesn’t need to see the information see it.” From a security perspective, the motivation is “don’t allow someone to violate privacy and then misuse the obtained information." They’re very closely related and wherever we talk about security (or privacy), we really mean both. Encryption at rest solves a small set of problems really well:
Unauthorized physical access, loss, or theft of portable devices, including laptops, USB drives, and other mobile media form superb use cases for encryption, because the risk/reward ratio is so skewed towards reward. That's one reason the Massachusetts privacy law MA 201 CMR 17 specifically requires "encryption of all personal information stored on laptops or other portable devices."
- Backup media and other information that is constantly in transit. This is another excellent use case. Data is on backups. Backups move around on trucks. Backups fall off the back of trucks. The impact is catastrophic. Encryption completely makes sense.
- Protection of individual files with sensitive information. For instance, an HR user who downloads sensitive employee information for work reasons to their computer must either encrypt the file manually or have it on an encrypted disk to start with.
It's when you start trying to apply the same principles to bulk data on servers without thinking correctly about it that you start getting into trouble. Let's talk about what encryption at rest does not do:
It doesn't help you when logical access to the system is gained through other means. For instance, a guessed or cracked password; through an application level attack, such as SQL injection; a user level attack, such as phishing. Remember that encryption must still make data available to the user on demand, so if an attacker has the ability to become the user, you're toast. How do you prevent that—perhaps with stronger authentication (e.g. two-factor authentication)? This now becomes a harder problem than just let's encrypt everything, doesn't it?
It also doesn't help you when a user goes ‘bad’. There's no way to predict this or, for the most part, respond to it. You could do strict segregation of duties and two-person controls, if you can afford it (the government can, but how many businesses can?), but encryption doesn't really help you protect against this attack either.
Encryption at rest is fine and dandy, but what about the transmission of data on your network? Are files encrypted? Stored on a file share, perhaps? On an email server? Are you prepared to perform all of the process flow analysis to ensure that every data avenue is protected? If an attacker were to gain access to your network and couldn't get to the encrypted database, could they simply sniff network traffic instead?
This is where concepts such as privacy by design come into play—you anticipate threats to privacy and counter them early in an application’s lifecycle. It’s a lot harder to do this for a legacy application.
Encryption can (eventually) be brute-forced. Of course, this is also a good thing—it means that it buys you some time to put in countermeasures, change passwords, warn banks and consumers, etc. But most people think that encryption "solves" the security problem entirely. Not by a long shot.
You need to keep the right perspective as you think about encryption at rest. There are a number of key points:
Data Privacy:
- Data minimization—have you followed the principle of data minimization and retained only the data that you need for business purposes and disposed of it after its useful life has expired?
- User access control—do you have a solid user access control program in place so that only people who need certain data access have it?
Data Security:
- Vulnerability management—are you actively scanning your systems like an attacker would to ensure that you are as protected as possible?
- Data protection—are you implementing controls such as data leakage protection and host intrusion detection/prevention to try and stop attacks from happening?
Data Privacy and Security:
- Segregation and segmentation of services—are your sensitive services walled off physically or logically from less sensitive ones so that you can apply the rigorous security controls selectively?
- Monitoring—do you have the right instrumentation being generated and monitored so that when someone breaks through your controls—and they will be broken, make no mistake about that—you are able to quickly detect it and apply countermeasures?
- Screening, training and awareness—do you have the right hiring policies in place? Are you ensuring that employees are trained appropriately about the dangers of phishing and social engineering?
The point I'm trying to make is that without a solid security and privacy program in place to start with, encryption at rest is like applying duct tape to a broken bone. Encryption has its uses and it can be effective as a security and privacy control, a safe harbor control, and as a compliance measure. But if you're not careful about realizing its limitations and communicating them to your executives, you're the one that will be in hot water when an incident occurs.
(Picture xkcd.com)