One of the interesting differentiators emerging between SIEMs is how well they support native Windows Event Collection as opposed to requiring you to deploy agents to every system. LogRhythm has some of the best support for WEC that I've seen. In this independently developed webinar, I will show you how LogRhythm allows you to collect logs 3 different ways:
- Locally installed System Monitor (aka Agent)
- Remote collection by a System Monitor
- Pure Windows via native Windows Event Forwarding
We will compare all 3 methods with their pros and cons. In preparing for this webinar I’ve talked to the folks at LogRhythm and they provide solid support for native Windows Event Collection because of its advantages in many situations. WEC is great because it
- Is zero-touch
- No inbound connections, credentials or firewall exceptions to configure
- No agents to install, update or monitor the health of
- Less push back from system administrators
- Use of WEC can save a significant amount of network bandwidth and reduce the number of log messages generated when remotely collecting Event Logs using RPC or WMI, e.g., multiple logon and logoff messages each collection interval.
- Public Cloud Environments: For environments with ephemeral hosts that would otherwise require manual configuration in the SIEM, using a WEC remove this challenge as log sources are automatically collected. For ephemeral IaaS hosts WEC is best approach.
Some of the LogRhythm/WEC specific points we'll address include:
- Installing System Monitor on your Windows Event Collector and configuring it to consume WEC destination logs
- Log source virtualization
WEC allows you to collect different source logs into one destination log. For instance you could collect Security, Sysmon and PowerShell logs from source computers into the Forwarded Events log on your collector. Some SIEMs can't deal with this, expecting only one log source type per log. But I'll show you how to use LogRhythm's source virtualization to deal with this.
- Known Hosts feature
The ability to identify an IP address or Hostname to a single known host Entity still works with WEC, that means inbuilt content around Rules and Reports works as is
I'll also discuss Windows Event Collection, how you can filter noise events at the source and even perform additional filtering in LogRhythm to catch noise patterns that WEC's Xpath syntax can't handle.
- SIEM doesn't recognize the ForwardedEvents log
- SIEM doesn't understand that forwarded events are from many different systems 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 mis-identifies 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.
I'll finish up by showing you how my own Supercharger for Windows Event Collection technology automates and centralizes the management, implementation and monitoring of WEC including how to answer these questions
- How to manage multiple collectors?
- Is WEC really working?
- Which computers are failing to forward security logs?
- Are we missing any computers?
- Is my WEC collector overloaded?
- Dropping events?
- Unresponsive?
- Approaching capacity?
- How do I balance the load of many event sources between multiple collectors?
- How do you optimize Windows for dedicated Windows Event Collection?
- TCP connection lifecycle
- Autologger buffer settings
- WEC batching and latency
- How do you create custom destination logs to avoid overloading ForwardedEvents
Please join us for this specific and in-depth real training for free session.