New Security Log Illuminates Windows Events

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.

   Previous  1  [2]  3  4  Next