So once again I’m stuck inside due to severe hay fever allergies, and so it’s time to make the first blog post of the year and talk about SIEMs. Yay!

For the uninitiated, SIEMs (Security Information & Event Management) are what Security departments use to collect data about what’s happening on systems so they (pro)-actively alert on interesting events. And despite the high criticality of such systems, every SIEM I’ve used, has sucked massively. So if you’re here to know why I’m building my own SIEM, that’s why. But let’s first dive into the sucky part.

Why SIEMs suck

This part of the blog post could literally be its own blog series. But I cannot be bothered spinning up an instance of each sucky SIEM to show you in detail.

• UI event list: They seem to be optimized to allow you to view as little as possible events in one screen as possible.
• Multi-line state-aware event parsing: Still needs to be invented in SIEMs. Try parsing a Linux auth file or an auditd file.
• Handling dynamic IPs (or multi-homed hosts): Start writing your own Asset manager, because the built-in one won’t do it for you.
• In-time asset lookup: Have dynamic IPs and want to know what asset had a certain IP at a certain point in time? Yeah, right! No, you don’t get that.
• Out-of-the-box monitoring: No, you have to build this yourself.
• Bespoke DSL: Please learn our very crappy query language.
• Out-of-the-box parsers: Only if you’re content with dogshit level event parsing.
• IPv6: Never heard of it, don’t assume our IP functions work with it.
• Ridiculously expensive: They are for what is a glorified event DB with a query scheduler on top.
• …

Crappy UI Gallery

Browse the crappy UI gallery and see how many events fit on one screen. Who wins?

These screenshots come from their own websites.

Why I’m creating my own SIEM

Besides that I don’t have the money to runlicense one, I’m pretty disappointed with SIEMs in general. In the worst case, I make a SIEM that’s equally bad but free to run. In the best case, I create a glorious piece of software that I enjoy using, fixes the above pain points, and provides me with SIEM capabilities for my own (ever-growing) infrastructure at home and in datacenters.

I’ll also be exposed to writing my own little interpreter for parsing and executing queries, writing a scheduler, making a useable UI (with my own widgets/dashboards/graph engine), making (FSM) log parsers, monitoring my own stuff, deploying on my own infra (probably containerizing), …. So lots of fun ahead!

Stay tuned for Part 1 where I’ll talk more about my own SIEM and less about other (sucky) SIEMs.