LOGbinder Blog

Remember when we said that we loved feedback and wanted to hear from you about the pain points? Here's an example of what we try to do when you send us that feedback. We got a call from a LOGbinder SQL customer with a production environment problem that didn't show up during his evaluation in a test environment. While diagnosing the problem (it turned out to be a GPO issue at the customer's location) we saw that the input window was too narrow to display all of the long file name, which was a major pain. Our development team made the correction to the source code and we got the new bits to the customer that same day! The customer was happy, and the developers got the satisfaction of delivering a solution that made a real difference.

So please keep that feedback coming. We sweat even the small stuff if it helps you get application security intelligence where you need it – your SIEM.

People who speak our language

LOGbinder has some great value-added resellers who speak our language. They totally get that your SIEM needs to have application security intelligence. And many of them are translating LOGbinder sales material into languages other than English.

If you or a colleague prefer German for example, click Innovative SIEM-Integration von Microsoft-Daten to get what our VAR in Germany, iT-CUBE has put together. It's great!

IT Guard also has translated our sales materials in to Russian to get the word out in that country. They have done a great job with their web site.

If you like your English with an Australian accent, you can't do better than talk applications security intelligence with the SIEM experts at Shelde. In fact, you North American and European readers, when you can't sleep for thinking about a SIEM issue, chances are the Shelde guys down under are just starting their day and would love to help.

Our sales team is working to form partnerships with smart security consultants and resellers all over the globe. Do you have a firm you like to work with that we should know? Tell us.

Tech Tip: Why i:0#.w| in front of user names in LOGbinder SP?

The other day someone asked why LOGbinder SP puts the characters ” i:0#.w| ” in front of the usernames. For example, instead of LB\capt.kirk ” as the username, it would show i:0#.w|LB\capt.kirk ”.

LOGbinder does not do this; it actually comes from SharePoint. This is how SharePoint 2010 and SharePoint 2013 encodes identity claims. It's SharePoint's way of representing the authentication method used in SharePoint. Here is an article on what it means: http://social.technet.microsoft.com/wiki/contents/articles/13921.sharepoint-2013-claims-encoding-also-valuable-for-sharepoint-2010.aspx

New SIEM integrations are publicly available

Many SIEM product developers have recently told us about new integrations for LOGbinder solutions. We're going to be telling everybody about these developments as soon as the documentation is complete. In the meantime, here are the highlights about what's new:

Logpoint has fully integrated all 3 of the LOGbinder products.
LogRhythm has completed their 2^nd LOGbinder integration, the one for LOGbinder EX and they are working on the LOGbinder SQL integration.
McAfee ESM is now fully supporting all three LOGbinder products.
IBM's QRadar product team approved our LEEF implementation. (see note below) QRadar now has integration for LOGbinder SP and LOGbinder EX and are working on an integration for LOGbinder SQL.
Solarwinds has also completed their 2^nd LOGbinder integration for LOGbinder EX and plan to work on LOGbinder SQL integration.
Our Splunk app for LOGbinder is in beta testing. Let us know if you want to kick the tires.

Note: All 3 LOGbinder products now in beta have LEEF output options. We expect to release these new versions publicly within the next 2 weeks.

Of course, LOGbinder works with any SIEM, and we have Recommended Rules and Alerts for all our products to help users when no custom integration exists for their SIEM. (Click here to get them.)

Options for SQL Server auditing

We know this is a huge topic. We sponsored an Ultimate Windows Security webinar about SQL Server auditing on October 16 that had one of the biggest registration and attendance counts of the year. Apparently more and more, people focus on getting SQL Server audit done right. If you missed the webinar, you can still get the information. If you or someone you know needs to get up to speed on SQL Server audit click here to get the recorded version. The recording captures all of the good questions and answers.

Don't forget to check out our blog post comparing SQL Trace to SQL Audit. It's great info.

Did we say that the Splunk app is ready for beta testing?

The new Splunk app for LOGbinder is available if you want to try it out. We'd love to hear some feedback from more beta testers.

Security analysts must have meaningful, relevant audit data from the mission critical applications such as SQL Server. Database admins must have no disruptions nor degradation to the performance of the mission critical instances of SQL Server. Beginning with SQL Server 2008,versions of Microsoft SQL Server offer a new, superior SQL audit capability custom-built to meet demands from both parties.

Many, if not most, organizations have gotten comfortable with SQL Trace. They have satisfied themselves with its inefficiencies, and cobbled together custom routines to reduce its voluminous output. Outweighed by whatever problems that may exist with SQL Trace is one simple fact: it doesn’t hurt the database(s) to keep it going. Nobody wants to run the risk of disrupting the current process. It may not be great, but it’s what is comfortable.

Here’s the problem: SQL Trace leaves big gaps that compromise organizations’ InfoSec and compliance policies.

So, many organizations are taking a hard look at the risks vs. rewards of moving away from SQL Trace and implementing SQL Server Audit as part of the application security intelligence SIEM deployment. To help inform the professionals charged with this decision, our founder Randy Franklin Smith, and Tamas Lengyel, one of our software engineers, have collaborated in writing a white paper, Comparison: SQL Server Audit and SQL Trace Audit. This detailed resource will help both security analysts and database admins to get a better understanding of the superior SQL Server Audit function. The white paper presents the options available to both audit logs and then provides specific benefits that come with SQL Server Audit:

Easy administration and predefined activities
Granularity, Specificity
Performance improvements
Better (and more) output options, centralized storage of audit logs
Audit trail integrity

The short story is that SQL Server Audit hits the sweet spot for both database admins and security analysts: it’s a low impact process that yields better results.

Get the full story, download the whitepaper. It may also be helpful to read why LOGbinder solves a critical problem in SQL Server security intelligence at logbinder.com.

***This article was has been updated with the release of SQL Server 2017. The updated article is located here.

SQL Server 2012 made SQL Server Audit partially available to all editions. Until SQL Server 2012, this true, native auditing feature (introduced in SQL Server 2008) was only available in Enterprise and Datacenter editions. Starting with SQL Server 2012,the server-level auditing portion of SQL Server Audit was made available to all editions, leaving only the more granular database-level auditing still exclusive to the Enterprise edition.

SQL Server Audit is based on actions and action groups. The audit can contain server-level audit specification and database-level audit specifications:

Server-level auditing consists of server-level audit action groups, which include server operations, such as security operations involving logins, roles and permissions, logon and logoff operations, database backup and restore,manipulation of certain database-, server-, and schema objects.
Database-level auditing is auditing at the database scope, and it is set on each database individually. This feature is not available in all editions of SQL Server, only in Enterprise editions. Database-level auditing utilizes database-level audit action groups, and database-level audit actions.

The database-level audit action groups cover some similar areas as the server-level audit groups, if applicable, but at the database level.
Additionally to auditing action groups,database-level auditing also enables auditing certain individual actions, such as SELECT, INSERT, UPDATE, DELETE, EXECUTE, RECEIVE, and REFERENCES. These database-level audit actions can be restricted to a specific database, an object (such as table, view, stored procedure), or a schema.

Here is a summary of the SQL Server Audit support in the different editions:

*Edition*	SQL Server 2008 and 2008 R2	SQL Server 2012 and 2014
Enterprise	Server- and database-level	Server- and database-level
Evaluation	Server- and database-level	Server- and database-level
Developer	Server- and database-level	Server- and database-level
Datacenter	Server- and database-level	N/A
Business Intelligence	None	Server-level
Standard	None	Server-level
Web	None	Server-level
Express	None	Server-level

So where does LOGbinder SQL fit into the SQL audit equation? LOGbinder SQL can be installed on any Windows server running SQL Server 2008 or later regardless of the edition, including Express. It does not need to be installed on Enterprise edition. The requirement is that the SQL Server that is being audited is:

Set to produce audit events.
Set to output these audit events to a location accessible to LOGbinder SQL.

The audit file can then be accessed and processed by LOGbinder SQL and made available for your SIEM / log management solution.

To summarize, audit logs could move the following way:

***This blog post is still important but outdated. Please see this post for updated least privilege changes.***

Issue

In the blog on www.logbinder.com (Workaround if LOGbinder SP is having SQL database issues), a suggested workaround for insufficient privileges to SharePoint’s SQL databases is to add the LOGbinder service account as a database administrator (DBO). The question arises: How does LOGbinder SP use these elevated privileges?

Access to SharePoint databases

First, it must be understood that LOGbinder SP does not access SharePoint’s SQL databases directly. All access to SharePoint data is through the SharePoint Server Object Model (see http://msdn.microsoft.com/en-us/library/jj164060.aspx). LOGbinder SP does not execute any Transact-SQL commands directly, nor does LOGbinder SP access the SQL database directly to adjust database structure, privileges, and so forth.

The workaround suggested in the above blog is recommended based on troubleshooting in our labs, to address what apparently is a defect in the SharePoint Server Object Model. LOGbinder SP does not then use these elevated privileges to perform other activity.

LOGbinder SP’s use of SharePoint data

Even though LOGbinder SP accesses SharePoint through its object model, a secondary question may be: What activity does LOGbinder SP perform in SharePoint? LOGbinder SP’s main activity is to read SharePoint audit logs, as well as to read metadata about SharePoint site collection, lists, libraries, users, groups, and similar entities.

Through the SharePoint Server Object Model, LOGbinder SP does make some changes to SharePoint (the customer specifies these changes in the LOGbinder Control Panel). The changes LOGbinder SP will make to SharePoint include: adding/removing site collection administrators, adjusting audit policy settings for a site collection, adjusting the audit log trimming setting for a site collection, and deleting audit log records. (The documentation for LOGbinder SP contains details on these actions.) So, other than purging old log data and setting audit policy according to configuration settings by the administrator, there is nothing that LOGbinder does that modifies or could corrupt SharePoint content or the SQL database.

Check out Randy's latest blog: Audit Myth Busters: SharePoint, SQL Server, Exchange

LOGbinder Blog

October 2014 LOGbinder Newsletter: Feedback Makes Customer Happy; New SIEM integrations

Comparison: SQL Server Audit vs. SQL Trace Audit for security analysts

SQL Server Audit Support in Different Editions and Versions

LOGbinder SP use of SQL Privileges

Issue

Access to SharePoint databases

LOGbinder SP’s use of SharePoint data

Audit Myth Busters: SharePoint, SQL Server, Exchange