Typically, businesses choose to implement Database Activity Monitoring controls that are independent of the database(s) itself. The key reasons for this are:
- Separation of Duty – configuration and control of the auditing system can be managed by a different set of people than those who manage the databases. Also enables regulators and audit firms to see that you have independent monitoring controls, away from the operational side of the business, to alert and report on potentially fraudulent or malicious taking place on the databases within your organisation.
- Privileged User Monitoring – ensuring that people with system-level privileges to your databases cannot bypass the monitoring controls to those databases
- Minimal changes – to operational databases and applications.
- Minimal performance overhead – critical requirement to not degrade performance of operational systems.
- Cross-platform – independent solutions audit most of the common enterprise Database Management Systems.
There are two main levels of database auditing:
- SQL statement monitoring. This technique observes the SQL instructions that are being sent to the database. This tells you what the SQL instruction was, but it may be difficult to ascertain exactly what actually happened as a result of that instruction.
- Data change monitoring. This observes the actual changes made to any data that has been created, modified or deleted.
There are several techniques by which the monitoring can be done; below is a summary of the main techniques, showing what levels of auditing they are appropriate for.
|Technique||SQL Statement||Data Change|
|Command buffer sniffing||Yes||No|
Of course, each of these techniques have their pros and cons – and the best solution for any business depends on the particular needs and environment. We can advise on the most appropriate solution for your requirements.
We have produced a White Paper on Database Auditing Best Practices which you can download in this paper: Database Audit Best Practice.