I'm a Splunk administrator, not a Windows administrator, so my Windows knowledge is limited. Nonetheless, many teams can benefit from having Windows Event Log data in Splunk. What are the best practices to collect basic Event Log data from Windows endpoints?
If you're new to collecting Windows endpoint Event Log data with Splunk, then review Monitor Windows event log data in the Getting Data In Manual. This topic provides the relevant knowledge to understand the Splunk configuration details in this post.
The Monitor Windows event log data documentation explains why Windows Event Log data is a critical provider of security-relevant data. But before you turn on the flood gates to collect all Window events, recognize there are hundreds of different event codes and such an approach can prove too noisy to be effective. To filter noisy and low value event logs, we'll focus specifically on the
System channels with some specific blacklist filters.
WinEventLog data inputs to collect all Windows Event Logs. An excellent way to implement this is to Use Splunk Web to configure event log monitoring. Alternatively, those interested in Deploying and Using the Splunk Add-on for Windows may prefer to Use inputs.conf to configure event log monitoring. If you're unfamiliar with the add-on, see our related post Is it a best practice to use the Splunk Add-on for Microsoft Windows?
You'll create the following simplified configuration regardless of your implementation method. Those using Splunk Web can use the instructions already available in the documentation Use Splunk Web to configure event log monitoring. Those using the configuration file approach can copy and paste the configuration template from below into the appropriate inputs.conf file such as
[WinEventLog://Security] renderXml = true disabled = false evt_resolve_ad_obj = true blacklist1 = EventCode="4662" Message="Object Type:\s+(?!groupPolicyContainer)" blacklist2 = EventCode="566" Message="Object Type:\s+(?!groupPolicyContainer)" blacklist3 = EventCode="4688" Message="New Process Name: (?i)(?:[C-F]:\Program Files\Splunk(?:UniversalForwarder)?\bin\(?:btool|splunkd|splunk|splunk-(?:MonitorNoHandle|admon|netmon|perfmon|powershell|regmon|winevtlog|winhostinfo|winprintmon|wmi)).exe)" #index = [WinEventLog://Application] renderXml = true disabled = false #index = [WinEventLog://System] renderXml = true disabled = false #index =
A few of the settings used in the above template are specific to the WinEventLog input type. This material explains their relevance while the Use inputs.conf to configure event log monitoring documentation elaborates on these settings, as well as many others. Beyond that is a notable setting used by all input types, the
renderXmlrenders Event Log data as XML in English. The default in Splunk Enterprise is 'false' although users of the Splunk® Add-on for Windows may notice the add-on sets the value to
true. XML is more structured format than the white space delimited default raw text produced by Windows. This readability is critical given that parsing individual events is necessary while investigating a security incident. Setting
renderXml = trueis a best practice because the resulting data is always in English even if the endpoint's Window installation is not English. English event logs is a dependency for dependent apps and add-ons to parse fields and work correctly.
blacklistitems are used to filter matching Windows events at the forwarder. This is a best practice approach for filtering because it avoids load otherwise put on the network and indexers to process and discard the events. The specific items outlined in the
WinEventLog://Securityblacklist items correspond to items of low value but high volume. Filtering them out reduces the indexing and retention load. Keep in mind that these blacklist are filtering out events of the matching not just an event code but also a message string. Therefore, depending on the Windows auditing configuration, Splunk may ingest events of the same event code but with different, or unmatched, messages. See Create advanced filters with 'whitelist' and 'blacklist' to learn more about the use of blacklists.
evt_resolve_ad_objis off by default and, as a result, the events produced render with guids for object names rather than the friendly name the object would resolve to. Correlating events with guids rather than friendly names introduces more complexity regardless of the ultimate use case for that data. Enabling this setting takes a bit more work to resolve the objects but is still accepted as a worthwhile expense for this best practice. See Resolve Active Directory objects in event log files to learn more about this setting and its logic for object resolution.
indexcorresponds to the target index where the performance data is available for search. This setting is common to all input types in Splunk. Different indexes provide different retention and read access capabilities. Learn more in the Managing Indexers and Clusters of Indexers documentation. Specify input settings for
indexwithin Splunk Web or by uncommenting (removing the leading hash
indexsetting in the inputs.conf configuration file you created in this activity.
Watch the following video to see how to get data into the Windows version of Splunk Enterprise.
After the basic event data for the Windows systems is available in Splunk, check out the Splunk Security Essentials and InfoSec App for Splunk apps to put that data to good use and learn about additional configuration to support a stronger security posture.
See also this excellent searchable reference for windows event codes. Primed with 540, one of the more useless ones:
And here is a quick guide on how to sift them from the mouth of the beast itself:
Good starting point if Windows isn't your thing. As ever, work with system owners to make sure their requirements are taken into account--but start from a position of some knowledge at least. You'll waste a lot of licence quota on what is basically noise from Windows if you aren't firm with them.