I have encryption on my mind again a lot lately. It certainly has something to do with work in progress for presentations I’m giving at our Catalyst 2012 conference (“Protecting Data in the Public Cloud: Encryption, Obfuscation, or Snake Oil?” and “Scenarios: Encryption, Tokenization, Anonymization, or None of the Above”). But it’s also because I’m seeing an increase in talk about encryption in general. Not just interest, but a real push for encrypting data as much and often as possible.
Although I can understand the occasional article having lines like referring to LinkedIn’s passwords as “lightly encrypted,” I really do not have much sympathy for experts prescribing encryption for most security ailments … especially because its often discussed without fully weighing its side effects (increased risk of data destruction and an empty wallet being two of the more prevalent). And in some cases these side effects are definitely worse than the cure.
A case in point: lately I’ve been getting a lot of customer questions about encryption data in applications and databases. When I ask why they want to encrypt, the answer is often that someone (e.g., a business partner or auditor) tells them it’s “required by regulation” or “best practice.” Although they mention encryption, very few – if any – regulations can be said to mandate it, especially inside the data center. And whether it is a best practice – even though some data shows fairly signification adoption of database encryption – is certainly up for discussion in my book.
Lucky for us, encrypting applications and databases isn’t exactly cheap and sticker shock usually leads to re-assessment. But even when a team is convinced they should implement such encryption, asking the question “who and what are you trying to protect from / have you performed a threat assessment?” is often met with silence. We end up discussing the limitations of encryption and may well come to the conclusion that the investment (implementation as well as ongoing management costs) might be better spent on different preventative controls (e.g., finer-grained access control) or altogether different types of controls (e.g., activity monitoring). In short:
- Don’t encrypt data unless you have to or unless it provides appropriate protection for a given use case.
But one thing is almost certain for the foreseeable future: overcoming a perception that encryption is always the primary control choice is difficult at best.
For those who want to evaluate whether encryption is an appropriate control, my recently published “Solution Path: Choosing and Implementing Encryption” [subscription required] discusses how to approach encryption from an architectural / planning perspective, and incorporates the above advice.