Storage Requirements for the Windows Vista™ Security Log

Recently, we've created a few blog postings that talk about some of the new events present in the Microsoft Windows Vista™ security log. From a security standpoint, Vista's increased number of auditable events is excellent, as administrators and compliance officers can get a much deeper picture of the actions taking place on a computer prior to and during a security incident.

However, if you are required to retain those security events, either by law (e.g. HIPAA, SOX, GLB, PCI, etc) or by policy, you need to start budgeting for more storage before you start your Vista and Windows Server 2008™ migrations.

Here are a few examples of how Vista security logs tend to grow much more quickly than their predecessors:

1.) Looking at some of our internal Vista security logs, there are tons of events relating to the blocking or accepting of network data via the Windows Filtering Platform. Some organizations may find this data valuable, especially if the machine is exposed to the public, however others may not.

2.) Some events log extra information at the end of the Description field that serves no other purpose than to further explain the parameters in the Description field. For instance, every 4608 event (Windows is starting up) also tells you that:

"This event is logged when the LSASS.exe starts and the auditing subsystem is initialized."

Similarly, every 4634 event (An account was logged off) feels the need to mention that:

"This event is generated when a logon session is destroyed. It may be positively correlated with a logon event using the Logon ID value. Logon IDs are only unique between reboots on the same computer."

These are just two brief examples, but note well: your Vista logs will use up more space than your XP and Windows 2000 workstation logs. If you are reassuring yourself now by thinking that you only need to retain server logs, bear in mind that Windows Server 2008 will share Vista's new events and logging tendencies!

Fortunately, the current release (and several prior releases) of our Event Archiver™ software offers you techniques to help you manage your storage of log data. Event Archiver allows you to automatically prune your database tables by date, selectively import only key events or exclude non-key events into database tables with global import filters, and keep your data in multiple compressed formats for storage efficiency. As the number of auditable events increase and expand in size, these features become increasingly important.

Auditing and Storage Requirements

One thing that admins tend to overlook when setting up a SEM or event log management package on their network is the amount of storage required to house all of the event log data.

Regardless of which vendor you choose (or even if you decide to attempt to do it in house with scripts), you need to keep in mind that the data output from native Windows event log files (e.g. EVT/EVTX files converted into database tables) will be greater in size than the native event log files themselves.

As mentioned briefly in this earlier post, EVT files contain references to other information not present in the log file itself. The resolution of those references into meaningful data is one reason behind the increase in data size after conversion.

Another factor that causes data size expansion is the field structure of the database itself. The number of bytes allocated for certain fields, as well as the use of UNICODE strings (e.g. two bytes per character) can both further contribute to this phenomenon.

A while ago, we wrote a freeware utility that does a nice job estimating the storage required to maintain your log data in various formats over time. You can download our Auditing Volume Analyzer tool here.

One final caveat: some SEM vendors in the marketplace attempt to take the log storage issue out of the equation by providing their own "black box" or appliance for accumulated log data. In general, we frown upon that approach here as it has the potential to hold your data captive. Should an audit or other incident arise - the last thing you want is data held captive in a proprietary storage system. For more on this topic and our general philosophy on event log management, please read this article.