Making the most of Windows Event Forwarding for centralized log collection

Despite the importance of centralized logging, not all enterprise environments on the Windows platform make the most of Windows Event Forwarding. It is a key part of security infrastructure and is already natively supported. With no Event Forwarding set up, administrators are left in the dark regarding what is occurring in their system logs. And even with logging set up, administrators are faced with the challenges of keeping up with a never-ending stream of system logs while trying to filter out events to analyze for potential problems, patterns, and more. Therefore, if you are given the choice of either localized logging or centralized logging using WEF, Event Forwarding is definitely better than no centralized collection at all.

Windows Event Forwarding comes out-of-the-box on Windows systems so that administrators do not need to worry about dependencies or installation of third-party software.

WEF is a subscription-based service where the event subscriber can request certain types of events to be forwarded. The WEF subscription normally includes XML event queries for selecting events. Depending on the query, the subscription can be set up to collect events for different purposes. A targeted WEF subscription involves collecting events from a set of targeted hosts which are deemed suspicious. With baseline logging, events are collected from all hosts since this subscription will enroll all devices in the organization.

The subscriber is normally a server that collects the forwarded events, and it is usually referred to as a Windows Event Collector (WEC). The collector mode is also a built-in feature in Windows.

Windows Event Forwarding provides administrators with a broad scope of how they can implement this type of logging in their network.

WEF can be configured for source-initiated (push) or subscriber-initiated (pull) mode. With the subscriber-initiated mode, the only setup required is to enable WinRM on the client machines that need to be monitored.

Before log transmission, Windows Event Forwarding converts logs into a rendered XML format. Administrators can choose to have these logs forwarded with or without localized strings attached to the message to allow for more compact transmissions. By default WEF works with pre-rendering so that the logs are fully formatted on the forwarder.

Administrators can also choose between different methods of secure transmission, such as the default option for Kerberos with a fallback option to NTLM. If the subscriber cannot be joined in the domain and Kerberos is not an option, HTTPS is also available with certificate-based authentication.

WEF only works with Windows systems and this can be problematic if you work with or find yourself migrating to hybrid server environments. Systems other than Windows cannot forward their logs to a Windows Event Collector. WEF is completely different than and incompatible with other log forwarding protocols such as syslog.

Centralized logging is still an environment to aspire to and it is completely possible to support WEF in a hybrid server environment. Since WEF is only supported by Windows, it is not possible to forward Windows Event Log via WEF to a non-Windows based server. However, the NXLog Enterprise Edition offers a solution with the im_wseventing module that allows you to set up NXLog as a Windows Event Collector and to do so even on the Linux platform. This can be compelling to users looking to centralize logs from hybrid environments since NXLog allows the collection of both WEF and syslog based logs with a single tool when an agent-based setup is not an option.

Windows Event Forwarding is based on the WS-Management standard and uses the Windows Remote Management (WinRM) service on Windows to forward events to a Windows Event Collector. WS-Management and thus WinRM are based on SOAP, which is an XML-based communication protocol. Serializing Windows Event Log into XML and shipping it via WinRM requires some resources.

If you are planning to forward Windows Event Log from systems producing a large amount of logs, it’s worth considering an agent-based setup. Some Windows servers, especially domain controllers, can generate a lot of logs. The log volume can be significant even if filtering is enabled to collect only a subset of the data, such as the Security log. Using NXLog as an agent to collect Windows Event Log with the im_msvistalog module should keep up with the volume that WEF may not be able to handle.

Some log collector solutions advertise WEC capabilities when in reality they only collect data from Forwarded Events and utilize the built-in WEC service in Windows that stores events in that location. This can be non-ideal for several reasons. First, it is Windows-only, so you need a Windows server acting as the WEC. Second, the data is first written into the Windows Event Log by the WEC service and then needs to be read out by the collector to ship it to the destination of choice. This puts the disk and CPU unnecessarily to work and is a waste of resources. The NXLog Enterprise Edition can be configured as a WEC to run natively on all supported platforms, including on Linux or even in light-weight containers. This can save a lot of resources to begin with considering the basic OS requirements of a Windows server.

Windows Event Forwarding only works with the Windows Event Log. It cannot forward events that are not stored in the Windows Event Log. Using a centralized log collection system that can recognize and parse a far greater variety of logs, including logs from custom software and other protocols, is recommended.

While the Windows Event viewer is able to show Analytic and Debug channels, this data is handled through the Windows Event Tracing (ETW) subsystem that WEF cannot deal with. Logs stored in files or in MSSQL are also out-of-reach for WEF. If you are planning to capture and forward such data, of which the Windows DNS server logs are a good example, then it is highly recommended to consider an agent-based approach.

The NXLog Enterprise Edition natively supports ETW log collection, can parse and collect a wide variety of formats from files, is able to pull data from ODBC compliant databases, and offers many other types of collection versus what WEF can provide.