This article will explore how database activity monitoring deals with other types of data attacks.
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.
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.
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 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.