Choosing the right SIEM Technology (For You!)

Arik Nachmias
Sep 2, 2018 · 6 min read

It sounds like there is a lot of re-buzz on SIEM / Analytics Technology, and I’m here (trying at least) — to make some Logics out of this mess.


As you know (or may not) — SIEM (Security Information and Event Management) has been here for years, so was Analytics and a few other Cyber(ish) Buzzwords, Nobody is re-inventing the wheel (Even those who are saying they don’t use correlations or patterns to detect needles in a haystack…I See you !).

So, A Good SIEM (first and foremost) should allow you to collect everything and Anything.

“In God we Trust , All others we monitor (V.Y)”

Remember boys and girls — if you can’t collect you cant Alert (And it’s 2018 — where CEF and other Log Standards have been alive for at least 2–3 years — and yet I Still see Vendors not supporting Log Export that well, but again — Another post)

Of course — Collection is a big word which includes :

  • Parsing and Standardization / Categorization (like Splunk’s CIM or ArcSight Categories or QRadar’s High Level / Low-Level Categories).
  • The Ability to Enrich data (pre/post), Tagging and other dirty words.
  • Aggregate the data where possible, Filter the data if you don’t need it.

So — Before Purchasing — make sure you check most/all of your Standard infrastructures is supported, Check the Vendor’s ability to support non-standard content (Database, text files, Syslog, XML’s, JSON and other places you might have nonstandard logs).

Detection Arsenal and Platform Flexability

Think of SIEM as a Big Toolset — which allows you to monitor everything/anything you can think of — as long as you have the data (References in Part 1 of my Blog post).

So, we should have at least the following ways to detect :

  • Usual Patterns (For the known known’s) — i.e., name=virus found.
  • Aggregated Patterns (i.e., this happens at least X times in Y Seconds) — but I’d stay away from Abusing Thresholds (dynamic threshold where possible).
  • Alert Suppression — pretty straightforward.
  • Statistical Modules Patterns (Moving Average, Skew, Kurtosis, and Others — the more, the merrier — will have a blog post on that).
  • Machine Learning (To a certain extent) — Although this is a topic by itself — we can start employing some Machine Learning Modules on our Data (as long as we can classify good and bad) — yea yea — I know it beats the whole “AutomationMachineLearningLetsFindCulpritInLogs” kinda Vibe — but hey — that’s reality — I think we are not still there.

A Word about “Included Out of the box Content”

It’s usually Crap, but it can get you started — Standard content is good (i.e., windows failed logins will always be windows failed logins) — but your going to spend a lot of time tuning and working your way to make everything spot on.

“Light at the end of the Tunnel”

Standard content usually uses some Categorization / Standardization — if you are new and just starting a project — I suggest you take a look on Sigma by the Talented Florian Roth — it can help you Build your correlations from the Ground up in a good NEW Flexible standardization.


I Said it once , twice , thousand times — do your home work ! , Follow this guide line when you start your comparison

The Do’s

  • Make sure the System you choose is highly versatile when it comes to New Data sources, mainly if you use External Cloud Vendors.
  • Make sure the system you choose can take advantage of Threat module which considers Roles, i.e., the ability to correlate and rank a Security threat based on the Landscape (Asset) and the Person (Actor) it occurred on — this comes to mind as Internal Threat might be introduced from “Foreign offices”, So higher emphasis on Insider threat comes to mind.
  • Make sure the system you choose could be integrated and is well opened to changes (not talking about open source) — as you will have to modify various aspects when you mature your SOC.
  • Create a Simple side by side comparison of the Best 2–3 Systems, to figure which system fits your needs the best — more on this at the end of the post.
  • Make sure the System supports various Threat Intelligence Modules and is not limited to 1–2 Sources (Usually Internal / Open source ones).
  • Make sure you understand the “Updates” given while on Support, Understand Parser updates and how many updates are there each year.
  • Make sure you understand the Pricing module (Although this shows up in Don’ts as well) — Understand what coverage you are paying for and the Support renewals, Understand the Scope of Work given by the Integrator when choosing one — And understand whether the Integrator is “Technical” only or will also assist in the SOC Buildup, If the Integrator does not — Consider taking a Consultant who will do it for you.
  • Understand system scaling, How the Technical scaling is done and does the Vendor have any working clients on an extensive scale network.
  • Check the Ability for Network Sniffing — This should earn the Vendor some extra points — as this is turning to a commodity and has value for a well mature SOC.
  • Factor out the Pricing — as most vendors will usually Adhere to “pretty much the same” Pricing module.

The Dont’s

  • Do not base the need for a system on Market statements.
  • Do not base the ranking for system ONLY on External Reviews — DO YOUR RESEARCH ! (or hire someone to do it for you) .
  • Stay away from using “In-house” Cases systems, as at the end of the day you will need to integrate the System to the ITOPS (usually via API) Ticketing system, Although having the ability to start handling Tickets in the SIEM is a useful feature for start (Stages 0–1 Toddler Mode SOC mentioned on my SOAR&Friends Post).
  • Verify Add-ons require you to pay “Extra” — Do not fall for “Almost working” or “Semi Working” Add-ons.
  • Another note — I am not saying Free add-ons are not useful, they are — I am just saying that for Premium content / Addons — you usually have to pay — as someone put mind & thought into it.
  • Do not fall for UBA Marketing just yet, The Technology is somewhat immature — and might lead to the false understanding of the “Box” you are buying does everything automagically.
  • Do not fall for “Appliance” — make sure the License you buy is a Software license — this will not limit you to specific hardware that might be “too weak” when your SIEM/SOC Grows.

Matrix

So, for your convenience — I am attaching a Summarized way I make SIEM Comparison when coming to a Client, Remember — Each and everyone is different, each company is different and has different needs, make sure you remember that — ill test you later on!

Short Matrix,YAY

Summary

Do your research , use the guidelines and factor out what is most important for you.

If you decide to do your research — decide on Scoring and do a dry test before going to a Proof of concept.

See what others implemented and how, understand the timeline and how mature they are by CMM.

Make sure you compare Apples to Apples (i.e., don’t compare SecurityOnion backed by ELK to Splunk, yea — they sound the same, but they serve a different purpose).

Please — don’t fall to Sales Persons sweet-talk — they want to sell you the product they are representing, not the product you need.

Until next time!

So long,and thanks for the fish.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade