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,

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?

By default, if you define a value for one of the 9 top-level categories either in the computer's Local Security Policy or in an applicable GPO, the top-level policy will override the configuration at the subcategory level. Under Windows default behavior, your subcategory policies take effect only if you leave the top-level category undefined in the Local Security Policy and in all applicable GPOs. I stress default behavior because a new setting in the Group Policy Object Editor (GPE) under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options called Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings, if enabled, reverses audit policy behavior so that whatever you configure for the subcategories in Auditpol overrides how the 9 top-level policies are set by the applied Group Policy.

I can't believe that Microsoft let Vista, much less Windows 2008, out the door without making this extremely important and sensitive area of security configuration manageable via Group Policy, but it did. And the solution set forth in the above Microsoft article is flimsy and prone to failure, in my opinion. The other amazing thing is that you can't run Auditpol against remote computers—only against the local system.

Anyway, here's what I recommend as a starting point for your audit policy in terms of top-level categories: Enable System, Policy Change, Logon/Logoff, Account Logon, Account Management and, on domain controllers (DCs), DS Access, which gives you the ability to track important changes to OUs and GPOs. Enabling these categories for success and failure will get you your most important information while eliminating major sources of noise such as Privilege Use and Object Access. If you do need to perform some file system auditing, then enable Object Access's File System subcategory.

After you enable the top-level categories you want by using GPE, use Auditpol to turn on success and failure auditing for each desired subcategory as shown above.

Selectively disable subcategories to eliminate events you don't want. To discover and confirm which subcategories to disable, identify events you don't want in Event Viewer and determine their subcategory name, which is known as the Task Category in Event Viewer. Before disabling a subcategory, make sure you don't need any other events belonging to that subcategory and success/failure type. To make that decision, filter the log in Event Viewer to show only the events in that subcategory. You can also refer to my free Windows Server 2008 Security Log Encyclopedia at http://www.ultimatewindowssecurity.com/encyclopedia.aspx for a listing of events by category. If you determine that no important events are logged by that subcategory for the same success/failure type, use Auditpol to disable the subcategory for success, failure, or both (as appropriate).

Don't forget that if you want your subcategory settings to take effect, you'll need to change the Group Policy setting Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings, as mentioned above.

Event Format
Now, let's discuss the new format that events have in Windows 2008. Microsoft changed both the physical file format of the Windows event logs as well as the logical fields that comprise each event sent to the log. If you're an XML buff, the XML schema for event logs is http://msdn2.microsoft.com/en-us/library/aa385201.aspx; otherwise the new format doesn't impact administrators that much. If you're a developer dealing with event logs, Windows still supports the old Win32 Event APIs, but you might want to check out the new capabilities at http://msdn2.microsoft.com/en-us/library/aa382610.aspx. The Security Pro VIP article "Windows Eventing 6.0," September 6, 2007, InstantDoc ID 96587, also has a few more details about the new XML log and event formats.

The logical format of events (as displayed by Event Viewer in an event's properties dialog box) is much more important. Figure 2, shows event ID 4625. Each event still has a number of what I call standard fields as well as a text description. Standard fields provide information that applies to every event regardless of event ID—information such as the date and time of the event, the source, the category, and whether the event was a success or failure event. The message and data items in the text description vary from one event ID to another.

Each event ID's description is a combination of static text and dynamic insertion strings. In the text below, you see the first few lines of event ID 4625's description. The text in black is static; the values in red are specific to the particular instance of the event.

An account was successfully logged on.
Subject:
Security ID: SYSTEM
Account Name: WIN-K2SF4WMIK17$
Account Domain: ACME
Logon ID: 0x3e7

So that much hasn't changed—that is, the concept of standard fields and a description that's event ID specific. What has changed are the individual standard fields and the insertion strings logged by each event ID.

Compare event ID 4625 (Figure 2) to its predecessor, event ID 529 in Windows 2003 (Figure 3). Most of the changes to the standard fields are easy to figure out, such as Date and Time changing to Logged, but let me call out a few that might require a little explanation. First, notice that the old top-level category doesn't show up in Windows 2008 events because in Windows 2008, the top-level audit categories relate only to audit policy (i.e., which event IDs get logged and which don't). When Windows 2008 logs events, it resolves them down to their subcategory level, which Event Viewer calls the Task Category. Evidently being consistent with Auditpol and using Subcategory was too boring.

There's no longer any Type. Now, we have Level and Keywords. As far as I can tell, all events in the Security log appear to have the Information level, and either the Audit Failure or Audit Success keywords.

You'll find that the event descriptions have changed drastically. Windows 2008 inserts many more dynamic values in the descriptions, and Microsoft has made progress in enforcing some consistency in description data throughout the different event IDs. The event ID descriptions are a good example of how a well-designed XML schema helps handle data records that are similar in structure but dynamic from one instance to another.

Many event ID descriptions share common data elements. For instance, nearly every event needs to log subject information—that is, the "who" of the event. As Figure 2 and the text above show, subject information includes SID, account name, domain, and logon ID. Historically, Windows has been inconsistent from one event to another about exactly how it logged this subject information. Some subject data was sometimes omitted or labeled differently.

To see an example, compare the subject data in Windows 2003's Account Logon events. The account name is labeled several different ways, and certain subject data is missing from some event IDs.

In Windows 2008, you'll find a number of common sections across most event IDs. I already mentioned the Subject section. Events that track an operation on some type of object—such as access to a file—have an Object section with all the appropriate fields for identifying the object, such as the type of object and its fully qualified name. All events that note the system process involved in the event include a Process Information section that documents the process identifier (PID) and name of the executable.

Finally, you'll find more explanatory text at the bottom of some event descriptions giving background on the event or explaining a little bit about some of the values in the description. But the coverage is pretty spotty and frequently incomplete. Whew! My Security Log Encyclopedia lives on!

New Event Viewer
I'll finish up by describing the new Microsoft Management Console (MMC) Event Viewer snap-in. Event Viewer is still not a full event log management solution, but it's a much improved tool for casual, ad hoc analysis of security events.

The first thing you'll notice about Event Viewer is the new task pane, shown on the right in Figure 4, which greatly reduces the clicks required to perform common tasks such as setting up and later clearing a filter. On the subject of filtering your view of the Security log, Event Viewer provides the same basic filter features it's always had but with a number of improvements.

When you click Filter Current Log in the task pane, you'll see the Filter Current Log dialog box shown in Figure 5. The Logged drop-down box makes it much easier to limit the time range you want to analyze by providing Last hour, Last 12 hours, Last 24 hours, Last 7 days, Last 30 days, and of course Custom range options. These options are a great improvement over Windows 2003 and earlier, which required you to specify exact date and time ranges.

You can limit the view to failure or success events by using the Keywords drop-down box and filter by subcategories with the Task category drop-down box. Note that the Task category drop-down isn't populated with the 52 audit subcategories until you select Microsoft Windows security auditing in the Event sources drop-down box. To view the results of your filter, just click OK.

Here's a cool new feature: Once you have the filter set up just the way you want it, you can save it for future use with the Save Filter to Custom View option in the task pane. When the Save Filter to Custom View dialog box appears, you provide a name, a description, and a location under the Custom Views folder (visible in Figure 4).

For the first time, Event Viewer lets you easily attach to events tasks that are automatically executed whenever the events occur. Say you have a special Microsoft SharePoint server dedicated to your company's senior executives, and you want to know whenever an account gets locked out so that you can call the executive and help him or her get back onto the server with minimum inconvenience (for the executive, anyway!). You can trigger a message to be emailed or displayed on the console or a command or script to be executed whenever an account lockout event is logged.

The simplest way to attach a task to an event is to select the desired event in Event Viewer and then click the Attach Task To This Event option in the task pane, which starts the Create Basic Task wizard. The wizard asks you to name the task and prompts you to define the program, email message, or display message you desire when that event ID is logged. After you finish the wizard, you can view the event, its properties, and its history by opening the MMC Task Scheduler snap-in found on the Start Menu under All Programs\Accessories\System Tools.

Often, though, you'll need to be a little more specific with your trigger criteria than simply specifying an event ID. The good news is that any criteria you can specify in a custom view filter you can also specify in an event trigger, including advanced filters written in XML. The bad news is that you can't use Event Viewer to create the trigger—you must use Task Scheduler instead. Open Task Scheduler and click Create Task. Specify the name and description of the event as well as what account the task should execute under on the General tab.

Then select the Trigger tab and click New. In the New Trigger dialog box, select On an event from the Begin the task drop-down list. Select Custom in the Settings drop-down box, and click New Event Filter. Now you're shown the same dialog box as when you create a custom view in Event Viewer. You can either use the Filter tab to specify the filter criteria or use the XML tab to specify an advanced filter in XML syntax. After you finish the trigger criteria, you can go to the Actions tab to specify one or more actions for Task Scheduler to execute.

A final thing I like about Event Viewer is the revamped log retention policy options you see when you open the properties of the Security log. The old Overwrite events older than _ days has been replaced by Archive the log when full, do not overwrite events, which for the first time exposes a feature that's been around for a long time but was configurable only via the registry by using the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\ Service\AutoBackupLogFiles setting. If you select the Archive the log when full option, Windows will automatically archive the Security log to C:\Windows\System32\winevt\Logs.

A word of caution, though: Windows will continue logging and archiving events until it fills the drive, so you need some kind of automated process for moving the logs. In the end, there's no good substitute for a real log management solution from an ISV. "Event Response," November 2004, InstantDoc ID 44093, compares three such tools. The Security Pro VIP article "Enterprise Event Logging for SMBs," InstantDoc ID 95511, describes six enterprise log collection and management tools.

Get Going
As you can see, a lot has changed and a lot has stayed the same in Windows auditing and security logging, but in general, there are many improvements. The new more granular audit policy will help you eliminate some but not all the noise that Windows writes to the Security log. The automatic task execution capability might help you automate responses or be alerted to important events when they occur. And the custom filter views will certainly help administrators that don't have a full-featured log management solution.

All the new event IDs and their changed formats will definitely mean a steep learning curve and lots of report and alert criteria redesign before you can start monitoring and analyzing Windows 2008 and Vista logs. Ultimately, though, the new formats are an improvement, especially in the area of consistency.

One other major new feature associated with event logs in Windows 2008 and Vista is the new event-forwarding capability, which for the first time allows Windows systems to automatically send events to other servers on which you can theoretically do centralized event management. But collecting logs from multiple computers is a gargantuan task, and Windows 2008's HTTP-based method for event forwarding is only intended for small volumes of events defined with very specific criteria. "Windows Eventing 6.0" describes Windows 2008 and Vista's centralized event-collection capabilities.

Get to know the new event log in Windows 2008 as soon as possible so that your security monitoring and compliance activities can continue unimpaired as you start migrating to the new platform.