Why Pick a DAM over Native Database Auditing, SIM or LM?
Every DBMS vendor out there, Oracle, Microsoft, Sybase, IBM, MySQL offers some database activity monitoring (DAM) features, at least in a more recent release, then why pick a DAM?
If the native database auditing solution meets your needs then by all means use what you already have, so, let's discuss "your need" and review key differences in functionality offered by DAM solution vendors like NitroSecurity vs. DBMS vendors.
Performance Impact
For starters be aware that native database auditing solutions do affect database performance because all audit records are logged in a table or a file on your database server. In some cases it brings the application response times to unacceptable levels. In other cases it is unnoticeable to the end user. Why the disparity? Simply put, it comes down to who, what and how much you are auditing and the excess horse power on your database server which makes it more or less noticeable. There are no published numbers from DBMS vendors even for standard hardware platforms because the answer frankly is not quite favorable. We are talking extra IO for every query if you need to log all access to your important databases. Extrapolate that to hundreds or thousand of queries per second for a busy server. You get the picture.
In contrast most DAM vendors provide a network based monitoring option which has zero performance impact on databases and applications. This makes the task of deploying DAMs relatively easy because they don't need to go through levels of performance benchmarking before being deployed in a production environment.
Native Auditing Pitfalls
If performance impact is not an issue, you only have a few databases, they are all of the same type and version, or all you want to do is demonstrate basic controls to your auditor, you may possibly get by with native DBMS features.
However, there are several concerns to keep in mind if you decide to use native database auditing & tools:
- Secure central logging, reporting, and notification is the most basic yet toughest requirement to meet with native tools since none of the DBMS vendors provide these features. Oracle offer a solution called Oracle Audit Vault but this feature costs extra - a lot extra! This means you'll have to develop or use open source code to meet this requirement. Unless you can dedicate a team to develop and maintain the tool this alone is reason enough to purchase a DAM. DAM solutions have pre-built reports to meet compliance requirements and mature solutions like NitroView DBM provide fast query times even in interactive mode while event collection is in progress and billions of events are in the repository.
- Segregation of duties is an important requirement for auditors. This means that DBA's shouldn't be in charge of database security. It is easy to understand that you don't want the rooster to have the keys to the hen house. Segregation of duties is enforced by auditors because it is a basic security practice required by every regulation. This is another requirement that is pretty hard to work around in the workplace when using native database auditing because the audit events generated by the DBMS are saved in a database table or on the database server host, which is the domain of the DBAs. In contrast most DAM solutions are appliances that can be managed easily by the security team requiring no interaction from the DBAs.
- Lockdown DBA access and monitor activity on the database server host. This is a good security practice. Locking down means ensuring that the DBAs have the least OS level privileges, and, all access to the database host machine is logged using sudo or a similar tool. You should be able to very least pin down who was on the database server host machine during a certain period. This is necessary because the database can be most easily compromised by someone that has access to the host machine. This also means you must log, report and notify on OS events (syslog or eventlog) and not just SQL activity. Unlike DAMs native database auditing does not include OS-layer monitoring.
- Limit the native auditing to minimize performance impact. This means restricting the auditing to DBA role & privileged users and only DBA type of commands such as schema or database config changes. For this scheme to work you must ensure your applications do not use privileged accounts or you will defeated the purpose of minimizing performance impact from native logging. Limited auditing is acceptable so long as your requirement is not to use the logs for security or forensics, because, capturing every SQL statement is essential if you want to detect a SQL injection attack or drill-down to session level details for future investigation.
DAM Capabilities Unavailable to Native Database Auditing
Besides meeting performance objectives, segregation of duties, providing scalable & useful reporting, drill-down and notification across heterogeneous database platforms there are a host of other advanced security features that are provided by DAM solutions that are not available in native database auditing.
- No content monitoring is provided by native tools which means "tough luck" discovering abuse of sensitive data or addressing use cases such as "who are the top consumers of sensitive data". DAMs monitor both the request and response of queries so you can use them to discover sensitive data in use.
- Native tools cannot discover & prevent database attacks. This means you can't detect or block buffer-overflow, denial of service (DoS), SQL Injection attacks or any other kind of exploit against the database - a major limitation of native tools.
- Information contained in native database logs is inferior and varies dramatically by database type and version. If your DBMS is Oracle you can get native logs that are richer in information albeit at a performance price. In contrast the native logs produced by Sybase, DB2, MySQL have much less information. Also none of the native events do any translation of the message codes, as in message code == 10011 means "Access Denied" in MSSQL server. NitroView DBM on the other hand capture's a very rich set of metrics that are translated so a non-DBA SOC or NOC operator can easily interpret the event. List of metrics collected by NitroView DBM include, "Begin & End Time of Query, Query Text, Command, Table names, Query Success/Failure Status, Login Name, OS User, Application Name, Client/Server Name, IP Address & Port Numbers, Returns Rows, DBMS Error Message & Severity, Query Type, Packet Count & Bytes for Request & Response, Database Name, Client & System Process ID's. It also generates a Session ID and Query number to uniquely identify a session and query. Performance metrics such as Response Time, Server Response Time & Network Response Time are also provided."
- You can't mask sensitive information with native solutions such as SSN, credit card, account numbers and passwords of employees and customers which are often in the SQL.
- You can't track application users when generic database logins or connection pools are used. DAM vendors provide features to track, correlate or narrow down to application users by providing added application-layer intelligence.
- No analysis of collected data. It would be naive to expect analysis when there is no reporting. It is by no means a simple task to show event distributions against a baseline or deviations from normal behavior without a properly architected solution.
- You can't correlate series of events. For example, you want a notification when there are several failed queries from a specific client or user. Needless to say you will have to write your own correlation engine if you use a native tools.
- Native events are not normalized to a taxonomy so you cannot report on events across data sources. For example, logins or access denied errors across database servers and OS events. This feature is important for security analysis when you need to find out what else a user or attack may have compromised.
Trying to create a useable solution around native auditing and maintaining it you will eventually break the bank. To provide an aggressive return on investment (ROI) and reduce the total cost of ownership (TCO) some DAM vendors like NitroSecurity have taken the extra effort to make their solutions completely self managing. They require little or no maintenance once deployed. They provide auto update of signatures, correlation rules, reports, software updates to support new versions of databases. So, purchasing a DAM with support really starts to makes a lot of sense.
Why use DAM when you already have a SIM or Log Management solution?
When most SIM and LM vendors market their solutions as being able to collect database events they simply mean that they can accept a syslog feed from a DAM solution OR you must turn on native auditing in your databases and the SIM/LM vendor will provide the hooks/agents to collect, report, notify on the database events.
The analogy here is going to an Internist for treating a heart problem rather than a cardiologist. DAM vendors are specialists when it comes to databases whereas SIM vendors are generalists. If you are looking to secure your database then a SIM will eventually have to refer you to a DAM.With a leading SIM (and less true with LM) you may overcome the drawback of a native auditing not providing reporting, analysis, notification or event correlation but you cannot overcome other shortfalls of native auditing discussed earlier. If these pitfalls don't matter in your situation then you can use a SIM/LM with native DBMS auditing but keep these tips in mind:
- Check what database servers, versions and platforms the SIM can collect native database events from - most leading SIMs still support collection only from Oracle because collecting native events from other DBMS's is more tricky.
- SIMs use a polling architecture to read the native events from each database server to a central location. This does not scale very well beyond a few servers and adds a significant load on the network if the database servers have a high transaction rate. Network-based DAM solutions were designed to overcome this shortfall and can take in multiple VLAN feeds so you can monitor 100's of database servers directly from the switches. If you exceed the capacity of the DAM appliance you can simply add another one.
- SIMs don't really create or manage the database audit records and therefore leave the management of the events to the DBA's. This creates a security hole. Also the polling architecture requires a login to each database server creating additional dependency on the DBA team to help commission, setup, upgrade and manage agents (if there are any). This has a direct impact on the TCO and manageability of the solution. Most DAMs perform all the necessary management of the database audit logs including purging of events.
Now, it does make a lot of sense to use a DAM with a SIM so you have the holistic picture of database events in tandem with other security events such as the OS, application logs, IDS's and firewalls. You can benefit from other features a SIM provides such as advanced visualization & analysis, correlation, case management, incidence response, workflow and increase your operational efficiency with a single console.
However, just beware of loose UDP/Syslog based SIM-DAM integration as this can cost you dearly and wipe out the benefits you get from a DAM. Most importantly the syslog packet size is 1024 bytes so your DAM events & SQL queries will get truncated. Moreover a DAM streaming syslog events to a SIM does not render itself well with busy database servers which can create several thousand events/sec. This will overwhelm a SIM trying to parse a syslog text stream. The end result will be that you will turn down the auditing and loose the security and forensics benefits you were seeking from your DAM.
Recommendations
Look for tight integration between a SIM and DAM so the SIM captures the full detail of the DAM events and scales to the high database transaction rates.
These icons link to social bookmarking sites to help share this content.
Log in
