Windows Audit/Logging

Eric posted a blog entry on Tues entitled "Keeping the noise down in your security log" that is a 'must read'! He makes some very good points about reducing the amount of noise in the Security Event Log, and presents some tips for doingexactly that.

I took a couple of interesting points away from the blog entry myself, the first being that enabling auditing on a system, and then auditing both success and failure events for every setting is pretty much just as bad, if not worse,than not auditing at all. Doing so, and then complaining that there's too much noise in your Event Log can be filed under the heading of "Duh".

Second, Eric's process is iterative. That means that you apply a template, let the system run for a bit, observe the changes, and then tweak the settings as necessary. My experience has been that most Windows admins don't have the time or interest in this sort of process...once the settings are changed, they're off to something else entirely. This is due in large part to how they are tasked by their managers, their individual knowledge/skill level, etc.

The third thing that I took away from Eric's entry is the need for documentation. Something like this is going to look odd to a new admin coming on board, so having documentation in the form of policies, procedures, and even a file stating why the settings were made (with references to pertinent MS KB articles, etc.) wouldbe very beneficial.

So, once you've made your settings changes, then what? You've taken steps to reduce the noise in your logs, so then what do you do? Well, there are ways to parse the data. One is to use DumpEvt or PSLogList to export Event Log entries to a text-based format. From there, you can use scripts to parse the data.

Being a Perl user, I'm more likely to opt for Perl to parse the text-based output of the log dumping tools mentioned above. The Microsoft Script Center provides a wealth of resources for using a variety of scripting languages for all sorts of system administration needs. Take a look at the Script Repository, and choose your language (Perl, Python, JScript, VBScript, REXX, etc.) to get started.

Microsoft also provides a tool called LogParser, which can be used to parse Event Logs and even text-based logs using SQL queries. LogParser.com provides some pretty extensive support for the Microsoft tool. LogParser works not only with Event Logs, but also text-based logs, such as those created by IIS. The neat thing about this tool is that it ships as an EXE as well as a DLL COM object, meaning that you can script your searches and correlation activities via the COM object.

EventComb is a graphicaltool provided by MS for searching Security Event Logs.

There are a lot of freeware tools for managing Event Logs across several machines, or the enterprise. Again, Perl can be used, or a syslog client/agent can be added to machines, and Event Log entries can be stored in text files, Excel spreadsheets, a mySql database, etc. Perl can be used to create reports of events, and there are also modules you can use to provide graphical representations of the data.

Post a comment, or drop me a line, and let me know what your favorite method for managing Event Logs is, or send me any questions you may have.