Tracking Program Execution
The Detailed Tracking category gives you the ability to track each program that's being executed on the Windows system being monitored. On workstations, you can see all the applications the user starts (event ID 592) and closes (event ID 593). You can tie the two events together using the process ID found in the description of both events. You can use process tracking with logon/logoff auditing and file open/close auditing to assemble a picture of when a user logged on, which programs he or she ran, and which files he or she accessed with those programs.
New in Windows 2003: Windows 2003 adds two new events to Detailed Tracking. Event ID 601 lets you know when a new service is installed. This event is useful for monitoring for new services being installed on servers or workstations, whether legitimate or unauthorized, but be aware that this event applies only to system services and not to user applications opened from the desktop. Also, this event won't help you catch Trojan horses or backdoor programs because they don't usually install themselves as a service. The new event ID 602 informs you when a scheduled task is created; however, there's no event for when someone modifies, deletes, or attempts to execute a scheduled task. We should have the ability to audit all these events, not to mention the ability to schedule events remotely.
User Rights
To control a user's ability to perform system-level functions, such as changing the system time or shutting down the system, Windows uses user rights, or privileges. You can track the use of such rights with the Privilege Use category. For most rights, Windows logs a Privilege Use event (event ID 577 or event ID 578) when a user exercises a right. A few rights, though, are exercised so frequently that Microsoft opted not to log them each time they're used; instead, when a user holding any of these rights logs on, Windows just logs the fact that the user has the right in event ID 576.
New in Windows 2003: Win2K logs event ID 578 when someone views or dumps the Security log, but for some reason, Windows 2003 doesn't. Likewise, when someone takes ownership of a file or some other object, Windows 2003 fails to log an event (Win2K does log an event). Perhaps these bugs will be fixed in the first service pack for Windows 2003; a number of audit-related bugs were fixed in Win2K service packs.
Policy Changes
Some Policy Change events that Microsoft documentation claims are logged never appear in the Security logs that I see. Likewise, some IP Security (IPSec)-related event IDs never seem to be logged (event IDs 613, 614, and 616), although others are logged (event ID 615). The Policy Change category does, however, log other security-configuration-related changes, including changes to trust relationships, Kerberos policy, Encrypting File System (EFS), and Quality of Service (QoS).
New in Windows 2003: In Win2K, event ID 615 is in the Detailed Tracking category; in Windows 2003, it moves to the Policy Change category. This is just one example of the baffling and needless changes I've discovered while comparing Win2K and Windows 2003 events. One other interesting change: Documentation states that Windows logs event IDs 608 and 609 when a user right is assigned or revoked, respectively. However, Win2K doesn't log these events at all. Windows 2003 does log event IDs 608 and 609 for changes in user right assignments except for logon rights such as Allow logon locally and Access this computer from the network. Windows 2003 logs changes to these logon right assignments with event IDs 621 and 622 (system security access granted and revoked, respectively) rather than the documented event IDs 608 and 609. Such inexplicable and undocumented changes wreak havoc on monitoring and reporting software that filters and analyzes events based on category, event ID, or the expected position of fields in the description.
System Events
The System Event category is a catchall for miscellaneous security-related events. Windows uses events in this category to let you know when the system starts up (event ID 512) and shuts down (event ID 513) as well as when different types of security modules (e.g., logon processes and authentication packages) are loaded during the start-up process. Two particularly useful events are event ID 517, which tells you that the Security log was cleared and who cleared it, and event ID 520, which is new in Windows 2003.
New in Windows 2003: The only new System Event that I've actually seen in my testing of Windows 2003 is event ID 520, which alerts you that the system date or time was changed and includes the new and old date or time in the description.
The Security log is an incredibly powerful tool for tracking users and IT staff members and detecting intrusions, but it has its challenges as well. The better you understand its idiosyncrasies, the more you can accomplish with the Security log and the more value you will derive from any Security log–related reporting and alerting tools you might have invested in. I look forward to sharing in future articles more of what I've learned over many years of research into the Security log.
AUTHOR'S NOTE:
This article series is based on Monterey Technology Group's "Security Log Secrets" course.
End of Article
