Database Activity Monitoring Part 1 - An Introduction

silhouette of a person

Written By: Nigel Stanley
Published: 16th February, 2010
Content Copyright © 2010 Bloor. All Rights Reserved.

We are inundated with new technologies and products designed to help make our organisations safe from hackers and other malcontents. One technology that has gained ground over the past few years is database activity monitoring. It makes sense to protect valuable databases, and by adding an intelligent monitor capable of sniffing out threats an additional level of protection can be gained.

But what is database activity monitoring and why should you care?

Database security - some background
The majority of sizeable organisations will use a database of some description to store their vital data, be it contact data, customer lists, product data or any other valuable intellectual property. With the widespread use of relational databases, the chances are that a product such as Microsoft SQL Server or Oracle will be the database of choice.

Although existing for many years these products have had a chequered history when it comes to their security. It wasn't that long ago when the default Microsoft SQL Server administration password was simply blank, something that reveals a lot about cavalier attitudes towards data security in the 1990's. Of course this has changed. Microsoft launched the Trustworthy Computer Initiative in 2002 and retrained its developers to ensure that secure coding became the norm. In an effort to beef up its product security, Oracle introduced the Software Security Assurance Process (SSAP). The objective of this process was to ensure that products developed by Oracle engineers were secured from the start, rather than having to re-secure production code and deploy large numbers of patches to their customers.

To sell some new software for the DBA to install on their database server is a very difficult process, and, probably in many circumstances, nearly impossible as the servers are so locked down nothing other than the database and operating system is allowed on the computer.

When it comes to IT security a lot of vendors have been successfully following the appliance modelthat is supplying a hardware box of tricks that carries out a single task which can be plugged into a network without having to install server-based software. This non-invasive approach has great appeal to network administrators who often like to touch and feel kit, safe in the knowledge they can remove it if they wish. This tangible aspect is something that software can't deliver.

The nature of IT security is also changing as we move away from solely securing the perimeter to ensuring we have defence in depth. IT security practitioners and DBAs are realising that the threat to their data, be it loss or damage, is increasingly coming from within. Disgruntled employees can quickly download a database result set to their memory stick and be out the door before anyone realises there has been a problem. 

Database Activity Monitoring vs. Database auditing
We have seen how database vendors have improved their product security over the past few years. This also includes the inclusion of tools to monitor database activities. If we take Microsoft SQL Server 2008 as an example, there are a couple of native database auditing tools that could be useful, but fall short of a comprehensive database activity monitoring tool.

SQL Server connection auditing is a subsystem that monitors failed or successful login attempts to the database server. The audit trail provides a guide as to who is attempting to connect to a server, when the attempt took place and if they managed to secure a connection. This level of auditing has relatively little impact on database performance as it is one of the native characteristics of the database product. 

In addition, SQL Server provides an auditing tool that meets the need of the C2 Security Evaluation Criteria. It is not enabled by default but when working will track each and every auditable event and write them to a file on the server. Therein lies the drawback with this auditing mode. It is possible to create huge volumes of audit data that is simply overwhelming. If the audit file should grow to the stage that it is bigger than the disk space allowed for it then SQL Server will stop working, as it is prohibited from processing any data that is not supported in an audit trail. In addition, the presence of an audit file will soon be detected by an attacker and will quickly be edited to remove traces of any attack, unless the attacker is very poorly skilled.

SQL Server Trace is another auditing tool but has other uses as a way of tracing and debugging slow queries. Although it is possible to configure SQL Server Trace to work quite efficiently, out of the box it does consume considerable resources and as such is not a viable tool if you need to audit the database from a security perspective.

Database Activity Monitoring Brings it Together
Database activity monitoring is designed to provide specific tools and techniques above those found in database products off the shelf and brings together the world of database and conventional information security.

Database activity monitoring products are normally appliances that sit between client applications and the relational database they use. The appliance analyses all Structured Query Language (or SQL) statements that are sent by the clients to the database and will flag potentially dangerous activity.

This is the pivotal difference between database activity monitoring and log management. With database activity monitoring it is the actual SQL commands that are monitored. With log management tools it is the database and system logs that are monitored for suspicious activity.

So how are the thousands of SQL statements that could be submitted to a database analysed? Well, this is where the appliance's "smarts" come into play.

Using specially designed algorithms the database activity monitor analyses SQL statements until it comes across SQL that is out of the ordinary. It will then flag the potential problem to the DBA for them to take action.

So what do we mean by SQL that is out of the ordinary? Well, it could be anything out of the ordinary for that particular SQL query, user, table being accessed, time of day or any one of many measurements being tracked day in and day out.  

For example in business, a finance user may normally select data covering a three month period for analysis each week. If, suddenly, they request 5 years worth of data this might be an innocent request to do some more historical analysis or it could be an attempt to steal 5 years worth of data from the business. 

In the next article in this series we will explore how database activity monitoring works for real.

Post a comment?

We welcome constructive criticism on all of our published content. Your name will be published against this comment after it has been moderated. We reserve the right to contact you by email if needed.

If you don't want to see the security question, please register and login.