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.

Seeing Crimson...

Sorry, couldn't resist that little play on words for this inaugural blog post. We're wrapping up development right now on new libraries to support the management of logs on Microsoft Vista. In case you haven't heard, Microsoft has introduced a new logging format in Vista, EVTX files. Back in Vista's beta days, this logging format was code-named Crimson.

So far, the development experience has been quite an eye opener. While the ReportEvent function, which is the cornerstone function for writing to the event log in the legacy EventLog API, works great in Vista, other Legacy API techniques do not. For instance, if you try calling the OpenBackupEventLog function on Vista to open a saved legacy EVT file, the function will fail. Interestingly enough, Microsoft has still not updated its documentation at MSDN to reflect this problem as of this writing: http://msdn2.microsoft.com/en-us/library/aa363671.aspx

Going in the other direction, legacy Windows clients (e.g. NT/XP/2000/2003) can open a handle to a "live" Crimson/EVTX log on Vista remotely, but the traditional techniques used to parse through and render the data on such a log will most likely fail due to a variety of other reasons that relate to the hardening of Vista's networking and new message provider data stores. On top of that, legacy Windows clients simply have no mechanism for reading saved Vista EVTX log files whatsoever.

While the Crimson/EVTX format does confer advantages over its predecessor, such as XPath queries, we're still not sure why Microsoft elected to cripple the OpenBackupEventLog function on Vista while supporting other legacy EventLog API calls. Certainly, from a programmatic standpoint, it would appear that the function does little more then read linked data structures out of a saved binary file. One perhaps controversial theory is that Microsoft wanted to make transitioning to Vista much easier for publishers of Windows events (e.g. software developers whose programs write to the log), than for the consumers of the those events (e.g. the utility software vendors whose programs manage and analyze log files). Considering Microsoft's efforts to increase market share in the server management market, that could be the case.

Regardless, we've found cool new ways to work around these potential trouble spots and look forward to introducing Vista/Longhorn compatible versions of our software very shortly.