Welcome back to our series on relational database security. In our previous post on enforcing third normal form, we discussed how proper schema design promotes security. Specifically, the primary key column should uniquely identify a row and include a non-prime attribute, such as a credit card, driver’s license, or national identity number.
And while proper schema design is necessary for improving database security, it’s not sufficient. The Identity Theft Resource Center (ITRC) found that even with fewer data breaches in 2018, Personally Identifiable Information (PII) loss increased well over one hundred percent. Those of us responsible for governance and security should protect our databases, usually via a form of encryption.
But how to protect a database? There are multiple types of database protection technology with varying “ease of use” levels. Choosing the optimum type depends on how isolated a particular database server is from the enterprise data network. And an organization’s compliance and governance policies.
Let’s define three types of database protection: transparent data protection (TDE), in-cell encryption (ICE), and application-level data protection using format-preserving encryption (FPE). We can characterize these types of protection as follows:
- TDE is provided by the database vendor and involves encrypting tablespace blocks. TDE is similar to yet separate from other data-at-rest protection technologies, such as disk encryption.
- ICE is provided by the database vendor or an independent software vendor and involves protecting data after connecting with yet before modifying a database. ICE protection does not interoperate with other data stores, such as data lakes and warehouses.
- FPE is provided by an independent software vendor and requires protecting data within the consuming application. Unlike ICE, FPE may applied prior to making a database connection and does interoperate with other data stores.
Let’s think about these encryption technologies based on database coupling: TDE is the most coupled, FPE the least, and ICE is between. The more coupled a protection technology is to a database, the easier it is to use with one database. The less coupled, the easier it is to use with multiple databases. The suitability of these technologies for an organization depends on how data flows within that enterprise.
Another way to compare these encryption technologies is based on key management and separation of duties: where are encryption keys stored and who may access them?
- TDE usually integrates key management with the database. Database administrators (DBAs) have access to encryption keys.
- ICE may integrate key management with either the database or a separate key manager. ICE may or may not integrate with a hardware security module (HSM). DBAs usually have access to encryption keys.
- FPE key management is never integrated with the database and does integrate with an HSM or other key management hardware. Key access is independent of database access and managed by someone besides a DBA.
We may also think about how loosely or tightly coupled key management is to a particular database encryption technology. TDE uses the tightest coupling, FPE the loosest, and again ICE is somewhere between. Depending on your organization’s compliance and governance standards, a particular technology may or may not be more appropriate than the others.
Let’s now talk about which of these technologies would be more beneficial for a particular use case. We’ll start with TDE. This technology is most ideal when the data is isolated (used only on one particular database server), separation of key management from database administration duties is of low or no concern, or application changes are difficult.
FPE, as one might guess, is a better choice in the opposite circumstances. FPE is most ideal when data is shared throughout an organization (no decryption prior to transport), compliance and governance requires independent key management, and application or network integration of an external encryption technology is possible.
And ICE is a compromise. It may offer greater separation of duties than TDE and greater ease of use than FPE. However since ICE is coupled to the database, one may need to use another encryption technology or key management system anyways when transferring data to another storage mechanism.
What is the best choice for your organization? Focus on two aspects: data flow and key management. Enterprises with integrated systems that regularly transfer data are best served by FPE. So are those where life-cycle key management cost and governance considerations are genuine concerns. Enterprises with isolated databases that do not share data might be better suited with using TDE—as long as key management remains under control. Can’t decide on the most suitable technology? Then developing a priority-based security strategy is best practice.
Before making this decision, however, consider how partially protecting data items with FPE eliminates the need for run time decryption in almost all use cases. Which will be the subject of our next post!
Meanwhile what are your thoughts on the matter? Have you participated in a team rollout of FPE, ICE, or TDE? How did the chosen database technology help your organization mitigate a breach? If you have a thought on these matters, please leave a note in the comments section below.
 The ITRC, a “non-profit organization established to support victims of identity theft in resolving their cases and to broaden public education and awareness” is partially funded by the United States Department of Justice. Connect with them for resources on mitigating a data breach.
 PII includes data items such as birthdates, email and street addresses, names, national identity numbers, passport data, and so on. PII can be abused to commit fraud and theft.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.