Encryption: Pros and Cons

The expression “when you are a hammer, everything is a nail” has a curious background. The concept belongs to a generalized law of the instrument which is a cognitive bias that occurs by being overly familiar with certain tools, and the likelihood of force-fitting problems to the tools at hand. As with all good quotes, several famous thinkers across the times are credited with its origination—from Buddha to Abraham Maslow to Mark Twain—but regardless of the source, the law has increasingly been adopted within computer science. Except in the case of computer science “when you are a hammer…” is more often viewed as the “anti-pattern”—as in, just don’t do it. Get out of the comfort zone of using routine approaches to problems and instead seek exploration and alternatives in order to achieve more optimized solutions.
Perhaps nowhere do the habits of “hammer and nail” thinking exhibit themselves more than in the approaches of encryption to secure databases. Need to protect data? Encryption must be the answer! And it’s easy to understand why, breaches are hitting databases in record percentages, and the promise of a data lock—encrypting data to render it locked, blocked, and utterly useless—in a breach or exfiltration is very appealing. Yet while the tools for encrypting data at the volume, column, or cell level are multiplying, lets examine some of the ways encryption is becoming a double-edged sword…useful but not wholly sufficient for data protection.

(Also, check out our Gartner report, “How to Use the Data Security Governance Framework,” where you’ll learn how to use data encryption and other strategies to mitigate the risks caused by security threats, data residency and privacy issues.)

A Security Standard

The question of should companies and organizations be utilizing encryption to better protect databases has essentially been answered with a resounding YES. At the session level, connections to the database can utilize advanced Elliptic Curve Diffie-Hellman Exchange (ECDHE) in both major database engines from Oracle and Microsoft, as well as increasing numbers of open source and data warehouse data systems (Postgres, MySQL, Teradata, Hadoop). Enabling either ECDHE and/or SSL should be the default choice for improved session security. At the database volume level, transparent data encryption (TDE), which serves to encrypt the whole volume of the database, gives customers a sense of protection, and will protect against broad (what we might call “wholesale”) attacks at the storage media of the database. All major database vendors should be applauded for making basic TDE rather effortless and truly “transparent” from a database application standpoint.
Unfortunately, TDE on its own may provide a rather false sense of security. With volume encryption, the protection is primarily against someone already inside the data center and outright physically stealing the storage media of your database, which is probably the attack vector in less than .1% of the largest breaches and attacks.

Volume Encryption Only Protects Data at Rest

More practically speaking, volume encryption is protection ONLY against data at rest, and ONLY against data not being edited. In general, that’s not going to get you very much. Any user or application that needs to edit the data will need the keys to unlock the volume. So, unless you “hit harder” with that hammer, and consider finer-grained encryption, such as encrypting at the column level (to better control columnar access), or data-centric protection at the cell/data element level (the more specific data protection offered with encryption), this hammer isn’t going to stop too much.
Therein lies the big problem with encryption. It’s the first tool you reach for, but it becomes exponentially harder to deploy at the levels that give you the most protection.

The More Protection You Seek, the Harder to Implement

This is the straight trade-off of encryption and reveals the limits of easy answers for data protection for databases. The more protection you seek with encryption, the harder the implementation becomes to deploy, configure, manage, and recover.
Volume encryption cannot provide any degree of access control or sensitive data separation; on the other hand, cell-level encryption gives you near perfect, strong control over each and every element—but every dependency and application relying on this protected data just got ten times harder to manage and scale.
See below for a summary of pros, cons, and recommendations for common encryption methods:

Encryption and Ransomware

But sometimes you whack at a hammer and there are no nails at all. It’s interesting to note that one very obvious place where encryption has zero protective value is in the database ransomware attack vectors. Encrypted data is, in theory, equally vulnerable and attackable to ransomware actors.  Here we can see the outright limitations of database encryption as comprehensive protection. If your goal is to limit or control access, encryption on its own won’t do it.

A Blended Approach to Data Security

As noted in the introduction, the risk of hammering everything pre-supposes the answer before all the right questions are asked. In the case of database protection, perhaps one of the biggest questions is around access and acceptable access. Encryption assumes that all correct access is occurring—that the right people are getting the keys to open the locked data. But how?
The best approaches to data security blend encryption with other services and protections, such as:

• Database Activity Monitoring: In many regards, database activity monitoring is highly complementary to database encryption. Knowing that your most private data is encrypted can provide peace-of-mind. With activity monitoring, you can add a layer of understanding and alerting around all database access, via encrypted datasets or not.
• Machine Learning and Peer Group Analysis: To gain more protection against insider threats, database security can be augmented and strengthened with machine learning and peer group analysis that can automatically detect and uncover anomalous user behavior. Simply put, building a full contextual baseline of typical user access, security teams can efficiently investigate the most worrisome data access events and take a deeper look into a specific incident to view granular information about the user and the data that was accessed. Locked, encrypted data, in and by itself, won’t tell you which access requests are strange or odd, outlier or higher risk.
• Data Masking: Lastly, if your data is headed to non-production, data masking is the recommended best practice to replace the encryption hammer in your toolset as it can offer the same degree of cryptographic protection, and if you don’t need to achieve reversibility, can avoid most of the pitfalls above.

Only as Good as the Keeper of the Keys

Clearly, there is a role and place for encryption in data protection—and a critical, principal role in session communications. But this protection will not and cannot, by itself, answer the question of correct access to data. A lock is only as good as the keeper of the keys. The next time you find yourself picking up the encryption hammer as the answer to database protection, be sure to ask yourself if you’re using the right nails.