Maybe Quiet Riot isn’t your band (OK, the song was originally a 1973 Slade hit but come on, I was only 3) but that line describes the Windows security log so well. There’s no getting around the fact that there are a lot of useless and inexplicable events in the Security log and the sooner you get comfortable with that the sooner you’ll save your sanity and get on with work. In this article I’ll look at some common examples or noise events in the security and discuss strategies for dealing with them.
You need to recognize noise events for what they are for 2 reasons. First the earlier in the log management process you can discard or ignore noise events the better for performance, bandwidth and storage. Second, you can waste a lot time investigating seemingly suspicious events that are meaningless.
One example of high volume noise events are Kerberos service ticket renewal attempts generated on domain controllers. Kerberos has 2 kinds of tickets – authentication tickets (aka ticket granting tickets) and service tickets. Authentication tickets (see event IDs 4768, 4771 and 4772 on Windows 2008 and 627, 675 and 676 on Windows 2003) are connected with the actual authentication of the user (or computer) to the domain controller while service tickets vouch for that user’s identity to the member computers the user subsequently accesses on the network.
When a user remains logged on (or a computer remains up) long enough the service tickets expire and Windows needs to renew them with the domain controller. A successful service ticket event (event ID 673 on Windows 2003 and 4769 on Windows 2008) is useful in that it provides a record of the workstation and servers a user accessed. But a successful ticket renewal (event ID 674 on Windows 2003 and 4770 on Windows 2008) denotes nothing of value other than the fact that the user or computer remained logged on or powered up for a long time. If a user remains logged on (or a computer remains up without being rebooted) for extra-long, the service ticket reaches it renewal lifetime limit and the domain controller finally rejects the renewal request which generates a renewal failure. There are other scenarios but at the end of day any kind of service ticket renewal (successful or failure) and any kind of service ticket request failure event is essentially noise. There are some theoretical malicious situations where service ticket events could conceivably be generated but in practice they are very unlikely and there are no criteria you could use to distinguish those events from all the background noise of other service ticket events.
An example of a seemingly suspicious event that is really just noise is the sometimes frequent occurrences of event ID 537, “Logon failure - The logon attempt failed for other reasons”, where user name is blank. I frequently hear from concerned admins who are worried they are under some kind of attack. In this case look the sub status code in the event description and you will probably see 0xC0000133 “The time at the primary domain controller is different from the time at the backup domain controller or member server by too large an amount”. No security issue here – just a time sync problem on the initiating computer or the domain controller.
Dealing with the quantity and variety of events you encounter can be overwhelming but here’s a strategy that will keep you on track and prevent you from wasting too much time on noise events.
First, identify what you know to be noise events – like the examples described above. Configure your log management / SIEM solution to suppress or filter those events out from any alerts you receive or reports that you review on a regular basis. Make sure you document your justification for filtering those events – that is, why they are considered noise or unimportant.
Next set up alerts and reports for events you 1) know to exist and 2) consider important enough to generate an alert or show up in a report you review every day. There may be other events that don’t deserve any kind of response but which you want to keep around for compliance purposes. If you aren’t already archiving entire logs – noise and all - make sure that your log management process results in these boring but necessary events being archived.
After those steps the only events left over are events you don’t already know about and thus have not classified as noise, important or “boring but necessary”. Whatever your log management processes and technology there should be a way to view any such “unclassified” events. Periodically reviewing these events will prompt revisions to your criteria for the classification types described above with the eventual goal of no unclassified events.
This strategy ensures you don’t indefinitely miss unknown but important events and provides a systematic way for managing noise. While the Windows security log graciously logs all events from a finite set of IDs which I’ve documented at www.ultimatewindowssecurity.com/securitylog/encyclopedia.aspx, many other logs, like those from Linux and Unix, have no well-defined and bounded event schema. The strategy described in this article is even more useful with such logs where you never know exactly what’s going to be thrown your way. And I can tell you that it works because it’s one of the core concepts I use in my log management consulting projects and in my Rosetta Audit Logging Kits.
All things considered you have to get comfortable with noise events in your logs. Through audit policy refinements you may be able to reduce some of the useless events written but there’s no way to configure the noise completely out of your logs. Windows audit policy just isn’t granular or flexible enough – even with the new subcategory audit policy structure released in Windows Server 2008. The same goes for other log sources. So, identify what you want from the log and don’t get too hung up on everything else. The security log isn’t like a financial audit trail where every transaction and penny can and should be justifiable. There are some events in the security log you’ll just never be able to run to earth but don’t worry about it.