This article explores the role of database activity monitoring in an overall compliance solution.
Database Activity Monitoring and Compliance
Organisations deploy DAM solutions for a number of reasons, ranging from compliance through to beefing up their overall security posture.
Increasingly, compliance laws, rules and regulations are forcing organisations to have tighter control over their data and, more importantly, have a provable audit trail that can be signed off, if necessary, by appropriate organisational officers or executives.
Sarbanes-Oxley, which has implications for organisations based in the United States or with a trading presence there, has a requirement that financial information is accurate, and a company executive will be expected to sign a statement to that effect. Although not specifically mandated, it makes sense to record database activity, especially if that data relates to financial information. Database activity monitoring will often be a useful addition to any compliance suite as it can provide a level of assurance that data usage is being monitored. For example, it could help enforce a separation of duties, preventing a DBA from viewing data they should not have access to during a database backup.
PCI-DSS, the payment card industry standards for data security, place a set of requirements on credit card merchants to protect customer credit card details. PCI-DSS is reasonably proscriptive in its requirements, and merchants that fail to comply with the regulations face fines and possible exclusion from credit card networks. Database activity monitoring would be a useful adjunct to a merchant's information security setup, as out of course access to credit card data can be detected and prevented. For example, if a user normally accesses 10 credit card numbers at a time then the database activity monitoring system could raise an alert if they should access more than this number of card details in a database query.
Database Activity MonitoringTechnical Architecture
Database Activity Monitoring vendors each have their own preferred way of tracking database activity and will therefore implement slightly different architectures.
A single appliance/single server architecture will provide a one-to-one mapping of a database server with a monitoring appliance, which, in turn, acts as both a sensor and collector of relevant data. This configuration would be suited to a small departmental database but may not be effective enough for larger database systems.
A two tier architecture will consist of a centralised management server that aggregates information from a set of remote sensors or collection points. This provides a better degree of system scalability.
A hierarchical architecture builds onto the two tier architecture and supports a larger number of sensors and collectors distributed across a large organisation or enterprise.
Advanced Database Activity Monitoring Techniques
Network monitoring is the process of monitoring all SQL traffic to a database. The advantage is that it can monitor multiple databases at any one time and keep track of all commands being sent across the network to its databases under scrutiny. It will not be able to detect database activity carried out by a user logged directly onto a database server via a local console but it is able to monitor encrypted connections if placed between the VPN and the database, at which point the SQL commands would be in plain text. Network monitoring places no overhead on the database so performance will not be adversely affected.
Remote monitoring places a SQL collector on the database with administrative privileges and native database auditing is enabled. The collector will then aggregate all activity collected by the native database auditing tools or indeed any other database feature that may provide relevant or useful user activity based data. This type of monitoring will impose an overhead on the database as logging has been fully enabled on the database server, causing it to do more work. The benefits of this approach are that all database activity is collected, included that of any user logged directly into the server via a local console.
Local agents can be installed on each database being monitored. These may or may not be successful in detecting all database activity dependent on how they have been configured and how close to the heart of the database they are allowed to sit. As the use of agents requires software to be loaded directly on a database server, and have an associated performance impact, they are not always widely regarded by normally very conservative database administrators. The upside is that a well coded and developed agent could detect all database activity with no need to turn on the local native auditing tools and may only adversely affect database performance by 27%. Of course the business will need to decide if any performance hit is acceptable against the data security risk.
In reality, each organisation will need to determine which database activity monitoring solution architecture fits their purposes and whether a compromise will need to be achieved between security and performance. Indeed, many organisations will probably implement a mix of architectures across their databases being monitored.
More advanced database activity monitoring solutions are increasingly moving into the realms of application monitoring as well as database monitoring. This requires a deeper understanding of application architectures and is only generally available for common enterprise solutions such as widely used HR, process management and enterprise resource planning systems. With appropriate hooks into client applications the monitoring software is even better positioned to see each and every action against a database.
The next article will cover database activity monitoring for the business decision maker
