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.
