The Noise Was Always the Problem

I've been in security long enough to remember the wall-to-wall SOC: rows of analysts staring at screens full of alerts, hoping they didn't miss the one thing that mattered buried in all the noise. Fancy "pew-pew" maps tracking attacks (that may or may not have happened).

We were fully staffed around the clock with very smart people. Good people. And most of what we did, day in and day out, was close alerts that should have been filtered before they ever reached us.

That experience is part of why Blumira exists. When we started the company, we wanted to build a SIEM that was actually useful for the people who lived inside it every day: the IT admin at a manufacturer who's also the de facto security person, the MSP engineer supporting forty customers at once, the sysadmin who gets paged at 9pm and needs to know in the next five minutes whether this is real.

We were opinionated from the start about what we shipped detections for. The goal was to fire on the things that mattered.

Then, as we grew, something crept in that we didn't fully anticipate.

The problem with scaling

When you have a small number of customers in similar environments, tuning is manageable. You know what normal looks like. You can be opinionated about what matters.

When you have thousands of customers across every vertical, every stack, every size, normal starts to look completely different depending on where you're sitting. An EDR alert that signals a real threat in one org is benign background activity in another. Impossible travel from Munich to Columbus is a red flag in one environment and a Tuesday in another. Pass-the-hash (which in my opinion should never be a false positive) turns out to fire constantly in environments where legitimate applications use it for background authentication.

That's the reality of operating at scale in a heterogeneous world.

What it meant for our customers was noise. Noise, even low-level background noise, erodes trust. When you open a SIEM and the first ten things you see don't require action, you start moving faster. You start pattern-matching on what looks familiar. You start missing things.

I've watched it happen. I've done it myself, back when I was a sysadmin/netadmin before I moved into security. The tool that was supposed to help you starts feeling like another thing you have to manage. You stop adding log sources because you already can't keep up with what you have. You stop deploying agents because the last time you tried, your inbox got flooded.

That's the thing we had to fix.

What we built, and why we built it the way we did

There's an easy version of this story where we say "we added AI" and call it a launch, but the Kindling story is more interesting than that.

Matt, our CEO, spent months on an engine that completely rethinks when findings become something worth your attention. Kindling redefines what work we owe you when we surface information: what belongs on our side of the screen, and what should land on yours.

The thinking started from a practitioner's frustration. Why are you, a human being with limited time and a hundred other things to do, doing the work of correlating five separate findings to determine if they're related? Why are you opening five tabs, sorting by timestamp, building a mental model of an attack chain from disconnected evidence? Why are you re-learning a schema every time you investigate something?

You shouldn't have to. That's work we can do.

So that's what Kindling does. It takes your findings (still your findings, still based on the same high-fidelity detections we've always built into the product) and goes to work on them. It pulls in your historical resolutions, looks at how other customers in your industry have handled the same detection types, checks external threat intelligence and IP reputation, and considers what the user was doing before and after the alert fired and whether this pattern has appeared in your environment before.

Then it tells you what it found, in plain language, with confidence levels, with the actual evidence surfaced and summarized, with an attack timeline when there's a chain to trace.

When something is benign, you don't see it. When something matters, you get a case: a complete picture of what happened, why it matters, and what you should do.

On AI, specifically

There is LLM involvement in Kindling, for well-scoped reasons: synthesizing evidence, generating analysis, and surfacing the natural-language output that makes a case readable. That's the part that's genuinely tedious. The cross-referencing, the pattern recognition, the "here's what this all means in plain English", so you can spend your time on the parts that need a human.

Detection still belongs to the engine and the Incident Detection Engineering team. Decisions still belong to you. The foundation is still eight years of detection engineering, eight years of customer data, eight years of learning what indicates a threat versus what's just the normal chaos of a real environment. The AI sits on top of that foundation. The foundation is what makes the analysis worth reading.

Too much "AI-powered security" is just a way to generate more alerts faster. We built deliberately against that.

What's next?

Kindling is live as of May 13th, available to all customers across all packages. No additional cost. What we're launching is a different model of how a SIEM-first security operations platform should work.

The old model said, “There are all the things we detected, go figure out which ones matter.” The new model says, “We figured out which ones matter, here's what you need to know.”

That's what Kindling is. A genuine attempt to give back the time ticking away every time you respond to an alert for routine activity.

I've been wanting to build this for a long time. I'm really glad we finally did.

And, if you want to see Kindling in action, you can book a demo with us.