New Security Log Illuminates Windows Events

Windows Server auditing and the Security event log have really changed in Windows Server 2008 and Windows Vista, and I'm glad to say that most of the changes are good. The Security log is a little cleaner and a little easier to understand, but you still need a lot of knowledge about Windows security and experience in decoding mysteries to really "grok" it. I've spent the last decade deep in the bowels of Windows security and auditing, and lately I've been concentrating on Windows 2008 and Vista, so maybe I can help bring you up to date with the changed event ID numbering, the new, more granular way that audit policy is handled in Windows 2008 and Vista, the XML log format, and enhancements to the Microsoft Management Console (MMC) Event Viewer snap-in.

New Event IDs
If you're already familiar with the Windows Security log, the first thing you'll notice when you open Event Viewer in Windows 2008 is that none of the old event IDs shows up. That's right! Just when you thought you knew the difference between event ID 528 and event ID 529, Microsoft goes and changes the IDs. Actually, Microsoft kept many of the events found in Windows Server 2003 but added 4,096 to the event ID. For instance, event ID 528 in Windows 2003 is event ID 4624 in Windows 2008.

I'm actually glad Microsoft changed all the event IDs because the company also completely revamped the fields in the description of each event. In Windows 2003, Microsoft kept event IDs from Windows 2000 Server but changed the events that they track, combined multiple event IDs into one, and changed the order of fields in the descriptions. This wreaked havoc on automated log analysis software. The new numbering lets you add Windows 2008 systems to your environment and begin collecting logs without throwing off your existing filter, alert, and reporting definitions. You will have to add new definitions for the new event IDs.

Audit Policy Subcategories
One of the most frequent questions I've gotten from people over the years about the Security log is how to stop Windows from logging so much #%*@&! noise (i.e., useless events that make finding the important events that much more difficult). My response has always been, "You can't configure the noise out of the Windows Security log; that's the job of your log management solution."

Well, Microsoft has taken a small step in the direction of helping you quiet things down. The company didn't do it the way I would have, which would have been to introduce a firewall-like rule set that would let you define on an event-ID-by-event-ID basis criteria for whether to record the event. Instead, Microsoft expanded the 9 audit policies (aka categories) in Windows 2003 to 52 in Windows 2008.

Actually, Microsoft kept the existing 9 policies and broke them into subcategories, each of which you can enable for success and/or failure events. If you like, you can still manage audit policy with the 9 top-level categories. Figure 1 shows the 9 categories and 52 subcategories. (See http://www.ultimatewindowssecurity.com/newauditpol for a table that decomposes the 9 categories into their respective subcategories and provides a brief description of what kind of events and activity each category tracks.)

This is all good news so far. In fact, you can eliminate a number of old noisy events with this more granular audit policy as well as disable some of the new event IDs logged by Windows 2008, which are pretty noisy as well. For instance, most of you will want to disable the Filtering Platform Packet Drop and Filtering Platform Connection subcategories, which are extremely noisy because they record network traffic at the packet level.

But here's some bad news: You can't manage audit policy at the subcategory level by using Group Policy. Microsoft added the 52 new subcategories but didn't update Group Policy with new policies to enable or disable the subcategories. In fact, you won't find these subcategories anywhere in the GUI. The only way to enable or disable at the subcategory level is with the Auditpol command. The Microsoft article "Security auditing settings are not applied to Windows Vista client computers when you deploy a domain-based policy" (http://support.microsoft.com/kb/921468) proposes a method for configuring audit subcategories via startup scripts defined via Group Policy, but the technique is something Rube Goldberg would be proud of.

Working with Audit Policy
Let's delve a little into the Auditpol command as well as how Windows resolves possible conflicts between the audit policy you configure in Group Policy Objects (GPOs) and the subcategory policy you can configure with Auditpol. To find out the current status of your 52 audit subcategories, just log on to the desired system and type

auditpol /get /category:*

at the command prompt. This command produces output similar to that shown in Figure 1. As you can see, the 9 top-level categories are listed with their subcategories below and whether each is enabled for success and/or failure.

To change auditing for a subcategory, just

run auditpol with the /set command and specify the subcategory and whether to enable success and/or failure events. For instance,

auditpol /set 
  /subcategory:"System Integrity"
  /failure:enable /success:enable 

enables the System Integrity subcategory for both success and failure events.

But what if you configure audit policies for the 9 top-level audit categories in Group Policy that conflict with policies set for the 52 subcategories in Auditpol or vice versa? For instance, let's say your computer W08-YHWH resides in the Servers organizational unit (OU) in Active Directory (AD). You edit a GPO linked to that OU to disable the Audit logon events (aka Logon/Logoff) top-level category for both success and failure. Then you log on to W08-YHWH and, with Auditpol, you enable the Logon subcategory for success and failure. What will the final outcome be?

   Previous  [1]  2  3  4  Next