One of the most important security-related functions in an operating system is system auditing and logging. Having audit log entries to inspect is essential in establishing accountability for individual users as well as for system administrators. Log entries are also extremely helpful in incident investigations—log entries often reveal who did what and when, helping incident response team members reconstruct events related to actual and attempted security breaches.
Recent Windows operating systems have Event Logging embodied in a number of logs, of which the System Log, Security Log, and Application Log are the most basic and essential for security. The System Log logs system-related events such as errors, warnings, and a variety of other information related to the operation of the system and network-related events. Although not specifically designed to provide security information, this log can provide important clues about what happened when denial of service and other types attacks have occurred, when a perpetrator has tried to install malicious code, and when other security-related events have transpired. Depending on the particular Event Categories that are enabled, the Security Log captures data about successful and failed logins, access to files and directories, changes in policy, privilege use, the processes that have started and stopped, and other extremely useful information. The Application Log provides information about how applications are running, including any errors that may have occurred. Double clicking on an entry in any of these three types of logs produces more detailed information, something that I have often found to be quite helpful in investigations of suspicious events. Other logs such as the Internet Explorer Log, Directory Service Log (on Domain Controllers) and DNS Server Log (on DNS servers) can also be quite useful.
Windows Event Logging has improved considerably since this type of logging first appeared in Windows NT. Explanations of some event codes have since Windows 2000 was released been available in the Event Viewer. Several Event Categories in Security Logging have since Windows XP was released been enabled by default. Windows operating systems since Windows Server 2003 list the source IP address of every logged event in the Security Log. But alas, some logging-related features that are routinely available in competing operating systems are still not available in Windows systems. Most bothersome to me is that fact that there is no built-in mechanism to transport log entries to a central server. It is possible to configure FTP or a similar protocol to push or put log entries to a server, but doing so is not inefficient compared to syslog facilities in Unix and Linux systems. It is also not very satisfactory for near real-time log entry analysis, because it is necessary to schedule FTP transfers at discrete intervals in time. In contrast, syslog continuously sends selected log data to any desired destination as soon right after each log entry is created. Real-time log data are required for event correlation purposes, however.
An alternative is to install agents such as Snare by Intersect Alliance to transport log entries as syslog output. Agents introduce a new set of problems, however, because they consume resources in already-too-fat clients. Additionally, these agents are not 100 percent accurate in the data they send, something that can easily invalidate forensics analysis efforts.
The day of having to inspect individual system log entities is long past us. We need central log data repositories and event correlation to spare us from an otherwise overwhelming and ultimately, financially costly task. To truly be useful, therefore, Windows systems need to be able to send Event Log information in near real time information to wherever analysis and correlation of them will occur, e.g., a Security Information and Event Management (SIEM) tool. Hopefully, some Windows operating system of the future will contain this important functionality.