LogRhythm and Native Windows Event Forwarding: How to Do It Right, Filter the Noise and Simplify your Infrastructure

Webinar

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.