Most of you have thousands of Windows systems. And many of you use Splunk.
- Are you thinking of using native Windows Event Collection to improve and simplify getting those logs into Splunk with many Universal Forwarders and/or configuring them and the source computers for remote collection?
- Did you try WEC and run into problems?
- Would you like to monitor more Windows systems with Splunk but lack the budget for the increased indexing?
- Are you already using WEC and Splunk and would like to share your tips and lessons learned?
Then this webinar is for you.
Windows native Event Collection (aka WEC or WEF) is awesome for getting those security logs on to one Windows event collector with zero-touch or agent installation on those thousands of source computers. But the next step is getting those events into your SIEM or log management solution. Here are few of the issues you may run in to:
- SIEM doesn't recognize the ForwardedEvents log
- SIEM doesn't understand that forwarded events are from many different systems and/or it's failing to look at the Computer Name field in the event header
- Throughput issues with the volume of events on a Windows event collector
- SIEM misidentifies the source type of the log and parses it incorrectly
In this first of a series on integrating various SIEMs and related solutions with WEC I'm going to cover all of these points and more.
After a very brief review of setting up Windows Event Collection (for more in depth treatment, see It's Time to Unleash the Power of Native Windows Event Collection) I will show you how to configure Splunk's Universal Forwarder to ship forwarded events from your Windows collector into Splunk. Here are some of the specific issues we'll discuss:
- How to ensure forwarded security events are identical to the same events collected directly. This includes
- ensuring sourcetype is correct and that events are parsed correctly so that all the WinEventLog:Security fields are present and your existing searches, reports, alerts continue to work
- overriding the host field to use ComputerName
- Why you need to send each WEC destination log only one source log type. This means you may need to create additional destination logs but this is not as simple as you might think. We'll show you how
- Tips for handling the volume of events shipped to Splunk from WEC systems
Then we'll get into how to filter the noise from security logs before it gets indexed. No one wants to pay Splunk to index garbage or provide the hardware resources necessary to do so. You've got a number of options when it comes to noise filtering, including ways to address anxiety about filtering out events that you might later wish you had.
- I'll show you what you can filter right at the source – before the noise ever leaves the system where it's generated.
- Or go ahead and forward the full security log to your collector where you split the flow:
- Archiving the raw logs in their entirety to cheap storage
- Then filter the noise at the collector, before shipping to Splunk
I'll also identify an important limitation of WEC's Xpath filtering technology that makes it impossible to filter out a significant slice of security log noise and then show you how to address this with blacklist filters in Splunk.
LOGbinder's Supercharger for Windows Event Collection is our sponsor and you'll briefly see how Supercharger automates and centralizes the management, implementation and monitoring of Windows Event Collection.
If you use Splunk and you have Windows systems please join us for this specific and in-depth real training for free ™ session.