Threats and Countermeasures Guide: Event Log
Updated: April 28, 2011
This section of the Threats and Countermeasures Guide discusses event log settings. The event logs record events that happen on the computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information that they provide more effectively.
Windows® 7 and Windows Server® 2008 R2 have event systems that save event log files as XML files that can be reported on and managed as part of a collective reporting schema. There are several additional log providers and categories that you can monitor.
Event Viewer in Windows 7 and Windows Server 2008 R2 tracks information in a number of logs, including:
This provider contains the following event logs from the operating system:
Application Events in this Windows log are classified as error, warning, or information, depending on the severity of the event. An error is a significant problem, such as loss of data. A warning is an event that is not necessarily significant, but it might indicate a possible future problem. An information event describes the successful operation of a program, driver, or service.
Security This Windows log contains security-related events, called "audit events," which are described as successful or failed, depending on the event, such as whether a user's attempt to log on to the Windows operating system was successful.
Setup This Windows log records events that are related to installing programs and services on a computer. Computers that are configured as domain controllers display additional logs in this category.
System This Windows log records system events that are sent by the Windows operating system and Windows system services. They are classified as error, warning, or information.
Forwarded Events This Windows log records events that are forwarded to this log by other computers.
Applications and Services Logs
The Applications and Services Log is a new category of event log provider. Each application or service that is installed on the computer can have an individual log. These logs store events from a single application or service rather than events that might have system-wide impact. This category of logs includes four subtypes for which the application or service can provide events: Administrative, Operational, Analytic, and Debug logs.
Administrative Events in the Administrative channel indicate a problem and a well-defined solution that an administrator can act on. An example of an administrative event is an event that occurs when an application fails to connect to a printer. These events are well documented or they include a message that gives the reader direct instructions about what must be done to rectify the problem.
Operational Events found in the Operational channel are used for analyzing and diagnosing a problem or occurrence. They can be used to trigger tools or tasks based on the problem or occurrence. An example of an operational event is an event that occurs when a printer is added or removed from a system.
Analytic Events found in the Analytic channel aid in performance evaluations and troubleshooting. These events are published in high volume, so they should only be enabled and logged for limited amounts of time as part of a diagnostic process. They describe program operation and they may indicate problems that cannot be handled by user intervention.
Debug Events found in the Debug channel can be used by developers to troubleshoot issues with their programs.
Analytic and Debug logs are hidden and disabled by default. To use these logs, first start Event Viewer, click the View menu, and then select Show Analytic and Debug Logs. Then select the Analytic or Debug log that you want to enable, and on the Action menu, click Properties. In the Properties dialog box, select Enable logging, and click OK.
Each of these logs has attributes, such as maximum log size, access rights, and retention settings and methods, which can be defined in the appropriate Event Log section in Group Policy.
Event Log Settings
You can configure the event log settings in the following location within the Group Policy Management Console:
Computer Configuration\Administrative Templates\Windows Components\Event Log Service
Subordinate folders exist for the following event logs by default:
An identical set of policy settings is available for each event log. The Setup folder has an additional policy setting that allows logging to be turned on. The following sections describe the options and issues for configuring event log settings for better system management and security.
The event log Group Policy settings in Windows Server 2003 are still supported on Windows 7 and Windows Server 2008 R2. However, if the new Group Policy settings for the Event Log Service are also specified, they take precedence.
Maximum log size (KB)
This policy setting specifies the maximum sizes of the log file. An individual log file size can be specified for each of the Application, Security, Setup, and System event log channels. The user interfaces (UIs) of the Local Group Policy Editor and the Microsoft Management Console (MMC) Event Viewer snap-in allow you to enter values as large as 2 terabytes. If this setting is not configured, event logs have a default maximum size of 20 megabytes.
Although there is no simple equation to determine the best log size for a particular server or client computer, you can calculate a reasonable size by multiplying the average event size by the average number of events per month, assuming that you back up your logs on a monthly schedule. The average event takes up about 500 bytes within each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the average number of events that are generated each day for each type of log in your organization, you can determine a good size for each type of log file.
For example, if your file server generates a Security log of 5,000 events per day and you want to ensure that at least four weeks of data are available at all times, you should configure the log size to about 70 MB (calculated as 500 bytes * 5000 events per day * 28 days = 70,000,000 bytes). Then check the servers occasionally over the following four weeks to verify that your calculations are correct and that the logs retain enough events for your needs. Event log size and log wrapping should be defined to match the business and security requirements that you determined when you designed your organization's security plan.
If you enable this policy setting, specify a user-defined value in KBs between 1,024 and 2,147,483,647, which must be a multiple of 64. If this policy setting is disabled or not configured, the maximum size of the log file is set to the local configuration value. The local administrator can change this value by using the log’s Properties dialog box, and it defaults to 20 MBs.
If you significantly increase the number of objects to audit in your organization and if you enabled the Audit: Shut down system immediately if unable to log security audits policy setting, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer is unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits policy setting that is described in Threats and Countermeasures Guide: Security Options and increase the Security log size.
Enable sensible log-size policies for all computers in your organization so that legitimate users can be held accountable for their actions, unauthorized activity can be detected and tracked, and computer problems can be detected and diagnosed. Article 957662 in the Microsoft Knowledge Base provides guidance for the maximum size of event logs that you should configure on your server.
When event logs fill to capacity, by default the computer overwrites the oldest entries with the most recent ones. To mitigate the risk of loss of older data, you can configure the computer to automatically back up the log when it becomes full.
Ideally, all specifically monitored events should be sent to a server that uses System Center Operations Manager 2007 or a similar automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, you can gather forensic information about the attacker's activities.
This policy setting determines which user accounts have access to log files and what usage rights are granted. Individual access rights can be specified for each of the Application, Security, Setup, and System event log channels.
Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor by using Security Definition Description Language (SDDL). The following example shows the default SDDL string for the Application log:
O:BAG:SYD:(D;; 0xf0007;;;AN)(D;; 0xf0007;;;BG)(A;; 0xf0007;;;SY)(A;; 0x5;;;BA)(A;; 0x7;;;SO)(A;; 0x3;;;IU)(A;; 0x2;;;BA)(A;; 0x2;;;LS)(A;; 0x2;;;NS)
In this example, the first ACE denies Anonymous Users read, write, and clear access to the log. The sixth ACE permits Interactive Users to read and write to the log. For more information about SDDL syntax and about how to construct an SDDL string, see the MSDN topic Security Descriptor String Format.
If this policy setting is disabled or not configured for the Application or Setup logs, all authenticated users can write, read, and clear the log. If this policy setting is disabled or not configured for the Security log, only system software and administrators can read or clear the log.
Attackers who successfully log on to a computer can learn important information about the computer if they are able to view the event logs. They could then use this information to implement additional exploits.
Identify which log files are valued in your organization. The Security event log has the most restrictive default settings, but events in the Application log or Setup log may also be useful for forensic investigation. Configure the SID to match the user account that is trusted to manage and monitor those logs.
Users may not be able to access event log data for troubleshooting information.
Retain old events
This policy setting controls event log behavior when the log file reaches its maximum size. When this policy setting is enabled and a log file reaches its maximum size, new events are not written to the log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events.
Old events may or may not be retained according to the Backup log automatically when full policy setting. You should only configure this setting if you archive the log at scheduled intervals and you ensure that the maximum log size is large enough to accommodate the interval.
Retaining old events introduces a greater risk of a denial-of-service attack by filling up the event log, and it prevents critical information about an attack from being logged due to lack of space.
Configure the Retain old events policy setting for the policies of all four event logs to Not Configured. If you decide that you must retain old events logs, configure the Backup log automatically when full policy setting to mitigate the risk that is associated with this policy setting.
None. This is the default configuration.
Backup log automatically when full
This policy setting controls event log behavior when the log file reaches its maximum size, and it takes effect only if the Retain old events policy setting is enabled. If you enable this policy setting and the Retain old events policy setting is enabled, the event log file is automatically closed and renamed when it is full. A new file is then started. If you disable this policy setting and the Retain old events policy setting is enabled, new events are discarded and the old events are retained. When this policy setting is not configured and the Retain old events policy setting is enabled, new events are discarded and the old events are retained.
If you significantly increase the number of objects to audit in your organization, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer is unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits policy setting that is described in Threats and Countermeasures Guide: Security Options, and then increase the Security log size.
If you enable the Retain old events policy setting and enable and specify a Maximum log size policy setting, you should also enable the Backup log automatically when full policy setting to ensure that all valued events are recorded and retained and that there is no loss of service due to lack of storage for event logs.
Ideally, all significant events are sent to a monitoring server that uses Operations Manager 2007 or other automated monitoring tool.
Computers must have enough local storage to create a backup file or access to a network storage location to create the backup file. If the events cannot be logged because the disk is full or unavailable, the events are lost. Security events are the exception to this rule if you have enabled the Audit: Shut down system immediately if unable to log security audits policy setting, in which case the affected computer shuts down.
The following links provide additional information about event logging in Windows 7 and Windows Server 2008 R2:
For more information about SDDL, see Security Descriptor String Format.
For more information about events in Windows 7 and Windows Server 2008 R2, see Event Viewer and Resulting Internet Communication in Windows 7 and Windows Server 2008 R2.