SIEM Tuning Philosophy: Filtering out noise

Submitted by kgeil on Fri, 09/09/2016 - 14:44

SIEMs are under a lot of pressure  When possible, it's good to try to alleviate some of their resource demand. When an administrator gets one, they are told to just start pushing logs to it.  This is OK at first, but needs to be quickly followed up by tuning.  One of my favorite activities with Alienvault is fat head/long tail analysis.  Go to SIEM view, look at all events, and click "grouped"  The most common events should be at the top, and the least common at the bottom.  The most numerous events are the ones that might be candidates for dropping, and the least numerous are often the ones that are interesting from a security or operational perspective (why was Weatherbug installed on that one client?).  Another thing about those numerous events: There are many times in which these events indicate some kind of misconfiguration in your environment.  When you log into your SIEM with morning coffee in hand, and are greeted with 25k failed login attempts from the same IP, more often than not, someone put a device on the network, misconfigured authentication, and you, the security person, can be the hero for the ops people.  Mind you, they will still think you're calling to bother them, but on the inside, they appreciate the quick fix.  The detection of misconfigurations on your networks just adds to the ROI of your SIEM.

When you have found events which you are absolutely certain are noise, it's time to begin filtering. The order with which you should be looking to drop events, from most efficient to least efficient  is as follows:

  • Do not send the events to your SIEM.  If you can configure your logging source to not send a particular event to the SIEM, do this.   For Windows clients, configure auditing settings so that 1. You get all of the events that you need, and 2, you get nothing that you don't need. This is easier said than done, and I'll write more on this in a later post.  For network devices, this can be harder, as some may only have settings for info, warning, or debug, but modern devices often have more options.   I love the way Sonicwall does this:  If you go to Log>Settings, the Sonicwall shows event counts for each category, and a checkbox which adjusts whether you want that event to be sent via syslog.Sonicwall log adjustment

  • Drop the events as soon as they hit the SIEM.  In Alienvault, this is done through syslog filtering.  It is configured through the .conf files  files in /etc/rsyslog.d.
    My sonicwall.conf file looks like this:
    sonicwall.conf sample

    Filtering can be done right in rsyslog.conf, but having everything in rsyslog.d keeps things nice and organized.  Rsyslog is at the heart of Alienvault, and it's worth knowing a bit about it:

  • Drop events in the Alienvault GUI through policies.  This is well documented in the USM V5 User guide, available here:  There is a lot that can be done with policies, but if you're just dropping noise, it's better if you can do it before it hits the SIEM.



Subscribe to RSS