LOGbinder SQL - Frequently Asked Questions

Visit our SQL Audit Background page for lots of help.

SQL Server can definitely output its raw audit events to the Windows event log in fact here's how to configure that and we encourage you to try it out. We think you will agree that LOGbinder SQL is needed for 2 reasons:

1. Perfomance: Writing events to the SQL servers local security log can consume added CPU, memory and disk resources which may be unavailable on heavily loaded database servers.
2. Raw, Cryptic Audit Data: The audit records generated by SQL Server audit are cryptic and difficult to understand. SQL Server uses log record format for documenting everything from an insertion on a table to a modification of a stored procedure. And while SQL Server can write events to the security log, it uses the same event ID for all events, and the IDs and keywords are not resolved. Thus, it requires in-depth knowledge of the SQL audit model in order to decipher events. LOGbinder SQL enriches SQL Server’s cryptic and generic audit messages to produce almost 300 different and easy-to-understand audit log events in Windows event log, where any log management or SIEM solution can collect, alert, report, and analyze.

Click here for a list of event IDs generated by LOGbinder SQL.

You can run LOGbinder SQL on the same server where SQL Server auditing is enabled and LOGbinder SQL's modest resource usage will not be felt in most environments but you can ensure LOGbinder SQL has absolutely no impact on heavily loaded SQL Servers by installing LOGbinder SQL on a different server. This latter does not incur the expense of another SQL Server license because LOGbinder SQL can use any edition of SQL Server 2008 (and later) - even the free Express Edition - to read audit logs generated by other SQL Servers via shared folders.

Thankfully SQL Server has a very granulary audit policy that allows you to audit just the desired actions on just the desired objects. So it is unlikely auditing will have a material impact on your database server performance unless you try to audit frequently executed operations like (select, update, insert, delete) on heavily accessed tables. Even with that said, most SQL Servers can output a great deal of audit events without feeling it. This is especially true if you configure the Audit to target a file instead of the local event log; appending to a file is much faster than calling Windows event APIs. And the good news is LOGbinder SQL is designed to process SQL audit log files and can do so from a different system than your busy database server. So, to ensure audit trail generation without performance degradation, enable auditing of table and view operations only as needed and target the Audit to create files in a shared folder on a different server where LOGbinder SQL is installed.

LOGbinder is fully integrated with Windows and SQL Server security and complies with widely accepted secure design and coding techniques.

At installation, LOGbinder secures the folder permissions where the software files reside.  To protect LOGbinder's configuration from tampering, LOGbinder encrypts its configuration data.

LOGbinder security requirements are greatly simplified since LOGbinder does not store your audit log data.  LOGbinder is designed to quickly get audit events out of the SQL Server audit log files and to the destination of your choice, at which point your log management solution takes over.  If you configure LOGbinder SQL to direct events to the Windows security log, you leverage the significant effort Microsoft has invested in protecting the security log.  And if you are already collecting Windows security logs with your log management application, SQL audit events will automatically be included when you install LOGbinder SQL.

LOGbinder SQL's design helps you fulfill separation of duty and audit trail integrity requirements by quickly getting audit events off the system where they are produced (and thus vulnerable to intruders or malicious administrators) and into your separate and secure log management system.   

LOGbinder SQL installs in about 2 minutes and only requires a few settings:

1. Select which folders for LOGbinder to monitor for SQL audit log files
2. Specify the user account LOGbinder should run as
3. Choose whether to output events to custom LOGbinder SQL event log, to the actual Windows Security Log, syslog or to a text file.

 Check the Application log for warnings or errors from source LOGbndSQ

These are functions of a log management solution.  LOGbinder complements and enhances the value of your log management solution. If you do not already have a log management solution, we can provide a simple, inexpensive but dependable solution from our partner and we will help you install and configure it.

With LOGbinder, any log management solution that supports Windows event logs, text files or syslog can now collect, monitor, archive, and report on SQL Server audit log activity.  Also, see next Q&A.

LOGbinder can output to either the Windows Security Log, syslog, text file, or a custom Windows event log called LOGbinder SQL. 

Based on customer feedback we may add additional output formats such as syslog, text files, or XML.

Click here for pricing and licensing information.

No. See above questions on performance.

The account needs to be authorized to run as a service, and if using the security log, must be authorized to write to the security log.

Yes, LOGbinder SQL can monitor multiple shared folders for SQL audit logs produced by different SQL servers.