Credit: Dreamstime
Event logs register information about software and hardware events that occur in a system, and they are a key weapon in the arsenal of computer security teams.
Windows Server has offered Windows Event Forwarding (WEF) for aggregating system event logs from disparate systems to a central event log server for several versions now.
High end security information and event management (SIEM) or security, orchestration, automation, and response (SOAR) systems are the ideal in an enterprise environment because of their ability to not only collect and correlate log event data, but also to add context, perform deep analysis, and even to initiate incident response.
When SIEM and SOAR are not enough
There are many cases where a third-party SIEM tool may not be feasible for meeting all your event log needs. The first case is simply the cost: pricing for SIEM and SOAR tools vary wildly but are frequently based on some combination of hosts being monitored, volume of event data being ingested, user count, or even the cost of the CPU usage for your analysis.
A second potential reason for the lack of access to an enterprise event log system is security. Event log data includes details on system configuration, hostnames, usernames, and potentially even system vulnerabilities. This type of data would be incredibly useful to a malicious user in profiling your systems as a first step toward an attack, making event log data a resource worth protecting.
Reason number three why an SIEM-type solution may not be ideal is in a closed network with no internet access. There are numerous security reasons why a closed network may be necessary, and while SIEM tools are available for offline use they don’t offer nearly the same feature set as their cloud-enabled brethren.
Windows Event Forwarding
For those looking for an alternative there is Windows Event Forwarding, which uses WinRM (Windows Remote Management), the same protocol used by tools like Windows PowerShell Remoting or Windows Admin Center. Using WinRM as the underlying underpinnings for WEF has some solid benefits.
First, many modern Windows networks are already configured to enable and configure WinRM (enabling services, managing permissions, etc.). Second, WinRM traffic within a Windows domain is encrypted by default using Kerberos, making it an inherently secure option. Systems that aren’t on the same domain are a little more complex to set up but can also be secured using HTTPS and certificates.
Also worth calling out is that WEF doesn’t have to be used independently from an SIEM or SOAR solution. In fact, WEF may be a first step in collecting events to a centralised log server to streamline your overall setup, leveraging Group Policy to configure forwarding and then submit these events to your third-party logging solution from there.
Configuring event collection prerequisites
A handful of steps will ensure that your collector server is ready to receive forwarded events. Some of the requirements may already be completed (depending on several factors), but we’ll cover our bases anyway.
Step one is to ensure WinRM is enabled and configured. This involves making sure the service is started and configured with the correct startup type, creating the WinRM listener, configuring exceptions in the Windows Firewall, and setting permissions.
The most straightforward way of doing all of this on a single computer is to run the Enable-PSRemoting PowerShell cmdlet from an elevated prompt. On a Windows domain you likely want to enable WinRM on all your computers, or at minimum on all your servers, so you more than likely want to handle this using Group Policy.
To configure WinRM via Group Policy Object (GPO), perform the following steps.
To configure the WS-Management service:
- Go to Computer Configuration/Windows Settings/Security Settings/System Services/Windows Remote Management (WS-Management).
- Click Define this policy setting.
- Choose Automatic.
To open the Windows Firewall port:
- Navigate to Computer Configuration/Windows Settings/Security Settings/Windows Defender Firewall with Advanced Security.
- Create a new Inbound Rule.
- Choose Predefined and select Windows Remote Management. Click Next.
- Check the box for Domain/Private networks. Click Next.
- Accept the default value of Allow the connection. Click Finish.
To create a WinRM listener:
- Go to Computer Configuration/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service
- Configure the Allow remote server management through WinRM setting.
- Choose Enabled and use an asterisk (*) as a wildcard value in both the IPv4 and IPv6 filter fields. This will allow all hosts with permissions to use the listener.
- Click OK.
To verify WinRM is configured appropriately you can execute Invoke-Command -ComputerName [Collector Server Hostname] -ScriptBlock { $true } from a remote computer using an account with admin credentials. This command uses PowerShell remoting to connect to the remote computer and execute a very simple command.
Enabling event collection
Once WinRM is enabled you’re ready to turn on event collection. The first step is to start the Windows Event Collector service and to configure it to start automatically. You can do this using PowerShell with the command Get-Service Wecsvc | Set-Service -StartupType Automatic -PassThru | Start-Service from an administrative PowerShell prompt.
Alternatively, you can open the Event Viewer applet, and click on the Subscriptions node in the navigation menu on the left side. The Subscriptions node will bring up a dialog prompting you to enable the Windows Event Collector service and configure it for automatic start-up.
Now that WinRM and the Windows Event Collector service are configured, we can move into actually creating the mechanism that collects and stores log events.
From the Subscriptions section in the Event Viewer applet, click the Create Subscription option in the Actions menu on the right. Subscriptions will require a name and a description can also be provided.
Next, choose which Event Log on the collector server should be used to store subscription events and whether the subscription will be Collector initiated (collector server pulls from the computer with the log event) or Source computer initiated (the computer with the log events pushes events to the collector server).
You will likely want to choose Source computer initiated, in which case you will also need to provide one or more groups containing the computer accounts that will be given permission to send log events to the subscription.
The final two subscription options are a bit more complex. First is configuring an event filter that can be used to your benefit in a couple of ways: to limit the scope — and therefore control both the noise level brought on by irrelevant or unimportant events and the bandwidth and storage requirements of collecting forwarded events — and to categorise different event types into multiple subscriptions that can be used for more refined context.
Subscription filters can refine collected events by time, event level (critical, error, etc.), event log (application, security, system, forwarded events, etc.), event ID, keywords, or even specific computers or users. Note that subscription filters should be planned in coordination with the Event Log setting to route specific events to the appropriate log, whether that’s one of the usual Windows Event Logs or the Forwarded Events log.
The final options in configuring your subscription are the advanced settings, which include Event Delivery Optimization (Normal, Minimize Bandwidth, or Minimize Latency) and protocol (HTTP or HTTPS). Delivery optimisation should generally be left at the Normal setting, which pulls events in batches of five every 15 minutes.
Bandwidth-constrained environments should consider using the Minimize Bandwidth option, which slows event forwarding to once every six hours. If you require increased timeliness in your subscription, when events should be forwarded more frequently than every 15 minutes, you should leverage the Minimize Latency option, which forwards events every 30 seconds.
You may notice a Custom option under the Event Delivery Optimization options. Custom delivery optimisation cannot be managed using the Event Viewer applet, only using the wecutil command-line utility. Oddly there doesn’t seem to be a built-in PowerShell equivalent to wecutil, though there are a few third-party PowerShell wrappers for the utility.
If you have advanced PowerShell skills you can certainly craft an alternative. The wecutil command-line utility allows you to configure performance settings such as heartbeat, maximum number of items to batch, and the maximum latency for batch deliveries.
In domain environments the HTTP protocol should be entirely sufficient from a security standpoint as event forwarding traffic is encrypted using Kerberos, but for event collection in a non-domain environment you’ll likely want to enable HTTPS — note that third-party SSL certificates can and should be defined to establish certificate trust when you select computer groups in a previous step.
