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.
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.
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.
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:
Method | Pros | Cons | Recommendations
Whole Database Encryption (aka TDE) |
Automatically protects backups |
Limited to zero protection against application-level and insider attacks
Many major breaches achieved with TDE turned on |
Should be considered a good “base” practice
Needs augmentation to achieve protection and audit
Column Encryption |
More flexibility in what you choose to encrypt
Keys per column improve isolation/protection |
Greater impact on performance (5-15%)
Ensure referential integrity between primary/foreign key columns
Field-level (aka cell) Encryption |
Highest protection—applied directly to each and every field or value
Better audit trails |
Hugely disruptive to business applications; all DB functions need a priority mapping of what’s been encrypted
Potential for large performance, latency impacts (20-40%) |
Most powerful when the sensitive data can be restricted to very few elements (PCI scope reduction for credit card data for example)
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.
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:
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.