<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=2923012&amp;fmt=gif">

Database Security—Repelling a Breach with Defense-in-Depth


Database Security—Repelling a Breach with Defense-in-Depth

Lily Hay Newman, in a recent article in Wired, pegs “poorly secured databases that connect directly to the internet” as a main culprit for many of today’s mega data breaches. Why? Robust database security offers a defense-in-depth strategy should an attacker breach your perimeter defenses. But if the security measures are left unused, the sensitive data presents an easy target for hackers to go after.

In the article, Newman points to the increasingly popular open source NoSQL databases as being chronically underprotected. Their ease of deployment means that those with little experience in cybersecurity best practices can spin them up without the proper protection in place.

And while I agree the quick deployment that NoSQL databases offers can sometimes lull users into ignoring data security best practices (or put it off until it is too late). We work closely with enterprise grade NoSQL providers like MongoDB, and what I can tell you is, they are passionate about data security. They work tirelessly to ensure that their users have every tool needed to properly secure their data.

The truth is, it doesn’t matter what database you use, if you aren’t adhering to data security best practices, you are inviting a breach.

Database Security

The good news, for those that are looking to create a defense-in depth strategy for their databases, there are policies and tools you have, already-baked-in to most databases, that can help. Here is a brief look:


All users should be required to authenticate themselves before gaining access to the database. Typically achieved by presenting the correct login credentials (username and password), this represents the first line of defense for your database. That being said, here are a couple things to consider when setting up your authentication protocols.

  • Password rules: Every year online publications, like Fortune, publish the list of most commonly used passwords and every year the same usual suspects top the charts. When able, you should force users to create unique passwords that avoid the pitfall of using easily guessable passwords. Tip: Using longer passphrases that are easy for the human mind to remember but almost impossible for a hacker to guess is a great way to go (example: !passphrases-are-hard-for-hackers-to-crack#).

  • Password management: The truth is, no matter how unique your passwords are, no one person can remember the hundreds of passwords they create. That is why using a password manager is the only practical solution. This allows your users to comply with your password rules while still being able to easily use those hard to crack passwords.

  • Use only encrypted channels: When logging into a database, you should use encrypted channels to relay both usernames and passwords whenever possible. As an example, Microsoft notes that using Windows authentication is best practice as using SQL Server’s security sends the password encrypted, but not the username. And while usernames tend to be generic, it is one more hurdle hackers can easily overcome in gaining access to a database just by sniffing network communications.


Once someone has been authenticated, the next thing that must be determined is their level of authorization to view or manipulate the data.

  • Role: A role grants users/applications certain privileges to view, edit, or perform other specified actions within the database. When setting up roles, you should adopt the principle of least-privileges. Administrative tasks should be given sparingly, and granting a user the use of the ‘sysadmin’ role should be severely restricted.

  • Permissions: Typically, a user’s permissions are assigned to reflect the role they perform.

  • Data Encryption: All sensitive data should be encrypted both at-rest and in-flight with robust, standards based encryption. The encryption keys should be stored within a centralized encryption key manager and users/applications only granted access to the keys if they are either authorized to view the unencrypted data or they are personnel designated to manage the lifecycle of the keys.

Listen, attacks are inevitable. But that doesn’t mean that they have to end in a breach of data. By conforming to database security best practices, you can ensure that no matter what database you use, you to keep your data safe.

This blog post was written by Ken Mafli. Ken Mafli is a Data Security Evangelist at Townsend Security and their Senior Digital Marketing Manager. For the last five years he has helped enterprise level clients around the world secure their data with Townsend Security’s encryption and key management systems. He regularly writes on the topics of data security trends, cryptography, and the changing landscape of the industry.

The Essential Guide to IT Security Strategy