We are pleased to announce the release of LOGbinder SP 3.0. The fundamentals of LOGbinder remain the same. It continues to support SharePoint 2007 and SharePoint 2010, Foundation (WSS), Standard, and Enterprise editions. While nothing was removed from LOGbinder, we have added a number of features that will make your use of LOGbinder even more effective.
For customers with active LOGbinder SP support contracts, please watch for an important email that will give you important upgrade information.
· Farm-Wide Default Audit Policy – Have you every wished you could just configure audit policy once for the whole farm? Now you can! You can now define a default audit policy and apply it to all existing site collections. Better yet…
· New site collections automatically audited – You no longer need to remember to enable auditing on new site collections. The new default audit policy is automatically applied to new site collections. This will be a real boon to farms with self-service site collection enabled.
· Audit Trail Integrity - Automatic detection and response to tampering
LOGbinder SP allows you to specify a “Default Audit Policy.” This allows you to define a policy once, and apply it to the site collections you specify—thus allowing for more consistency in audit settings.
The default audit policy can also be applied to new site collections. Thus, soon after a site collection is created, LOGbinder SP can automatically enable auditing and begin processing its audit logs.
There are now three ways to specify the audit settings for a site collection:
· “Custom audit policy”: Corresponds to Version 2.x, where you use LOGbinder to set the site collection’s audit policy.
· “Allow Site Collection Administrator to configure audit policy using SharePoint’s administration page”: This allows you to set the audit policy in SharePoint (if running the Microsoft SharePoint Server edition).
· “Use LOGbinder’s default audit policy”: Once the default audit policy has been defined, it can be applied to the site collection. If the default audit policy later changes, LOGbinder will automatically apply the changes to the site collection’s audit settings.
There is no change to functionality, but the text of the properties window has been updated to make the options more clear.
Available from Options and from the Configure Inputs windows, the “SharePoint Farm Properties” window displays basic information about the SharePoint farm—the number and names of servers, farm ID, and edition information. Some of this information is needed when purchasing a LOGbinder license.
While LOGbinder is processing events, it will perform actions that generate SharePoint events. These same actions, if performed maliciously by a SharePoint user, could compromise the integrity of the audit trail. In order to distinguish between authorized and unauthorized changes, when LOGbinder processes these events, it will indicate it performed the action—or whether the action might be unauthorized. A tamper warning may be generated by these events:
· Audit policy change: When processing event #11 “Site collection audit policy changed” or #12 “Audit policy changed,” LOGbinder will determine if the change overrides the setting in LOGbinder. If so, LOGbinder will reset the audit policy and generate a tamper warning.
· Audit logs deleted: When processing event #20 “Audit logs deleted,” LOGbinder will determine whether LOGbinder deleted the logs. An additional line is added to this event “Purge performed by LOGbinder”—the value will be “Yes” if LOGbinder performed the purge. If not, a tamper warning will be generated.
An additional event, #60 “Possible tampering warning” has been added to the LOGbinder SP event list.
The diagnostic events generated by LOGbinder can be accessed from within LOGbinder. These events are still written to the Application event log, but by selecting the view “LOGbinder Events”—or one of the subviews—you can view the diagnostic events right from within LOGbinder.
The new “Reports” contain our recommended SIEM reports, where you can inspect LOGbinder’s results right from within LOGbinder. However, LOGbinder is still best used in conjunction with your SIEM solution—and LOGbinder now provides basic information on integrating your SIEM solution. In the meantime, however, you can use the basic reports within LOGbinder to view the filtered LOGbinder events.
The user account you use to install and configure LOGbinder is required to be a member of the local administrators group. This was recommended in Version 2.x, but now is required.
Licensing
LOGbinder SP 3.0 licensing is per farm—based on the number of front-end and application servers on the farm. The “Installation Code” will be based on the ID of your SharePoint farm instead of the fingerprint of the server on which LOGbinder is installed. This means that if you install LOGbinder on a different server on the farm, the same license key will be used for both. Also, if you upgrade the Windows server, you will not need to obtain a new license key.
LOGbinder SP 3.0 has only two editions: “Microsoft SharePoint Foundation 2010” and “Microsoft SharePoint Server 2010.” (For SharePoint 2007, “Microsoft Windows SharePoint Services 3.0” and “Microsoft Office SharePoint Server 2007.)
The server count is now included in the licensing window. In addition, you can obtain the server count through the menu File\Options, then click on “SharePoint Farm Properties,” and note the value of the “Number of servers requiring LOGbinder license.”