Database Activity Monitoring Part 3 – Other Common Attacks

This article will explore how database activity monitoring deals
with other types of data attacks.

Temporary Accounts
Temporary accounts have a perfectly legitimate part to play in
any database system as they can provide flexibility for the DBA
wanting to create short term access for contract workers or for
managing some database activities. Unfortunately they are also a
vector for hackers, especially if the administration account can
be compromised and the temporary account assigned roles and
privileges that could result in data being stolen.

By setting up a temporary account a hacker can start to create a
better level of anonymity and bury their true identity at the end
of a long chain of other accounts designed to throw investigators
off their path. A database activity monitoring solution will
raise an alert if an unusual temporary account or set of accounts
has been create that do not fit into the normal pattern of
behaviour for an application.

Sensitive Data
Not all data in a database is sensitive. For example you may have
a table that contains a list of the products you sell on your
website, all of which is public. On the other hand you may have a
table that contains customer discount rates, which is highly
confidential and could seriously compromise your business
relationships if it was made public. Then of course we have
payroll and salary data, often deemed to be the most sensitive
information and organisation keeps.

During the setup phase for the database monitoring system the DBA
would normally work alongside the security team and the business
to categorise the data being held and determine what data is the
most sensitive. It will then need to be decided what database
actions are permitted on this data. For example it may be
perfectly acceptable for a payroll clerk to SELECT data from the
salary table for the monthly cheque run but it is completely
unacceptable for them to be able to UPDATE the same data and give
themselves a pay rise. Once finalised, the database activity
monitoring tool will see what activities are being attempted
against the various sensitive data sets and raise warnings if
necessary.

Out of Course Data Access
Out of course data access is when a user attempts to access data
by bypassing their usual client application. For example if an
organisation has created a client server application that uses a
front end Visual Basic screen to retrieve data they may decide to
try and connect to the backend database using Microsoft Access or
Excel. If the user was able to connect using a tool such as MS
Access, the simplicity of the tool will enable most users to
download huge amounts of data by pointing and clicking. The
database activity monitoring tool can be configured to audit
connections from clients other than the approved Visual Basic
tool and raise an alert for any out of course connection
attempts.

Unusual Activity
This is often a catchall for activities that fall outside the
norm for a particular database. Typical unusual activities
include users accessing more data than normalfor example
selecting all the data from the customer table rather than just
those for their sales region. It could be someone accessing the
data out of hours, maybe at the weekend and maybe from home. What
is unusual for one database may be usual for another, so this
will need a higher degree of customisation and learning for the
activity monitoring solution to prevent legitimate users getting
annoyed, but it can be a powerful data protection tool.

More obscure activities should also be tracked; for example users
trying to start or stop services, trying to run extended stored
procedures or meddling with database backups. Any of these could
be legitimate but at least you will be alerted and will have the
ability to investigate what is happening.

Connection Pooling
Connection pooling has been implemented by a number of vendors of
enterprise software as a way of optimising the performance of a
database. For example a system may only have one shared
connection under a single database account that is used for
updating customer data by all users. Of course the users don’t
know they are using this single accountthis is a process that
happens underneath the covers of the application. From an
information security perspective this presents us with a problem
as it is more complicated to work out who the actual user was for
a specific transaction if the connection was pooled. Some
database activity monitoring products are able to see if
connection pooling has been implemented and then track
transactions back to the client application and discover who the
actual user was for each discrete transaction, a feature which is
very useful with such pooled connection implementations.

The next article will cover compliance issues and the way in
which a database activity monitoring solution can be
architectured for best effect.