Yet another intrusion with data theft, yet another chorus of yells for "encryption.” I refer to the eBay intrusion from last week with the subsequent hysteria over their not encrypting certain personal information at rest. "It is inexcusable for a company the size of eBay with the amount of data it holds to not encrypt all personal information held,” said Trend Micro’s Rik Ferguson.
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. This is a superb use case for encryption, because the risk/reward ratio is so skewed toward 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.
(Picture from xkcd.com)
It's when you start trying to apply the same principles to 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 doesn't help you when a user goes "bad.” There's no way to generally 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? Is it encrypted? Is it stored on a file share, perhaps? On an e-mail server? Are you prepared to perform all of the process flow analysis to ensure that every data avenue is protected? If an attacker were on 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.
Keep the right perspective as you think about encryption at rest:
- Data minimization—have you followed the principle of data minimization and only retained 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?
- 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.