Data Encryption: 4 Common Pitfalls

Employing data encryption is a no-brainer, as it supports the defense-in-depth strategy that organizations must embrace to stop bad actors from accessing sensitive network files. However, outside of the extra layers of protection data encryption can provide, there are also tradeoffs in network performance and complexity that might arise when organizations aren’t approaching encryption thoughtfully. Here are four pitfalls to avoid as you begin encrypting content.

Pitfall One: Proprietary Algorithms
It may seem counterintuitive to the way many effective security strategies are designed and implemented, but relying on standardized algorithms to encrypt sensitive data is actually safer for organizations than tasking their own IT staff or developers with crafting a unique encryption algorithm or even authentication system. The reason for this is that cryptography is its own specialization that requires an advanced degree of scientific and mathematical precision. While specific individuals from in-house security teams may have this highly specialized set of skills, dedicated cryptographers have devoted their sole attention to crafting industry-standard algorithms like IDEA 128-bit and ARC4 128-bit – more attention than an IT generalist or cross-functional developer could devote given the wealth of other projects in their purview.

Pitfall Two: Full Disk Encryption
While it is essential to ensure that data is encrypted while at rest and in motion, considerations must be made for the systems that manage that encryption.

Full Disk encryption, for instance, is designed to prevent access to sensitive data if a device or its hard drive(s) are removed. When the device is on, and a user is logged in, the sensitive data is available for anyone who is logged in – including bad actors who may have a backdoor into the system. In a roundabout way, this highlights challenges with key management. No matter how strong the crypto, if the key that provides the ability to return the content to plain text is available to adversaries, its game over.

Pitfall Three: Regulatory Compliance
Across most industries, rules regarding data collection, sovereignty and storage are extensive and usually mandated by legislation at the local and federal level. While regulations like HIPAA, PCI, CJIS and CIPA go far in detailing the costs of noncompliance, they are less instructive in telling businesses how to avoid it. In fact, many of these regulations don’t mention data encryption at all, even though encryption can prevent many of the most egregious regulations from taking place. These laws may represent a good starting point for mapping out a security strategy, but teams need to be diligent about going beyond just the standard “checklist” of protocols and standards many of these mandates provide.

Pitfall Four: Decryption Key Storage
Even after teams have gone about extensively encrypting their data, many developers make the mistake of storing the decryption key within the very database they are hoping to protect. After all, encryption is a means for protecting data even after bad actors have infiltrated the data base. If the key to decrypt all that data is basically hiding “under the doormat” right on the other side of the network gateway, all those efforts to encrypt are basically worthless.

As a result, many teams are exploring "Key Encryption Key," "Master Encryption Key" and "Master Signing Key" encryptions that they store elsewhere to protect enterprise data – a step that may seem excessive to some, but provides an all-important level of assurance that minor missteps don’t curtail major security operations.