7 Key Database Security Best Practices



We all know that there is no data security silver bullet; there isn’t a perfect database security plan. That said, we keep seeing media reports about global organizations that seem to have failed to secure their data on the most fundamental level. You’d hope that it would take a very clever bit of malicious hacking to get into what should be a sophisticated system, but too often it turns out to be a basic configuration error.

The problem may be budget-driven or a matter of misunderstanding, or it could simply be that defending against advanced persistent threat (APT) and other patient, stealthy attacks have just worn us down. Whatever it is, we can’t give up. And the best way to prepare to rejoin the fight is by reviewing the mistakes most commonly made and developing our own database security best practices.

1. Protect Your Backups

There’s a huge temptation to use backups in test environments, in lieu of live data. This leads to companies having to announce, “Yes, we were hacked but hey, all the compromised info was old.” Old data can be used in a myriad of bad ways. Protect your backups as stringently as you protect the actual database, and make sure your security policies cover all copies of critical data, not just the most current live copy.

2. Hack Your Own Database

Hacking is also on the list of database security best practices. Actually, here’s hoping you don’t need to be reminded to run pen tests often, both internally and ones conducted by outside experts. We all know that it’s far better to successfully attack yourself than to have some malicious kid find the security hole you missed. Just make sure you let the DBA know what you’re planning before you launch a hack attack and document the plan so an auditor doesn’t get the wrong idea.

3. Don’t Trust Other People’s Code

Those community resources make life so much easier – just reuse someone else’s code to save time, right? Sure, but make sure that you test and test again to make sure that bad code isn’t sneaking into your nice clean app ecosystem. It’s a good policy to hold developers responsible for all the code in their apps, not just the segments that they personally created. Also, keep a close eye on security flaws that may creep into application frameworks, and stay up-to-date with those patches even if it seems to be a daily event.

4. Beware of User Input

This is a well known issue, but it’s still far too prevalent. Validate all those input fields and parameterize queries, or run the risk of handing over terminal access to your database to anyone who knows the power of a single punctuation mark inserted into a too-trusting form field.

5. Don’t Provide Helpful Hints

Detailed SQL query error messages may make troubleshooting easier, but they also provide actionable information on the database to anyone who happens to see the error. Don’t make it easy for people to understand database structure and query processes. Go with a generic error message.

6. Bring in the Encryption Experts

This is not an area where a general understanding of the topic is good enough. If you don’t have someone on staff (or on call) who knows encryption inside and out, chances are you’re doing it wrong. Implement cryptology properly, and make sure your staff knows exactly what threats and vulnerabilities encryption can and cannot address. And don’t let other departments talk you into leaving sensitive info unencrypted simply because it’s faster to access in an unprotected state! Sensitive data should be encrypted at capture, in transit, and at rest – no excuses.

7. Don’t Forget Disaster Planning

Securing databases requires protecting them from natural catastrophes and human error as well as from criminal attack. Review your recovery plan; test it and your backups regularly. And ensure that your plan dovetails with current data retention compliance requirements as well as your own document governance standards.

And here’s one last tip. Database security best practices include the necessity for creating a comprehensive failure plan. Think through and document in detail your entire process of dealing with a breach, and then update your plan often. No one can prevent every single data-disastrous event from occurring, but intelligent planning will help mitigate the damage.

Joseph Janecka
Joseph Janecka is the Vice President of Information Systems and Technology for SalesStaff, where his responsibilities include alignment of technology systems and management of SalesStaff’s vast data assets. Joseph’s contributions to client campaigns include alignment of marketing automation, enriched sales and marketing analytics, and campaign tracking enablement – resulting in increased pipeline velocity and an enhanced level of qualification for leads and appointments delivered to SalesStaff customers. In his position, Joseph continues to execute on a comprehensive Information Technology roadmap and set the vision for the future of SalesStaff’s information systems.
Joseph Janecka

Written by Joseph Janecka


Joseph Janecka is the Vice President of Information Systems and Technology for SalesStaff, where his responsibilities include alignment of technology systems and management of SalesStaff’s vast data assets. Joseph’s contributions to client campaigns include alignment of marketing automation, enriched sales and marketing analytics, and campaign tracking enablement – resulting in increased pipeline velocity and an enhanced level of qualification for leads and appointments delivered to SalesStaff customers. In his position, Joseph continues to execute on a comprehensive Information Technology roadmap and set the vision for the future of SalesStaff’s information systems.

View all author posts →




What's Next?