EventSource Newsletter – March 2011
By Randy Franklin Smith
It’s the line from a song in the 70’s, but quite apt when it comes to describing the Windows security log. 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 we’ll look at some common examples and noise events in the security and discuss strategies for dealing with them.
It is important to recognize noise. First, the earlier in the log management process that noise can be discarded or ignored, the better for performance, bandwidth and storage. Second, a lot of time can be wasted investigating what appears to be suspicious events, but which are, in fact, meaningless.
One example of high volume noise events are Kerberos service ticket renewal attempts generated on domain controllers. Kerberos has two kinds of tickets – authentication tickets (also known as 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. Service tickets vouch for a user’s identity to the member computers that 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) can be useful by providing a record of the workstation and servers accessed by a user. 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 was powered up for a long time. If a user remains logged on (or a computer remains up without being rebooted) for too 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. Theoretically, malicious situations involving service ticket events could conceivably be generated, but in practice this is very unlikely, and there are no criteria that can be used to distinguish those events from all the background noise of other service ticket events.
Another example of noise that appears to be a event are the sometimes frequent occurrences of event ID 537, “Logon failure – The logon attempt failed for other reasons”, where user name is blank. Concerned admins may worry an attack is underway, but looking at the the sub status code in the event description should confirm or allay these fears: if the code is 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” (and it usually is), there is no security issue this is simply a time sync problem on the initiating computer or the domain controller.
Dealing with the quantity and variety of events can be overwhelming but several strategies can help prevent losing too much time on noise events.
First, known noise events should be identified, such as those described above. Configure the log management / SIEM solution to suppress or filter these events from any alerts that are received or reports that are reviewed on a regular basis. Document the justification for filtering those events so they are properly identified as noise or unimportant.
Next, set up alerts and reports for events that are known to exist, and are considered important enough to generate an alert or appear in the daily report. There may be other events that don’t deserve a response but which should be reviewed for compliance purposes. If entire logs aren’t already being archived, (including noise events), make sure that that the log management process records and archives these events.
Finally, the remaining events are those that are unknown, or unclassified. Whatever the log management processes and technology, there should be a way to view any such “unclassified” events. Periodically reviewing these events should prompt revisions to the criteria for the classification types described above with the eventual goal of no unclassified events. This ensures unknown but important events aren’t missed, and provides a systematic way for managing noise.
While the Windows security log records all events from a finite set of IDs 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. Even with the new subcategory audit policy structure released in Windows Server 2008, Windows audit policy is not granular or flexible enough. The is true for for other log sources.
Security logs aren’t like a financial audit trail where every transaction and penny can and should be justifiable. Get comfortable with noise events in your logs; through audit policy refinements, useless events can be reduced and real threats can be more readily identified.
About the Author
Randy Franklin Smith is an internationally recognized expert on the security and control of Windows and Active Directory security who specializes in Windows and Active Directory security. He performs security reviews for clients ranging from small, privately held firms to Fortune 500 companies, national, and international organizations.
Randy Franklin Smith began his career in information technology in the 1980s developing software for a variety of companies. During the early 1990s, he led a business process re-engineering effort for a multi-national organization and designed several mission critical, object-oriented, client/server systems. As the Internet and Windows NT took off, Randy focused on security and led his employer’s information security planning team. In 1997, he formed Monterey Technology Group, Inc where he serves as President.
You can contact Randy at firstname.lastname@example.org