Talking Insider Threat to Databases at ISACA Network Security

A few weeks ago, I gave a presentation about addressing the insider threat to database security at the ISACA Network Security conference in Las Vegas (thanks ISACA for having me!).

My session covered database security issues in general, then focused in on the threat from insiders and what organizations can do to protect themselves.

It was a very well attended and interactive session. Great to see the audit community showing such interest in data and database security issues!

The real interesting parts of these presentations for me are the Q&A session that happens at the end of my talk. The types of questions that get asked provide great insight into the data security problems that folks are dealing with day in and day out.

This time around, the most interesting questions were asked after the session during some one-on-one discussions. There was one question in particular I'd like to discuss:

My DBAs tell me that they have enabled logging on their databases and therefore their DB security work is done. They won't consider adhering to any best practices for configuration, nor are they willing to discuss patching vulnerabilities or fixing weak passwords. What can I do?

This came from an internal auditor at a large public company. Sadly, it's not that unusual a situation. The auditor is rightfully concerned about potential security issues in the databases that could lead to major data loss. The DBAs however want nothing to do with it, claiming logging is more then enough. They couldn't be more wrong.

Logging is important. It provides an audit trail of what actions have been taken in a database. Logging however does nothing to improve the security of the database. If weak and default passwords are in place, logging won't stop someone from breaking in and stealing data.

If vulnerabilities exist and can be exploited, logging won't stop an attacker, in fact depending on the vulnerabilities being exploited, logging may not even notice what's going on. Furthermore, logs are typically under the control of anyone with DBA privileges.

This means both the legit DBAs and anyone who has gained unauthorized DBA rights. Any of these folks can disable the logging system or erase the logs.

Information security is all about layers of defense, and the first layer in a database must be a secure configuration. Eliminating the weak passwords and establishing password controls, enabling security features, applying security patches, and practicing the principal of least privilege; these are the elements that bring real security to the front lines of a database system.

I encouraged this auditor to escalate the issues, and to come up with a set of security configuration standards based on accepted industry best-practices for securing databases for her DBAs to adhere to.

We also discussed how logging is different from Database Activity Monitoring, and that logs are only useful if they are frequently and carefully reviewed by someone who can differentiate between normal access and suspicious or malicious access.

A weekly review of the logs from all systems by one manager is not nearly enough. Even if an attack was captured, a week later it is too late to do anything about it...if indeed that attack can be identified by a quick examination of the logs.

Database Activity Monitoring would deliver much more value to their organization. By identifying and alerting on suspicious or malicious behavior in real time, and feeding that info into a centralized security event monitoring system, they can take action when something bad happens.

Even with a DAM solution in place, the need for a secure configuration and rigorous standards do not go away. Again we go back to the layered defense, and start with the basics. Itâ??s just like making sure to lock the door and close the windows before you enable your alarm system.

Let common sense rule when securing your data! Lock down your systems first, then monitor to make sure the controls you have in place are effective.

If you have questions about securing your databases, ask us at: