Database Activity Monitoring Part 1 – An Introduction

Written By: Nigel Stanley
Published:
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.