For the past several years I’ve specialized in helping people understand the Windows security log, but the truth is that operating system logs only take you so far.  In today’s environment of increasing compliance and security requirements, you need the same level of auditing at the application layer as is found at the operating system and network device layers.  A great example of such an application is SharePoint.  As more and more information and processes move to SharePoint, it becomes critical for compliance and security requirements to monitor and audit SharePoint activity.  And with regard to logging SharePoint security events I have good news and bad news … and then more good news.

First, the Good News

As of Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0, SharePoint has its own native audit log! The SharePoint audit log allows you to track changes to configuration, security and content as well as viewing of content and other document operations like check-in and check-out.  Before you can track what’s happening, you have to enable auditing for the types of activity that are important to you.  You, as a site collection administrator, configure SharePoint audit policy at the site collection level under Site Collection Administration / Site collection audit settings as shown here:

Once enabled, SharePoint begins recording the indicated security events to the audit log.  At this time auditing is basically an all or nothing proposition in that, for instance, auditing of check-in and check-out is performed for all document libraries within the site collection; you can’t define audit policy at lower levels such as sites, lists or libraries.

The audit log is stored with all other content such as list items and documents in the SQL content database.  To view the SharePoint audit log visit Site Collection Administration / Auditing reports as shown here:

As you can see, SharePoint provides some prebuilt reports that filter the audit events according to the desired type of activity ranging from content view to security setting changes.  SharePoint delivers these reports via Excel.  Shown below is an example of a Content Modification report.  As you can see, it includes the IDs of the site, item, user and document, the operation performed and, of course, the date and time the event occurred:

Now for the bad news

The SharePoint audit log provides a critically needed audit trail of what’s happening inside SharePoint, both in terms of end user and administrator activity.  It is by no means a complete solution, however.  I’ve listed the top problems you should be aware of with the SharePoint audit log below, and in the following “More good news” section, I’ll show you how I’ve addressed these problems:

1. SharePoint audit log is trapped
   SharePoint doesn’t really generate an audit log per se.  Instead SharePoint stores audit events in the content database along with all other SharePoint data. This is a big problem in terms of accessibility, log management and security.  Accessibility is hampered by the fact that you must use write custom code against the SharePoint object model to access the audit log.  What this means is you can’t directly query the audit log and you can’t use your log management or SEIM solution to collect and monitor SharePoint audit trails.  Which, in turn, creates a security problem because a commonly accepted info security best practice dictates that you must move logs as quickly as possible off the system where they are generated to a separate and protected log archive.
2. Reports are unreadable
   If the above report seems a bit cryptic, you are right – you can’t read the Excel-based audit reports generated by SharePoint.  SharePoint audit events contain countless ID codes, surrogate keys and other numbers that can only be translated programmatically and often require queries against the SharePoint object model.
3. No alerting
   There’s no way to send an email or otherwise alert security staff if unusual or suspicious events are detected.  Understandably, we don’t expect every application developer to reinvent the wheel in terms of security monitoring, but that’s why it’s so important that it be possible for audit logs like SharePoint’s to be accessible via log management solutions like Prism EventTracker, Quest InTrust, LogRhythm or AlertLogic, among others.  These solutions have already solved the problems of log collection, alerting, reporting and archival functionality.
4. No scheduled pruning or archival
   Audit events just grow and grow until an administrator manually clears the log from the Site Collection administration.  (Some pruning capability is coming in SharePoint 2010.  As you probably know, auditing any system can generate huge amounts of data, and the last place you want to store log data is in the content database of SharePoint where it consumes expensive SQL server storage and slows down the SharePoint application. Not to mention the fact that this means your audit trail is vulnerable to whatever security incidents affect SharePoint (see point 1).
5. No interface for auditing Windows SharePoint Services (WSS)
   WSS includes auditing, but the administrative pages for enabling auditing, generating reports and clearing the log are absent.  You can only audit WSS by writing custom code that manages auditing via the SharePoint object model.

More good news

Well, I’m still a developer at heart and the critical need for the SharePoint audit log combined with these very real problems pushed me over the edge, and the result is a new software solution called – get ready for the shameless plug – LOGbinder SP (www.logbinder.com/sp).

LOGbinder SP translates cryptic SharePoint audit events into plain English and bridges the gap between SharePoint and log management solutions.  By way of an example, LOGbinder SP turns a security modification like this:

As you can see LOGbinder SP resolves the user and object IDs and other cryptic codes, producing an easy to understand, plain English translation of the SharePoint audit event.

LOGbinder SP then outputs that event to the Windows event log – either the Security log itself or a custom event log.  From that point, you can use any log management solution to manage SharePoint audit events like any other security log, taking advantage of all the collection, alert, report and archival functionality of your log management solution.

LOGbinder SP automatically prunes events from the SharePoint content database after forwarding them to the event log, thus preventing your database from ballooning and slowing down SharePoint.  LOGbinder SP runs as an efficient Windows service and makes no modification to the SharePoint application or interface.

Final thoughts

SharePoint auditing will only become more important as SharePoint becomes more embedded in the business processes of organizations.  Regulatory compliance demands that we monitor and audit business processes and information flow, and thankfully Microsoft has added an important audit foundation to SharePoint.  But like many foundation technologies, there are gaps that need to be filled and we hope LOGbinder SP helps you fill those gaps with the SharePoint audit log.