That Infernal Road, Paved With Good Intentions...

Eric, the head auditing guru at Microsoft, posted today on his blog that he is receiving an ever-increasing number of complaints on the lack of documentation regarding the new Event IDs in the Windows Vista™ security log. Specifically, he says that our earlier post "complains" about how sometimes the "add 4096" rule works in Vista's security log, but not in all cases.

With that background, let me take some time here to clarify our original comments and attempt to speak to the source of the frustration Eric is hearing from log management vendors, log scripting enthusiasts, and security admins.

First off, our earlier post on the 4096 offset trick in Vista was not a complaint in so much as it was an attempt to draw attention to a very significant change in the Windows Vista security log. Keep in mind, while Microsoft has made subtle changes to security events ever since Windows NT, the changes in auditing from Windows® NT to Windows 2000 to Windows XP to Windows 2003 are nowhere near as complex as the changes from Windows 2003 to Windows Vista and the forthcoming Windows Server 2008™.

Expanding on this, the complete renumbering of security events in Vista is just the tip of the iceberg. Compounding this trauma of sorts is:

A.) A completely new logging file format, the EVTX file
B.) A completely new API that is used to manage these EVTX files
C.) New, different auditing categories (Tasks) in the Vista security log
D.) Shifting of user account information out of the User field altogether in security events
E.) Other changes to the "traditional" log fields that were present in the legacy EVT files (e.g. the Level/Type field)
F.) Other issues related to forward and reverse compatibility as it relates to log management on pre-Vista and Vista.
... etc

That being said, we know that Eric is not responsible for all of these changes. He did not create the new EVTX log format or the API used to access it, for instance.

Collectively, though, all of these challenges together are most likely frustrating third-party log management vendors, as well as the admins who have developed scripts to automate security event management. Unfortunately, it would appear that Eric is getting the brunt of that frustration. Perhaps he should post contact information for the team at Microsoft that developed the Crimson logging format and accessory APIs so that constructive criticism and questions can be more properly distributed.

At Dorian, our approach is to adapt and innovate around the changes to Microsoft Vista's new logging format and auditing system, and we are proud of our efforts to date. Still, we hear every day the issues that small and medium sized businesses face regarding log management, often directly due to compliance regulations. Not every organization has the budget or resources needed to procure a commercial log management package, and for those facing a complete rearchitecture of their log automation scripts in Windows Vista and Windows Server 2008, those limited resources just got stretched even tighter.

Tip of the hat to Eric at Microsoft

Many kudos to Eric Fitzgerald, the head of Microsoft's Windows Auditing Team, for his very candid explanation on the transposing of security event ids in Vista. He writes:

Doriansoft noticed that there's a relationship between our pre-Vista security event IDs and our Vista-era security event IDs.

For most security events:VistaEventId = PreVistaEventId + 4096

Why is this?

We needed to differentiate the Vista events from the pre-Vista events, because we were significantly changing the event content and didn't want to break automation. However we wanted to preserve the knowledge that security professionals already had in their heads about security events, so we wanted to make sure that there was a relationship between old and new event IDs.

We decided to offset the old IDs by some constant to get the new IDs. I wanted to offset them by a decimal number (say 6000, so 528 would become 6528, etc.). However event IDs are declared in hex in the source code and are all 3 digits long (528 = 0x210), and Raghu, my developer, wanted to conserve effort, and he won that battle so we added 0x1000 (4096) to the existing event IDs.

For what it's worth, I think Eric's initial approach would have been best, as I think most non-developers can deal with Base 10 offsets in their head much more easily than Base 16. Still, his candor in addressing the issue is refreshing, and is much appreciated.