Is “SIEM-less” really what it sounds like?

A SIEM is a multipurpose tool. It brings together cyber and physical security use cases; drives threat detection, investigation, and response (TDIR); serves as a system of record for governance, regulatory, and compliance needs; and supports observability use cases tied to resilience and service degradation. The list goes on.

In short, a SIEM is what an organization wants it to be. Therein lies both its strengths and its weaknesses.

The SIEM paradox

A SIEM can be a powerful “single pane of glass.” But that strength comes with two persistent challenges: operational complexity and data-ingestion costs.

Does more data mean better outcomes?

SIEMs store vast amounts of data. As the attack surface expands, organizations keep adding sources. Yet not all data serve the same purpose:

• Detection and prevention require one set of data.
• Investigations need contextual data to explain what happened.
• Audit and compliance depend on evidence retained for reporting and review.

Because teams cannot always predict what they will need in the future, the default is often to ingest everything “just in case.” That is where the problems begin to compound.

Complexity comes first

The first symptoms are operational. Teams must determine which data is useful, why it matters, and how it should be applied in a particular context. Then they must be able to find it, search it, report on it, and turn it into something actionable when the moment comes.

Then comes the bill

Once the operational burden is established, the financial impact follows, often in the form of escalating ingestion costs.

How the SIEM became the center of the SOC

Over time, the SIEM also subsumed technologies that had once stood alone such as threat intelligence platforms, user and entity behavior analytics (UEBA), and security orchestration, automation, and response (SOAR). Each addition promised better context, stronger detection, or a tighter response loop.

Very quickly, the SOC was built around the SIEM, and the SIEM became fossilized in SOC processes and vendors took advantage of the “lock in”. Enter the era of SIEM deconstruction, and with it, the promised benefits of going “SIEM-less.”

Deconstructing the SIEM

Ingestion-based pricing crushing you with costs? Not to worry. Add a smart ingestion pipeline that filters out what you do not need before you store it. While you are at it, run detections in the pipeline. Et voilà, you have reduced storage costs and gained detections along the way.

Need to search the data in place? Add another component that can search across sources by translating queries for each one. Need to triage and investigate all those “detections” to determine what is worth chasing? Add an agentic SOC that promises to automate it all away.

Pretty soon, the collection starts to sound a lot like security information and event management, a SIEM. The difference is that the costs are now spread across individual components. It starts to look like unbundled pricing, where savings in one place create compute costs, or compromises, somewhere else.

The real cost driver: Compute

It is important not to confuse data-ingestion costs with storage costs. Processing data for upstream use cases requires compute; deciding how much data to retain, and for how long, requires storage. Even at today’s storage prices, compute costs dwarf storage costs.

Compute is the real cost driver. It is consumed when data is filtered, indexed for faster retrieval, queried, or used to generate reports. More compute is required when data must be rehydrated, moved from cold storage back into hot storage for analysis. Any or all of these costs can ultimately be passed on to the buyer.

A deconstructed architecture does not eliminate the underlying tasks or the ‘jobs to be done’. They still exist; they are simply carried out differently than they would be in a traditional SIEM.

Is SIEM-less a bad idea?

Actually, no. It can be the right call for an organization with the expertise and resources to build and maintain such a system. These new approaches are reshaping the economics and forcing traditional vendors to rethink their go-to-market strategies.

But a SIEM is ultimately a set of capabilities assembled into an architecture. Over time, every vendor offering one piece of the SIEM-less story will add adjacent capabilities until the resulting offering starts to look like, you guessed it, a SIEM.

Organizations that need a SIEM, therefore, face a practical choice: take the DIY route or invest in a fully integrated system with the right economics. At the end of the day, that choice matters.

So, where does XDR fit into all of this? More on that in my next blog.