• Support
  • Forums
  • Blogs

Log Collection Best Practices


New Life Form

We are a new customer to AlienVault USM Anywhere.  Recently, we started forwarding security logs from our MS Windows Domain Controllers to sensors using NxLog.  As I'm sure many of you may already know, that was a mistake.  LOL.  Apparently, we generate millions of events per day and are quickly using up the allocated monthly subscription.  Not good.  As a temporary workaround, we initially built a few Event Filtering Rules to drop some of the higher volume events.  While that helped, the high volume of events were still being consumed and processed (dropped) by the sensors; which wasn't a good thing.  So, we quickly learned it was better to drop these events on the source; rather than send the events to the sensor where they were subsequently being dropped anyway.  Makes sense.  So, that was pretty easy.  NxLog configuration files have a pretty good syntax for letting you define what event IDs or Types to include or exclude in forwarding.

All that said, I couldn't help but wonder if anyone has published a Log Collection Best Practice document on what events or logs are generally a good idea to drop or forward for "default" SIEM analysis purposes.  When we first started down the SIEM road, we really expected to create "Use Cases" to look for specific bad activity.  Unfortunately, use cases have specific or unique event or log data requirements of their own; which seems to defeat the purpose of having a SIEM that can ingest all event or log data and look for bad activity everywhere.  When trying to decide what event or log data to ingest or not ingest, we are also trying to manage the impact to monthly storage (aka cost).

In any case, I thought I might poll the Discussion Forum to see if anyone else has started down this road or be willing to share their mistakes or success stories so new customers like us could avoid recreating the wheel.  I realize not all SIEM configurations are equal, but there must be a basic or default configuration profile worth using for starters.  Are there specific events or log data that just don't provide any value add whatsoever to SIEMs?  If so, those would be great candidates to filter or drop immediately.  Are there specific events or log data that provide high value-add to SIEMs?  If so, then I'd like to make sure we ingest those right away.  Hope that all makes sense.  Appreciate any information others are willing to share.  Thanks!


Share post:

Sign In or Register to comment.