S 4.344 Monitoring of Windows Vista, Windows 7 and Windows Server 2008 systems
Initiation responsibility: IT Security Officer, Head of IT
Implementation responsibility: Auditor, Administrator
Computer systems should be monitored to maintain system security and system integrity. This is the only way to detect possible security gaps, violations against the currently valid security policies, or even attacks by insiders and outsiders, and trigger suitable countermeasures.
The monitoring (or auditing) of Windows Vista, Windows 7 and Windows Server 2008 systems must be taken into account in the planning phase, and relevant parameters must be recorded in a monitoring concept. In order to perform monitoring under Windows Vista and Windows 7, this must first be enabled using group policies or the local settings. This applies especially to file and registry monitoring.
Microsoft Windows Vista, Windows 7 and Windows Server 2008 differentiates in the Event Viewer between "Windows logs" and "Application and Service logs".
The following events are monitored in the Windows logs:
- Application log: Contains events reported by the applications. The application developer specifies which events can be logged. This log is named as follows under Windows 7: Application.
- Security log: Contains events classified by Microsoft as security-related events. An administrator can specify what information should be logged in the configuration of the auditing policies.
- Setup log: Contains events occurring during the installation of applications. This log is named as follows under Windows 7: Installation.
- System log: Contains events reported by Microsoft Windows system components. This log is named as follows under Windows 7: System.
- Forwarded Events: "Forwarded Events" are only displayed on a Microsoft Windows Vista or Windows 7 client when there is a client explicitly configured to collect events occurring on remote computers (or remote clients). The events collected in this case are the events of the logs listed above. The remote clients must also be configured accordingly to permit access to their Event Viewers.
Creating a collecting client for central control of the event logs, similar to a Syslog server, should be considered. This function can also be taken on by Microsoft server products or tools of other manufacturers such as anti-virus software for professional use.
Application and service logs were introduced for the first time in Microsoft Windows Vista. These logs do not contain system-wide events, but store events affecting the individual applications or components instead.
The following tables offer recommendations for the display settings of events in the Event Viewer. The events generate corresponding messages in the Security log.
The headings of the following tables specify the paths to the Group Policy Objects (GPOs). They can be configured locally (local XP group policy) or in the Active Directory (see S 2.326 Planning the Windows XP, Vista and Windows 7 group policies).
Path "Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy"
| Parameter | Recommendation |
|---|---|
| Audit process tracking | Process tracking is generally unreasonable and should only be enabled for debugging purposes. |
| Audit privilege use | Failed attempts to gain access should be monitored. (Failure) |
| Audit policy change | Changes to policy settings (GPOs) are operations that are critical to security and should be monitored. (Success) |
| Audit system events | System events should be monitored. (Success) |
| Audit logon events | Logging of login events should be enabled on the local computer (e.g. the workstation computer). (Success). On domain controllers or systems with high requirement of protection, also failed events should be monitored. (Success or Failure) |
| Audit account logon events | Logging of the login attempts should be enabled. The settings should be selected analogous to the Audit logon events setting. |
| Audit account management | Changes to account settings are events that are critical to security and should be monitored. (Success or Failure) |
| Audit object access | Failed object access should only be monitored on systems with high protection requirements or for incident management. Due to the amount of events, successful object access should only be activated for a low number of important objects. |
| Audit directory service access | The directory service access should be monitored. Here, at least the logging of errors during access should be recorded. (Failure) |
There are also other monitoring settings available in Microsoft Windows Vista, Windows 7 and Windows Server 2008 in addition to the settings listed above.
The below tables state recommendations of configuration settings for the following topics:
- "User Rights Assignment for the Event Viewer",
- "Settings for the Event Log" Part 1,
- "Settings for the Event Log" Part 2, and
- "Security Options"
for monitoring of Microsoft Windows Vista, Windows 7 and Windows Server 2008 systems.
Path "Computer Configuration | Windows Settings | Security Settings | Local Policies | User Rights Assignment"
| Parameter | Recommendation |
|---|---|
| Manage auditing and security log | This right allows the following:
|
Path "Computer Configuration | Administrative Templates | Windows Components | Event Log Service |
"
| Parameter | Recommendation |
|---|---|
|
The size must be selected so that enough storage space is available for the storage method used even during times of above-average system activity. This is especially important for the security log because otherwise a gap in time can arise while monitoring the security of the system. Suggestions for the settings to be specified here can be found in S 2.326 Planning the Windows XP, Vista and Windows 7 group policies and S 4.244 Secure configuration of Windows client operating systems. However, the suggested settings must be adapted to the real conditions (and tested in test operations). |
| Retain old events | If this policy is disabled and the log file has reached its maximum size, then the entries for older events will be overwritten in the log file by the entries for new events. The information on the previous events is not available any more in this case. If this policy is enabled and the log file has reached its maximum size, then no entries for new events will be recorded in the log file. Information on new events is lost in this case. It is recommended to enable the "Retain old events" policy. If the policy "Backup log automatically when full" (see below) should be used to automatically archive log files, then the "Retain old events" policy must be enabled. |
| Backup log automatically when full | If this policy and the policy "Retain old events" are both enabled, then the log file will be automatically closed and renamed when it has reached its maximum size. This policy should be enabled. |
The settings in the following table can only be configured in the Active Directory and not using local group policies.
Path "Computer Configuration | Windows Settings | Security Settings | Local Policies | Event Log"
| Parameter | Recommendation |
|---|---|
|
You can select between the following options depending on the logging concept:
|
|
With this policy, it is possible to configure the length of time that a log file will be stored. This setting is important when the storage method is set to "Overwrite events by days" for one of these logs. The number of days configured depends on the particular system environment and must be large enough to permit backup of the log data. Furthermore, the "Maximum log size" of the logs should be set to a large enough value so that the logs are not overwritten. See also the table "Settings for the Event Log Part 1" for more information. To archive the logs, an administrator or user must possess the "Manage auditing and security log" privilege. See also the table "User Rights Assignment for the Event Viewer" for more information. |
|
The access restrictions for the Guest account should be enabled. |
Path "Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options"
| Parameter | Recommendation |
|---|---|
| Audit: Shut down system immediately if unable to log security audits | To guarantee availability, this option should be disabled. This option should only be enabled in the case of high protection requirements since verification takes priority over availability in such cases. Additional measures to ensure operations are maintained are necessary for activation. |
In the Event Viewer, it is possible to locally configure the log file size and the response when the maximum size of the event log is reached individually for each type of log.
When using DirectAccess under Windows 7 and higher, logging of the connection activities of the tunnel should be created on the client (see S 5.123 Securing network communication under Windows). For this, among others, performance indicators of perfmon.exe must be queried and collector sets must be created. A secure system directory such as %systemdrive% \perflogs \System \Diagnostics should be used as storage location. The optimal size of the log files should be adapted to the current conditions of the IT system by applying regular verification. The connection information should be reproducible for at least one week in order to be able to identify malfunctions and possible attack patterns.
In the Event Viewer, it is possible to locally configure the log file size and the response when the maximum size of the event log is reached individually for each type of log.
In general, the following aspects also must be taken into account in the context of auditing:
- The Data Protection Officer and the personnel or supervisory board should become involved early on in the audit planning process. When monitoring, personal data is usually recorded as well so that it is possible to reliably determine which user was the source of a security violation.
- In order for the auditing components to generate log entries, auditing must be enabled using the relevant group policy settings.
- Microsoft Windows Vista, Windows 7 and Windows Server 2008 also provide the "Applications and Services Logs" logging functionality for monitoring purposes. The "Setup" and "Forwarded Events" logs have been added to the group of Windows logs already available in previous versions of Microsoft Windows. Logging can be enabled or disabled locally for all logs. Furthermore, it is possible to configure the log file size and the response when the maximum log file size is reached.
- The creation of a central collection point for log files with correspondingly automated evaluation can be achieved using products available from Microsoft or from third party manufacturers. If a tool is used for network and system management (see also M 4.2 Network and System Management), then, depending on the product, it may be possible to import the Windows log data directly into this tool. Microsoft Windows with version Vista and higher allows for calling events of other Windows systems on another Windows system with version Vista and higher.
- If a central collection point of log files is used under Windows Vista or higher versions, then Subscriptions must be configured. Before creation of Subscriptions, both the collecting computer (collector) and the source computer (source) must be configured for sending and receiving events. The events of the configured subscriptions are displayed on the collector computer under "Forwarded Events". The subscription function is a new function in Windows Vista and higher.
In a subscription, you configure which events should be collected. In a standard installation, the data of the forwarded events is transmitted via HTTP. It is also possible to transmit the data via HTTPS, and this option should be selected.
The Microsoft Windows Vista, Windows 7 and Windows Server 2008 systems must be configured so that they allow for remote access to the corresponding data. This can be accomplished with the help of the winrm tool. It ensures that the corresponding ports are opened in the Windows Firewall.
Subscriptions must be set up on the system that will be used to perform the evaluation of the logs. The subscriptions can be configured in Forwarded Events | Properties | Event Subscriptions. - Individual auditing policies can be configured in Microsoft Windows Vista and higher using group policies. The auditpol.exe tool can be used to specify settings in addition to the group policy settings to enable finer control of the audit settings.
- Monitoring can generate large amounts of data depending on the settings. In addition, intensive monitoring leads to losses in performance. In extreme cases, a system can become so overloaded that proper operation becomes impossible. For this reason, the suitable monitoring parameters must be checked in a test operation environment and modified if necessary. It must be taken into account that modifying the parameters can also have an effect on the overall auditing concept because it may become impossible to perform certain monitoring tasks after the changes. This applies especially in cases where additional products are used that place high requirements on the events recorded. Examples of such products include programs that automatically analyse the log data for behavioural anomalies to detect attacks, for example.
When auditing system functions, it is also recommended to regularly check the AD replication used to deploy configuration changes to the domain controllers in a domain. To perform such checks, you can check the AD tools as well as the ADS (Active Directory Service) log and the FRS (File Replication Service) log for error messages. An error during replication usually means that the configuration changes were not made everywhere. This means there is a danger that there may be users who have been granted unsuitable rights or too many rights.
The system time plays an important role when monitoring the system and evaluating the log data. When monitoring several systems it is especially important to synchronise the system time on all computers. The Windows Time service is responsible for synchronising the internal clocks and must not be disabled for this reason.
In an Active Directory environment, a domain controller can be used as the time service for the members of its domain. It is also possible to create a hierarchical structure for the Windows Time service.
The domain controller uses the primary domain controller (PDC) operations master or a domain controller in the parent domain as the time source. The PDC operations master uses the PDC operations master of the parent domain as its time source. The PDC of the master domain is the authorised time source. A domain controller can be configured using the command
net time /setsntp:<time source>
so that it uses an external time source for synchronisation purposes. The time source can be located inside or outside of the organisation's network, although the use of an internal time source should be preferred. If a time source outside of the organisation's own network is used, then its trustworthiness must be ensured.
Client computers that are not members of a domain use the Microsoft Time Server time.windows.com by default. However, the net time command can be used to specify the use of a different time source.
Review questions:
- Has it been ensured that the system time is synchronised using a trustworthy time source?
- Was the monitoring concept of IT systems designed and implemented to meet the actual needs?
- Has auditing been enabled in the group policies or in the local settings?
- Were audit settings configured for important system files and registry entries?
- Are important system events logged?
- Are the log files backed up once their maximum size is reached?