Protecting Relational Databases

“Insanity is repeating the same mistakes and expecting different results.”[1]

Protecting Relational Databases.pngWe can thank QuoteInvestigator for verifying the best definition of today’s typical database security practice was first codified not by Albert Einstein, but by a 1981 Narcotics Anonymous publication. And yes, I am asserting that, for the most part, our database security practices are the very definition of insanity.

Why? Well, back in December of 2013, Target experienced a massive, headline-gathering data breach that ultimately (according to their 2014 annual report) incurred net cumulative expenses of $162 million and an operating loss of $1,636 billion, ostensibly due to customer dissatisfaction and reputation erosion from this data breach.

Thanks to press coverage, this event is common knowledge. Many publications, including one sponsored by First Data, have recorded the mistakes Target made practicing security[2] that resulted in this breach.

So what’s changed? According to Brian Krebs, not much if anything. He reports that retail hacks are as lucrative as ever, citing such hacking has increased 250% over the past year.

And that’s the insanity of our current database security practices. They simply do not work. If we want actual database security in the first place, something must change.

So what should change? I propose a change from relying on solely on access control, or restricting who may interact with a database, to relying on data protection, or modifying how a database stores information. Our experience shows that access control alone helps yet is not sufficient. We also need database protection.

And how should we add database protection to our enterprises? In this blog series, we’ll discuss a series of posts addressing the mechanics of this concept. Here are the topics we’ll cover:

  • Enforce Third Normal Form (3NF): one characteristic of 3NF is that non-prime attributes may not be used in the definition of primary keys. Enforcing 3NF means that key columns by definition cannot contain sensitive data.
  • Choose A Database Protection Mechanism: for smaller operations, using the transparent data encryption (TDE) or in-cell encryption (ICE) provided by the database vendor may be worthwhile. Yet in larger operations, performance problems sharing data indicate format-preserving encryption (FPE) is a more suitable database protection mechanism.
  • Implement Partial Protection: One drawback of database protection is that the encryption reduces transaction performance. Yet we can avoid this degradation with partial protection, for example keeping the last four characters of an account number in the clear for authentication.
  • Add Alternate Coding Schemes: one can’t perform wild card matches on an encrypted name field. Yet express the same name as in Soundex coding, which may not be sensitive, and one can now accomplish such fuzzy searches.
  • Perform Discrete Range Searches: Can one perform range searches (number between two values) on encrypted data? Not if the ranges are continuous. Yet if the ranges are discrete, one can perform a range search by looking for a set of encrypted values.
  • Use Case Examples: if birth dates must be encrypted, how can we send out greeting emails on a customer’s anniversary? We’ll look at applying both of these methods (alternate coding and discrete searching) on this and other examples.

Databases occupy a significant position in the pantheon of information technology. They warrant special attention from us as security specialists. First, databases are “honey pots” of information that are a frequent attack target. Hackers go out of their way to exploit vulnerabilities and the rewards for bad actors are often worth it.

Second, however, databases, especially relational ones, conduct transactions based on set theory. Any security mechanism must take this into account. We also must maintain relational integrity. Otherwise the database becomes worthless for many of its intended purposes.

So over the next several posts, we will discuss protecting databases while taking these factors into account. Both by assessing how security technology can help and also by examining how we can design in efficiency, reliability, and security.

Meanwhile what are your thoughts on the matter? Have you been part of a database protection practice? Ever brought in to clean up the aftermath of someone else’s breach? If you have a thought on these matters, please leave a note in the comments section below.


[2] No disrespect to Target implied: information security, like medicine, is a formal practice. Its fluidity is something we must respect. No practice can prevent all data breaches all the time. Anyone claiming anything to the contrary is at best naïve.


Data security and encryption