As a security administrator, you may be inclined to focus on the Windows Security log within Windows Event Log.
You might even go as far as filtering for specific event IDs, such as EventID 4625 (failed logon request), while forgetting there is much more to security logging on Windows than this single log source.
The consequence of this narrow field of view is that you are not benefitting from the valuable information that other Event IDs used for security audit policies can offer.
On Windows there are so many other sources of security-related events such as:
-
Other event IDs on the same channel
-
Events from other channels
-
Sysmon events
-
Events from ETW Providers
-
Files
-
Windows Event Forwarding (WEF)
One of the biggest challenges with security logging on Windows is that the log sources containing security events are spread across multiple channels and not always available in the same format. Although these security events often follow a schema, data normalization across all log sources would require additional processing. Also, the security events contained in Windows Event Log pertain only to the local machine collecting them. All these challenges combined create a nightmare for security administrators who need to provide an aggregate of all security-related Windows events from all monitored Windows systems within a business unit or the entire enterprise.
In this post, we will look at the primary sources of Windows logs related to security and how NXLog can come to the rescue with its log aggregation capabilities on Windows.
Windows log sources
Windows Event Log
The Windows Event Log API provides the foundation for the default Windows logging facility. With third-party Windows application developers as its intended audience, Microsoft explains its purpose:
The Windows Event Log API defines the schema that you use to write an instrumentation manifest. An instrumentation manifest identifies your event provider and the events that it logs. The API also includes the functions that an event consumer, such as the Event Viewer, would use to read and render the events.
The Event Viewer is a utility program for troubleshooting all sorts of Windows problems. It provides a log of application and system messages, including errors, informational messages, and warnings.
With the help of NXLog’s im_msvistalog module, you can easily monitor any channel in Windows Event Log. It looks up the available channels, including those created by event providers, and monitors events in each channel. With the im_msvistlog module’s Query and QueryXML directives you can use native XML queries to filter events by channel, event ID, etc.
Event Tracing for Windows
Event Tracing for Windows (ETW) is a kernel-level tracing facility that logs kernel, application, and other system activity events to a log file. You can configure Windows Firewall and DNS Server services to log events through Windows Event Tracing.
An event tracing session consists of three components:
-
Controllers start and stop an event tracing session and enable providers.
-
Providers provide the events and send them to a consumer.
-
Consumers consume the events and retrieve events stored in log files.
You can list Providers via logman by issuing the logman query providers command using either Command Prompt or PowerShell.
NXLog can act as a Controller and Consumer by starting the event tracing session and collecting events generated by the providers. It achieves this with maximum efficiency, without the additional overhead of writing ETW event data to temporary trace files. With the im_etw module, you won’t need any other log collection tool to satisfy your ETW log collection requirements. The NXLog agent can collect ETW data at the source, then parse, filter, and reformat the data, if required, on the fly while forwarding the log records to a SIEM or other centralized log aggregation system.
File-based logs
Windows contains different log files in various formats, namely:
-
Windows Event Log files in the EVTX file format (since Windows Vista and Windows Server 2008)
-
Historical logs in the former EVT file format
-
DNS debug logs
-
Windows DHCP Server audit logs
-
Microsoft Exchange message tracking logs
-
Microsoft IIS logs in the W3C extended log file format
-
Domain Controller promotions and installations log file named dcpromo log
-
Microsoft SQL Server error logs
-
Microsoft System Center Configuration Manager (SCCM) logs
-
Microsoft System Center Endpoint Protection (SCEP) client log files
-
Windows Firewall Advanced Security Log
NXLog can collect all the log files mentioned above and easily route them to any destination using its im_file module. You simply specify the path to the log files and the destination route. Filtering out low-value logs based on field values so that they will be dropped ensures that your disk and network resources are not wasted. You can also configure NXLog to reduce the event record size from any log source by which fields to trim or which fields can be dropped to conserve even more resources.
WEF (Windows Event Forwarding)
Windows Event Forwarding (WEF) is a service that forwards Windows Event Log events to a remote server that acts as a collector. WEF is agentless, meaning you don’t need to install any additional software to enable it. All the required technology is built into the operating system. The setup includes the Windows Event Collector (WEC) and WEF clients. A WEC functions as the server that receives events. The WEF clients collect their local events and send them to the WEC.
NXLog can collect forwarded WEF events using two methods:
-
Acting as a WEC using the im_wseventing module to receive events from WEF clients using the push method. This can also be configured on GNU/Linux systems offering versatility.
-
Collecting forwarded events from a Windows server configured as a WEC using the im_msvistalog module.
With WEF being agentless, you might be inclined to ponder over the Agent-based versus agentless log collection debate. Although NXLog supports both log collection modes, we recommend that you use the agent-based mode. Having a dedicated agent provides better security and offers more reliability. When it comes to processing massive amounts of log data, the NXLog agent doesn’t have much competition.
Conclusion
Despite the huge challenge we encounter from the myriad sources of security-related logs on Windows systems, NXLog offers a versatile and elegant solution for seamlessly aggregating them to any centralized log collection destination, be it a SIEM, database, or file server for log archival. Because it can natively communicate with ETW providers as well as the Windows Event Log API, your Windows security events can be relayed in real time to your security analytics solution. Since NXLog agents can be deployed on practically any modern operating system, it is also possible to aggregate security logs with those from macOS systems or Linux servers.
