Way too many SIEM implementations are wasting money

Don’t be one of them.

Output driven filtering. Do you know what that is? Does your organization leverage it in their log collection and management? Do you think that you need all of your logs? With all the innovation at the analytics level, interest in well executed data collection has suffered. Log collection tools lack sophistication and have almost regressed in recent years, and those are the solutions that at least work.

While our broad set of Snare functionality that helps you “reduce the noise” can help you save money, I want to zero in on filtering, an output driven strategy and how the Snare Reflector makes implementation palatable for even the most log hungry incident responders.

Filtering is simple, collect some logs, and ignore others. Having an output driven strategy means zeroing in on the log data that you know how to utilize immediately and how to present it. In other words, forward the longs that serve a purpose in your SIEM on to your SIEM and simply store the rest in an easily accessed repository empowering incident response while contributing to compliance. Spamming your network and your SIEM with log data you have no current use for is a waste of time and money. This is key. Time, because you’ll eventually have to scale your solution and also the lengthy mean time to detection that results from hefty amounts of unneeded data. Money because the increase in data load can mandate new hardware, and a lot of SIEMs charge by the amount of data they take in.

So, how exactly does filtering work? You basically cut out all the data you don’t have an immediate use for. This can make incident responders nervous as you can never be 100% sure what data will be relevant in the future. What if seemingly useless logs have hidden forensic value? There are tons of log types, how can I be sure which ones I want and which I don’t? Sweat not my friend, this is a rare occasion where you can have your cake and eat it too. The Snare Reflector can not only filter the collected logs but can forward immediately pertinent logs to your SIEM while archiving the rest for any number of reasons including compliance and incident response (and forensics, of course).

Filtering in Snare is incredibly easy. What some call a “white list” and a “black list” are simply the “Include” and “Exclude” fields in Snare, simplifying both setup and future modifications.
Logs you need to strongly consider collecting or absolutely should include:

  • Application Servers
  • Databases
  • IDS
  • Firewalls
  • Antivirus
  • Routers
  • Switches
  • Domain Controllers
  • Wireless Access Points
  • Intranet Applications
  • Data Loss Prevention
  • VPN Concentrators
  • Web filters
  • Honeypots

Some examples of logs you don’t need to include:

  • Access tokens
  • Commercially sensitive, non-pertinent information
  • Application source code
  • Sensitive personal data (although pseudonymization is a work around)

That about sums it up. If you are already a Snare user you can get started on this today. If not download the free trial and try it out yourself. If you’re looking for more ways to reduce the noise, check out our post on it.

/by