The SIEM Zombie Apocalypse: Why Every SIEM Killer Becomes the Corpse

Warning: this blog is another experiment. The idea for a blog came from a real conversation I had with somebody. The content is researched, debated, refined, “hardened” by a Gemini skill I created (using Gemini 4 Argon). Then Claude Fable 5.2 performed a peer review, and tore some parts to shreds. Then rewrote them. Then Gemini 4 Carbon made fun of Claude’s dry style and restyled it. And then I very lightly edited it, and tuned a few jokes. I removed a metaphor involving a taximeter (wut?) Let me know if this sucks, and I will stop. Promise!

I met my first SIM appliance in January 2002. Roughly eighteen months later, somebody at a conference told me the category was a dead end, and possibly even dead. So began the story of “SIEM is dead.”

Since then, I have attended at least five formal industry funerals for SIEM: first when Log Management arrived around 2006, then when UEBA promised “math instead of rules” around 2014, then when XDR promised “endpoint-first nirvana” around 2020, and most recently when the Security Data Lake and Agentic AI crowds showed up holding shovels (some: pitchforks) in 2024 and 2026.

Funny thing about all those funerals: the corpse keeps eating the pallbearers! (BTW, I am a constructive cynic, not a SIEM museum curator.)

Look at the 2026 SANS SOC Survey (surveying 513 practitioners and security leaders). EDR earns the highest tool satisfaction in the SOC (not surprising), yet SIEM remains the number-one most sought-after skill in hiring, at nearly double the demand of EDR. People love complaining about their SIEM on Tuesday, try to replace it on Wednesday, and then hire two new SIEM engineers on Friday.

Why does every “SIEM killer” end up quietly rebuilding a SIEM two years into production — and occasionally dying while trying?

The short version fits on a sticker: you can fire your SIEM vendor, you can unbundle your SIEM storage, and you can ban the word “SIEM” from your architecture slides, but you cannot fire the SIEM job.

Five Funerals and the Same Six Missing Parts

Back in March 2023, in Debating SIEM in 2023, Part 2, I proposed a simple sanity check: stop arguing about the four-letter acronym and list the actual problems you solved with it. If you refuse to buy a SIEM, those problems do not politely excuse themselves from your building.

Every replacement wave starts with one genuinely superior wedge and an unspoken assumption that the other five parts of security operations are trivial plumbing!

Here is The “Accidental SIEM Gravity Well”: what happens between Day 1 and Month 18 of every “SIEM-less” revolution (the four most recent are shown):

None of these waves failed because their core invention was bad. They won their narrow argument, walked into the SOC, and slammed straight into the Six Irreducible Jobs of SecOps Gravity (is this cool or what?):

1. Hostile-World Ingestion & Drift Survival: Collecting from 80+ sources whose vendors change JSON schemas on Friday afternoons without telling you.
2. Semantic Normalization & Identity Resolution: Knowing that achuvaki, [email protected], and uid=2342 on an AWS role assumption are the same human, not just three strings in a column.
3. Stateful, Cross-Source Correlation: Joining ten failed IdP logins, one new MFA device registration, and a SharePoint bulk download within a 10-minute sliding window.
4. Alert Deduplication, Grouping & Queue State: Turning 47 firing rules from one intrusion into one work item with an owner, SLA timer, and status, instead of 47 Slack webhooks.
5. Local Environment Memory (“Context as Code”): Remembering that svc_backup_02 is supposed to touch every file share at 2 AM on Sundays, and who approved that exception.
6. The Tamper-Evident Time Machine: Proving to an auditor — or an incident responder nine months later — exactly what happened, with role-based access controls so junior analysts can’t read the CEO’s workstation logs where he mistyped his password.

Skip any one of those six jobs in your shiny “not SIEM” replacement, and your own teams will quietly start writing Python scripts and gluing Jira tickets together to rebuild a SIEM organically. Not organically as in “tasty and healthy,” but as microbes decomposing a dead body kinda organic … [A.C. — this joke is me, not AI, obviously]

Back-of-the-Napkin Math: The “Cheap” Data Lake Guess

Let’s test today’s favorite boardroom sacred cow: “We will dump all our logs into S3/Athena or Snowflake, write SQL queries as detections, and fire our SIEM vendor!” (I picked this fight in 2017 and again in 2022.)

At roughly $23/TB/month in S3 Standard, your CFO is already popping champagne. Painful enough for the SIEM vendor yet? Wait until you turn on detections.

Take a mid-size enterprise generating 2 TB per day of raw security telemetry (AD, Okta, EDR, VPC flow, proxy, SaaS audit logs):

• Naive Pay-Per-Scan Polling: Suppose your SOC runs 250 SQL (gasp!) correlation rules every 5 minutes (72,000 query runs per day). If your data lands as semi-structured JSON or tables partitioned by day rather than minute (or joining across a 30-minute lookback window), where each rule scans a 50 GB slice of recent multi-source logs, 72,000 queries × 0.05 TB = 3,600 TB scanned per day. At $5 per TB scanned (Amazon Athena’s baseline rate), that is $18,000 per day, or $540,000 per month just to ask “did anything bad happen in the last five minutes?” Hilarity ensues! The ghost of SIEM curses you from the great beyond.
• “Wait, Anton, Nobody Does Unpruned JSON Scans!” Fair enough! A sharp data engineer will object: “Convert everything to OCSF in Apache Parquet/Iceberg, partition by eventDay and eventHour, buffer writes with Firehose, compact small files on a schedule, and push down predicates so each rule scans 50 MB instead of 50 GB!” [Ok, fine, AI made this up, but this is plausible! — A.C.]
• Now Add Up the Engineering Bill: Congratulations, your scan bill just dropped by 99.9%, and your people and pipeline bill just arrived! To keep that running without dropping events, you now own: (a) a streaming ingestion and compaction tier; (b) OCSF mappers across 50+ messy sources where — as practitioner deployments keep rediscovering — mapping an IP to src_addr vs. proxy_addr takes security judgment, not just regex; (c) a stateful engine for sliding-window joins across partition boundaries; and (d) an alerting and case-management UI. Compliance reports? Yeah, that would be (e). Congrats, you are now a SIEM vendor yourself!

Staffing that “free” architecture reliably takes 2 to 3 dedicated security data engineers ($200,000 to $500,000+ a year in loaded comp) before you write a single detection rule or hire an analyst to read the output (agents would do it?). You haven’t killed the SIEM — you have just entered the unregulated, artisanal SIEM software business, with one customer (yourself) and zero vendor support when it breaks, or any other time frankly.

Where the “SIEM Killers” Were Actually Right

Why do ambitious CISOs and brilliant detection engineers keep trying to kill SIEM every five years? Because the monolithic 2010-era SIEM bundle need evolution, if not a revolution!

For fifteen years, traditional SIEMs tightly coupled storage, data management, and detection. Worse, per the 2025 SANS SOC Survey, 42% of SOCs dumped all incoming data into their SIEM without a retrieval plan — paying hot-index rates for debug noise and compliance wallpaper nobody ever queried. SIEM is not log management.

Still, over the years, the “SIEM killers” got three big things right [this point alone is worth the price of reading this blog — A.C.]:

1. Decoupling storage from compute became credible. (I asked in 2023 whether decoupled SIEM was brilliant or stupid before softening my stance on this). This is how several modern security platforms work in 2026, and even some legacy SIEM vendors spent the last few years replatforming onto lakehouse backends.
2. Data pipelines broke log lock-in. Putting a routing and transformation layer in front of your detection engine means switching SIEMs no longer requires re-plumbing 10K servers and 220 log source types from scratch.
3. Detection-as-Code beat click-ops. Engineering teams were right to demand Git-versioned detections, CI/CD testing, and open schemas like OCSF instead of clicking around brittle GUI wizards.

So the twist isn’t that data lakes, UEBA, XDR, or AI SOC failed. They succeeded at evolving the monolithic SIEM, and SIEM survived by eating their architecture. Calling a platform built on Iceberg + streaming correlation + OCSF + case management + AI triage “Not-a-SIEM” doesn’t prove SIEM is dead. It proves SIEM is alive!

As I wrote in The Ancient Art of SIEM: Why 2003 Problems Look So Familiar in 2026, the cost currency keeps changing (from RAID arrays to EPS to GB/day to warehouse credits and LLM tokens) while the underlying operational physics refuses to budge.

The Secret of SIEM’s Staying Power: It Owns the Messy Seams

SIEM survives because it is the only place in security forced to reconcile cross-domain state with local human reality under adversarial pressure.

In Can AI Let You Jump SOC Maturity Levels? (Spoiler: Only the Boring Half), I separated time cost from learning cost. AI and modern data lakess slash SecOps time cost — generating parsers, translating SPL to SQL, or scanning ten billion rows in three seconds. Take that win immediately.

What neither a Parquet file nor an out-of-the-box XDR sensor possesses is your security learning cost:

• Which third-party vendor VPN is allowed to touch the claims database during month-end close?
• Which subsidiary still runs a legacy AS/400 or custom billing app whose logs look like hieroglyphics?
• When an alert spans Okta, AWS, and CrowdStrike, where does a human (or agent) record why it was benign — with an owner and expiration date — as I detailed in Stop Building a 2003 SOC with AI (Part 3: Local Context)?

Sit strictly below that seam (pure object storage) and you build a data swamp; sit strictly inside one silo (pure EDR) and you go blind the moment attackers log in instead of break in. Reach across the seam to correlate state and hold local context, and — whoosh welcome back to the Accidental SIEM Gravity Well.

The Lean Team Reality

Now let’s leave Silicon Valley hyperscaler land for five minutes. Suppose you run security for smaller enterprise with four security engineers, an MDR contract, compliance auditors breathing down your neck, and a SIEM renewal bill that just jumped 30%.

When a vendor or ambitious consultant pitches “Let’s ditch our SIEM and build a SIEM-agnostic AWS/Snowflake Security Data Lake!”, run away from the “replace the SIEM” half of that sentence. In advisory conversations I have had with smaller teams attempting this exact move, homebrew SIEM projects suffer a brutal failure rate.

What actually works for a lean team is the two-tier split I first argued for in 2009 and updated in SIEM: Centralize Like You Mean It, Federate Like You Have To:

• Keep real-time detection, stateful correlation, and case triage in a commercial SIEM (or MDR-managed SIEM/XDR), shrink its hot retention window (say, from 90 days to 30), and strip out high-volume, low-signal compliance and network noise.
• Put a commercial data pipeline in front of it (this mostly works, I swear, though YMMV on exotic legacy sources) to fork raw archival logs — plus daily structured exports from your SIEM — into cheap S3 or Snowflake storage for 1-year+ compliance, retro-hunting, and future migration leverage.

Why keep both raw and SIEM-structured exports in the lake? Same reason as in 2006: store only raw logs, and pivoting from a live SIEM alert into 9-month-old lake history is painful; store only SIEM-parsed exports, and anything your old SIEM failed to parse is lost forever while locking you into its schema!

You get most of the CFO cost relief and close to none of the broken homegrown correlation engine misery.

Potentially Useful Actions Based on This

Four usable ideas here:

1. Audit your “SIEM Tax” by job, not by vendor invoice. Take your top 15 log sources and apply the Output-Driven SIEM test: which sources feed active, multi-source detections versus sitting there for annual audit comfort? Evict the compliance wallpaper instead of throwing out your correlation and case engine. (If an MDR runs your SIEM, ask at renewal which ingested feeds fired zero reviewed detections in the past 180 days, and stop paying hot-tier rates for logs their analysts never touch.)
2. Run the “Six Irreducible Jobs” checklist on every “SIEM-less” pitch. Whenever an internal architect or startup proposes replacing your SIEM with Snowflake/Iceberg, XDR, or an AI agent mesh, score them against the Six Jobs above — and demand the 24×7 computer/storage cost estimates for your intended SIEM use.
3. Unbundle your pipeline before you touch your platform. If your real pain is renewal extortion, use that vendor-neutral pipeline and 12-month S3 archive as commercial leverage. Owning routing and historical copies in your own bucket lets you swap SIEMs — or renegotiate your current one — without a 14-month re-plumbing nightmare.
4. Use lakes and LLMs to kill toil. Point compute at petabyte-scale IOC sweeps and cold retro-hunts where SIEM hot tiers choke on cost. Point LLMs at writing parsers, translating detection logic, and drafting investigation summaries, while keeping deterministic engines in charge of streaming correlation, state, and gating. Do not point LLM at raw logs, unless you hate money.

So, Why Won’t SIEM Just Die Already?

Every few years, our industry confuses a clumsy product generation with an optional operational problem. Monolithic appliance SIEMs deserved to die. Blindly stuffing firewall debug garbage into premium-priced hot storage deserved to die. Swivel-chair L1 human triage is in the middle of dying right now.

What refuses to die is the messy, unglamorous center of gravity where half-broken logs from eighty vendors, stateful attacker timelines, compliance receipts, and quirky local business reality all collide at 3 AM. Call that box a Next-Gen SIEM, an Open Security Lakehouse, a Unified SecOps Platform, or “Bob.” [A.C. — which AI came with Bob?]. It is still a SIEM. And it is alive!

Related blogs:

• “I Don’t Need a SIEM, I Have Ollama!” (Yes, You Do!)

[A.C. — note to self: this is v7.5 Gemini skill using 4 Argon]

---

The SIEM Zombie Apocalypse: Why Every SIEM Killer Becomes the Corpse was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

---

Originally published at Medium.

This blog focuses on SIEM, log management, PCI DSS compliance and other information security issues. Check out more articles like this here: http://chuvakin.blogspot.com/

Source: http://chuvakin.blogspot.com/2026/11/the-siem-zombie-apocalypse-why-every.html