Had many, many valuable conversations with colleagues in DC a couple weeks ago at HP Protect 2013 about auditing and monitoring SharePoint, SQL Server and Exchange. This is a tough subject because there are so many details. You can’t just answer "Are you currently monitoring SharePoint/SQL/Exchange: Yes/No?"
This is because each of those applications have multiple logs with widely ranging security value and content. Also, there are some existing connectors from HP for these apps but their capabilities, caveats vary greatly - as well as exactly which logs and versions of SharePoint/SQL/Exchange they apply to. Many folks are making decisions and/or belaboring under one or more misconceptions.
In this post I'm going to try to quickly bust a few of those and myths and provide links to where you can get more details. It’s kind of specific to ArcSight users but has value to anyone with a SIEM and Microsoft apps.
1. We are already monitoring SharePoint.
OK, but what are you actually monitoring in SharePoint? SharePoint has about 4 different logs. Only one of them is the actual SharePoint Audit Log with security activity. And that log is not available through normal log collection means. Just recently HP released a SmartConnector for SharePoint. But this SmartConnector simply uses JDBC to pull the raw audit log from the SharePoint DB. Take a look at the raw audit log in SharePoint (http://www.ultimatewindowssecurity.com/sharepoint/logbindersp/crypticdata.aspx) Getting the raw SharePoint audit log into ArcSight allows you to say you are collecting the SharePoint Audit log but try understanding and responding to the events. Things like user 17 and role 42 are not translated, so you don’t know who or what you are dealing with. Check here for more non-commercial information on the SharePoint audit log. Learn how we solve the problem with LOGbinder SP here.
2. We are already monitoring Exchange.
Again, what are you actually getting from Exchange? Exchange has 3 different logs that are valuable to security. The message tracking log tracks message flow and is available through a connector for Exchange Message tracking. While it’s incredibly voluminous, it does allow you to track all inbound and outbound emails, but it doesn’t track:
- Non-owner access to other mailboxes
- Mailbox copies and exports
- Privileged user operations
- Administrative changes
- Security policy and configuration changes
For non-owner mailbox access auditing, you need the mailbox audit log. As of Exchange 2010 that log is not a log file nor is it sent to the Windows event log. Each mailbox has a hidden folder where it stores audit records for that mailbox. There is a SmartConnector for the Exchange mailbox audit log and it is practical if you need to audit a handful of mailboxes and do not require full audit log integrity. See my comparison here between that SmartConnector and LOGbinder EX. Check here for more non-commercial information on the mailbox audit log.
The 3rd log in Exchange, admin audit log, is extremely important because it gives a full fidelity audit trail of all privileged user activity in Exchange including:
- Exports and copies of mailboxes
- Changes to security policies
- and about 600 other operations
This log is also completely inaccessible to SIEMs because it’s stored in a hidden mailbox of all places in Exchange. There is no connector at all, but we do handle it beautifully with LOGbinder EX. Check here for more non-commercial information on the admin audit log.
What about SQL Server auditing?
SQL Server 2008 added a new and beautiful, true, honest-to-goodness audit capability. It blows the old SQL Trace out of the water. No comparison. SQL Audit can send events directly to the Windows event log which you could then pick up with the WUC or Snare, etc. But if your DB admin has anything to do with it you may run into trouble because of the performance load of both logging and retrieving those events through the heavy Windows event API. Microsoft recommends using the other output option which is to a binary log file on some other server on the network. This is the most efficient high speed low overhead method of getting audit events off of a busy production SQL Server. If you need that option, LOGbinder SQL is there to help. The other issue with collecting SQL audit events from the Windows event log is that SQL Server logs every possible operation (we’re talking 100s of them) as just one generic event ID with the same static text and fields. Can you say cryptic? We can help with that too. More, non-commercial, information on SQL Server Audit here.
Some other educational resources right here on 724 are: https://protect724.arcsight.com/docs/DOC-3181 for Exchange and https://protect724.arcsight.com/docs/DOC-3170 for SharePoint.
I hope this helps and feel free to reach out to me anytime…
Randy Franklin Smith
Security Log Nerd
Designer of LOGbinder