Which Security Event Log audit categories are most useful on a Windows client?

Let’s say you’re looking to maximize the value of the data logged to the Security Event Log on a huge number of Windows clients (say, Windows XP SP2).

Further, let’s assume that you’re not inspecting such logs on a regular basis, but instead you just want to keep the most critical events in case you have to track down some “suspicious activity” later.  [Suspicious activity would probably include such things as successful intrusions into the PC (whether by attackers or malware), which is going to be a losing battle but worth trying.]

You have two different sets of knobs to twiddle: which categories of security events will be logged, and how the security Event Log will be configured.  The categories are the more involved thinking, so let’s start with the Event Log configuration first, shall we?

Security Event Log configuration

The default Security Event Log size on Windows XP is a paltry 512 KB.  [It got boosted on Windows Vista, so don’t go yelling at Microsoft — they heard ya already.]  The question isn’t if you should increase its size, but by how much?

When it comes down to a “best practice”, I’ve always found it to be an arbitrary choice.  This choice should be informed by the level of activity you expect (or tend) to see — many customers who turn on all logging options can fill up a 10 MB log in the space of a week, but those who make more judicious choices can survive on 2048 KB for sometimes a month.

The upper limit is somewhere in the neighbourhood of 300 MB, but that limit includes all Event Logs (even custom event logs created by other applications, I believe) — this is documented in Chapter 6 of Threats and Countermeasures.  So for example, if you’ve already set the System and Application logs to 50 MB apiece, I would strongly advise a Maximum log size of somewhere around 150-200 MB for the Security event log.  [Note: there is a bug that causes problems with Security event logs over 50 MB, which hopefully has not only been fixed in Windows Server 2003 but also Windows XP SP2.]

Aside: I’m sure there are others you might find, but on my own Windows XP box I’ve got four additional custom Event Logs:

  • Microsoft Office Diagnostics
  • Microsoft Office Sessions
  • Virtual Server
  • Windows PowerShell

The next setting to consider is how the logs will respond when they (inevitably) fill up.  There’s a setting innocuously labelled When maximum log size is reached, and there’s no perfect selection for everyone.  I’ve generally advised people to choose Overwrite events as needed, since most times, my customers would be interested in having a record of the most recent activity on the PC (e.g. tracking down details of a recent virus outbreak or suspected break-in attempt).

Finally, if you’re really anal about your Security Event logs (and what security geek doesn’t ideally want to keep them around forever?), you can enable one or two other specialized settings created just for you — but should you?

  • WarningLevel: recent versions of Windows can warn the Administrator when the Security Event log is nearly full (the usual recommendation is 80 or 90% threshold).  Windows will record a single System event with EventID = 523.  However, this is really only useful in cases where the Administrator wants to archive all Security Event Log records for later analysis or compliance checking, and they don’t already have an infrastructure for collecting and centralizing this logging info.  Warning someone of imminent failure, when they have no way to avert disaster, is really just a tease.  Thus, the more useful setting is…
  • AutoBackupLogFiles: Rather than let the log files overwrite themselves, some would prefer to archive all log entries.  This registry setting enables Windows to automatically backup and empty the specified Event Log, so that all the entries are stored in a local file on disk.  This isn’t perfect (a malicious attacker could wipe them out, for instance) but in cases where you just can’t imagine copying the security Event log between the time the 90% alarm goes off and you get the time to deal with it, this can be an effective alternative.  The most significant consequence of this is, over time, you may end up filling the OS volume with these archived files.  However, shunting such saved data to a separate, non-OS volume — or monitoring for disk space — are the kinds of problems that aren’t difficult to solve.

Security Event Log Category choices

Now the tough part: deciding which Success & Failure event categories to enable.  Leaning on Eric Fitzgerald and Randy Franklin Smith, here’s the current thinking I’m advising my customer for keeping the noise down (and which you’re welcome to leverage, if our thinking seems to fit):

Account Logon

  • This’ll identify the local (i.e. SAM-based) usernames that users have attempted to logon at this PC
  • If you’re interested in tracking actual user activity and successful break-ins, then enable Success auditing.
  • If you’re interested in (and plan to actually investigate) attempted but failed break-ins, and if your users don’t use local accounts (and thus won’t be the overwhelming cause of failed account logon attempts due to fat-fingering their password), then enable Failure auditing.  Under such circumstances, this shouldn’t be a significant contributor to the security logs.
  • Recommendation: enable Success and Failure auditing.

Account Management

  • This’ll identify such things as account creation, password reset and group membership changes.
  • Under normal circumstances these should be highly useful records (both the successful changes and the attempts) — especially if you don’t often manipulate local accounts on your XP clients.
  • Recommendation: enable Success and Failure auditing.

Directory Service Access

  • pointless — this only applies to Domain Controllers
  • Recommendation: No Auditing

Logon events

  • In a non-domain context, this doesn’t add much value over and above Account Logon auditing
  • Recommendation: No Auditing

Object Access auditing

  • This is a tricky one.  It logs little or nothing by default, even when Success and Failure auditing are enabled for this.
  • Used correctly, you can collect information with a fairly high signal-to-noise ratio.
  • Used incorrectly, however (and I was as guilty of this as anyone in my early career, and am still guilty today), and you’ll wipe out any useful information that the security log might’ve otherwise kept for you.
  • For example, I’m currently recording “Handle Closed” and “Object Access Attempted” events dozens or hundreds of times an hour.  What is being accessed?  LSASS.  Why?  Because of a single “Everyone: Full Control” auditing entry I added to the EFS\Current Keys registry key, to try to track down some odd behaviour a few months ago.  I’d forgotten about this ever since, and now I’m filling my 10 MB security log every 36 hours.
  • If you follow a VERY specific set of SACLs as in the EricFitz article linked above, then you will get some real value out of this category.
  • Recommendation: only enable Success and Failure auditing if you have specific activity you’re looking for, but be VERY careful when setting any SACLs on the system.

Policy Change

  • I’ve never seen anything in this category that helps really track down malicious behaviour
  • While it may be interesting to highlight attempted (or successful) changes to Audit policy or assigned user rights, I’m extremely skeptical that any of this information would be conclusive.
  • However, with Windows XP SP2 and the use of Windows Firewall, there are a number of very specific audit records (e.g. Event IDs 851, 852, 860) that track changes in the Windows Firewall configuration.  [It’s unfortunate that there’s not better info on the source of those changes.]
  • If you’re using the Windows Firewall in XP SP2, these records could well be useful in isolating the source, cause, or spread of a malware outbreak.
  • Recommendation: enable Success and Failure auditing when using Windows Firewall.

Privilege Use auditing

  • One of the greatest sources of log pollution, with little practical application.
  • This looks very useful to a security geek on paper, but in practice 99% of the recorded events will be (a) legitimate behaviour and (b) completely harmless.
  • Recommendation: No Auditing

Process Tracking

  • Aka “Detailed Tracking” (which is how these events are labelled in the security Event Log)
  • A great way to swell the size of your security logs, unless your PCs run a very small number of applications for very long periods of time.
  • However, when you’re using Windows Firewall, Failure auditing will record (in Event ID 861) a number of potentially useful pieces of information about any application that attempts to open an exception in the Firewall rules.
  • This logging can be very frequent (I show over 2000 events in the last 36 hours on my PC), but will give very detailed information on the the Port opened, the process that bound it, and whether the process is a service or RPC application.
  • (One good non-security use for this auditing capability is to troubleshoot unknown application behaviours.)
  • Recommendation: enable Failure auditing when using Windows Firewall.

System events

  • The only semi-useful information I’ve ever found from this auditing are the startup and shutdown events, and they’re much more useful in determining uptime statistics (and otherwise unseen BSOD events) than they are for security.
  • Unfortunately, these events get buried under the amazing number of 514, 515 and 518 events that accumulate in the space of a few days.
  • Recommendation: No Auditing

Summary: Windows XP Security Event Log auditing category recommendations

Security Event Log Category

Recommended Audit Level

Account Logon Success, Failure
Account Management Success, Failure
Directory Services access No auditing
Logon events No auditing
Object Access auditing No auditing*
Policy Change No auditing*
Privilege Use auditing No auditing
Process Tracking No auditing*
System events No auditing

* except in unusual circumstances, see above.

Advanced Oddities

Per-user Auditing

  • As of Windows XP SP2, auditing can be enabled or disabled for any or all users
  • Each category can be separately configured as well
  • On a PC with many user accounts, this would be useful to help remove the less interesting entries
  • However, where few accounts exist, and for PCs not joined to a domain, per-user auditing is not advised

Windows Firewall auditing

  • As I hinted above, there are some aspects of Windows Firewall’s operations that can be logged to the Security Event Log, and which don’t get logged to the pFirewall.log.
  • For organizations using Windows Firewall, and especially those that don’t have a perfect idea of all the exceptions they need to open up on their user’s systems, this auditing can be extremely useful.
  • Recommendation: To capture this data, you should enable Policy Change (success and failure) and Process Tracking (failure) auditing on the target systems

File/Registry access auditing

  • If you’re interested in detecting attacks that tamper with system files, then EricFitz has some fascinating work you should examine
  • His work became the input for the Security Configuration Wizard in Windows Server 2003 SP1
  • Having had a quick look at it, there’s nothing that looks dangerous or unsuitable for an XP client
  • Recommendation: if you’d like a quick & dirty way to detect changes to system files, cut and paste those “file access auditing” settings from the SCW templates, and make sure that you’ve also enabled Object Access auditing (success and/or failure, depending on whether you’re after actual changes or just attempted changes)

Full Privilege Auditing

  • You can toggle a Registry setting known as (duh) FullPrivilegeAuditing, but be warned: these are default disabled for good reason
  • Recommendation: do NOT enable this setting

Audit the access of global system objects

  • Ever since this got added late in the NT4 service pack cycle, I’ve never quite figured out what this really tells me.  Eric doesn’t seem to interested in this either for most of us.
  • Recommendation: turn this setting Off

Audit the use of Backup and Restore privilege

  • This setting blows me away — it’ll fill up the most generous security event log, ’cause it creates an entry for each file that is backed up or restored
  • Recommendation: do NOT enable this setting

CrashOnAuditFail aka “Shut down system immediately if unable to log security audits”

  • Are you nuts?  Have you ever met a sysadmin that voluntarily puts in place a predictable Denial of Service attack?
  • If you’re that one-in-a-million organization that can actually implement this setting, I want to hear from you.  Yours is a tale I just gotta hear…
  • Recommendation: duh, do NOT enable this setting

For More Information…

Eric Fitzgerald is an old colleague of mine from my days at Microsoft, and I have an incredible amount of respect for the depth and persistence with which he pursued issues in the Auditing subsystem of Windows over the years.  He’s like the Rain Main of Windows security eventing, except I don’t think he’s much of a fan of Wapner. 😉  Eric’s “Windows Security Logging and Other Esoterica” blog is chock full of Windows security auditing goodness.

Windows Security Log Encyclopedia — Randy Franklin Smith’s take on Security Event Logs

Technet Events & Errors Message Center — detailed information backing up each security Event ID and what it means.

Deciphering Account Logon Events — in case you wonder what “Logon Type 5” really means…

Account Management — disabling the noise — and we’re done!


[Apologies to anyone monitoring my external blog, as this is a straight repost.  However, I’m assuming very few of you know about both, so I’m going to start reposting anything that’s applicable to both audiences.]


3 thoughts on “Which Security Event Log audit categories are most useful on a Windows client?

  1. Hi Mike, I have a question regarding the event viewer. So once an event log reaches maximum capacity (512 kb for example) and events are overwritten, will a record of them still be found in the registry or are they also deleted from the registry? Is there a way to retrieve them? Please let me know


  2. For file and folder auditing I can recommend implementing a tool called < HREF="http://www.scriptlogic.com/products/filesystemauditor" REL="nofollow">file system auditor<> that we purchased as part of scriptlogic’s < HREF="http://www.scriptlogic.com/solutions/file_server_compliance.asp" REL="nofollow">file server compliance solution<>.We were looking for tools to address a number of concerns and this combination of products covered it all. Nice thing about this tool is that I get real time alerts and reports on any actions and access attempts on audited files and folders. No manual event log browsing.


  3. Like we always watch in movies that wrongful actions often occur in crowded places where an event is being organized, having and event security is necessarily important. There are a lot of companies that offer security service, but it will always be difficult to decide whom you will have to go far. Of course, you want to experience the best service possible so that you are rest assured of enjoying the event without worries. So in this case, one option that you should have when searching for a security service is Guardian Eagle Security.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s