A Year-End Reflection on the SIEM and SecOps Landscape
Because who said it wouldn't become more complicated?
The TDIR (Threat Detection, Investigations, and Response) space has been somewhat schizophrenic, marked by both fragmentation and consolidation. As organizations grapple with increasing data volumes and complexity, the traditional SIEM has become a complex beast, often requiring additional tools and technologies to effectively manage and analyze security data.
On the one hand, we see a fragmentation of what is usually considered part of the SIEM domain. DPM (data pipeline management) tools are emerging as a way to control the volume and routing of security telemetry. Many organizations are no longer trying to have a single consolidated security data repository (the holy grail of the ultimate security data lake), working with separate data repositories and relying on federated search, separate security analytics, and hunting tools. We are even seeing more appetite for UEBA as a standalone tool, which was almost completely consolidated as a SIEM feature just a few years ago.
At the same time, there’s also a push for consolidation. Large vendors with broad security portfolios are selling “platforms” that include the main functions of a SIEM. Many of them are the evolution of a previous XDR push. Those vendors realized that organizations were unwilling to replace their SIEMs with tools that could deliver only a subset of their functions, so they are now trying to turn those platforms into SIEMs by adding the missing parts, usually via acquisitions.
Some of these movements are part of a reaction to the high cost of TDIR, primarily due to the large volume of data collected and stored. The ingestion-based cost model is itself a large part of the problem, which is very hard for SaaS solutions providers to address. Their main cost is processing and storing that data, so they can’t do much to avoid passing those costs to their customers. Is DPM the solution? Or should organizations try to minimize the movement and replication of data and rely more on federated search?
DPMs and Federate search solutions can alleviate some of the data volume-based cost problems, but they also bring their own challenges. There are more tools to purchase, deploy, maintain, and integrate—exactly what buyers have been saying they do not want!
Managing the skills in the SOC would also be affected. Before, you would need people who knew how to deploy, manage, and use SIEM A. Now, you need people who know SIEM S, DPM C, UEBA S, and hyper-automation tool (because some people decided the acronym SOAR is dead; really?) T. Good luck finding those extremely rare and expensive professionals out there!
So one side is pushing for knee-jerk consolidation, leaving out valuable features and flexibility and forcing vendor lock-in, while the other is disintegrating SIEM into multiple tools. This seems contradictory and, in all honesty, quite confusing.
What’s the best approach? What will we see in the next couple of years?
I believe this scenario will continue for some time. The hard truth is that making sense of it is now more difficult because the problem is also more complex. One of the main challenges is that all these technologies need people, which are expensive.
The XDR wave attempted to solve this problem by creating “dumbed down” EDR/SIEM hybrids, intending to offer something that would cover most use cases but with less complexity. However, we ended up seeing XDR being a fit for only a small number of organizations. Most of the others needed either the full version of the EDR and SIEM combination, with all its features (and associated complexity), or something that required even fewer people than XDR required.
The most promising solution to these issues should come not from off-the-shelf products but from service providers.
Just like the tools side has evolved greatly, security services have also evolved a lot. MSSPs started with low-value services inspired by typical network device management services, but in the past few years, we’ve seen the emergence of high-value services such as MDR.
Service providers can act as the glue for all these pieces and as the advisor who will determine the best combination of parts for each customer. They can isolate the customer from the complexity of all the moving parts, exposing only the part the customer wants to see.
During this past year, I have noticed a change in the security operations space. In the past, only organizations with smaller SOCs, or no SOC at all, were willing to rely on service providers for their TDIR needs. Now it is common to see organizations of all sizes, even those with quite a few people in their SOCs, relying on service providers. The way they do it varies. Some will try to offload the simple triage and response of “vanilla threats”, while others will leave the technology management side with the MSSP. There’s no single model to be adopted: Just like we’ve seen an explosion in the number of technologies available, we are also seeing more security services delivery models emerging.
The adoption of AI technologies will further accelerate this scenario. Service providers will develop their own AI agents and systems in an attempt to achieve a better human/customer ratio, with the winners being able to charge lower prices while maintaining healthy margins. With this demand, technology providers selling highly efficient AI systems to support security analysts will flourish selling to MSSPs, not necessarily to the end customer.
That’s my “most likely” scenario for the next couple of years ahead. There are also a couple of things we may see soon based on other trends I’ve been noticing:
The emergence of strong and popular “combined stacks”, powered by increasing collaboration between vendors and emerging standards, such as OCSF, and foundational building blocks, such as Snowflake or Amazon Security Lake.
New SaaS SIEM vendors running their infrastructure on-prem; wait….SaaS and on-prem? Yes. What I mean is a SIEM vendor who runs its own infrastructure instead of relying on the major cloud providers, but offering its SIEM just like the major vendors today, as SaaS. Why would they do that? Because public cloud providers are convenient and highly scalable but not necessarily cheaper. Achieving high margins in this space is hard - one of the main SIEM vendors out there went down because they had never managed to achieve a healthy margin - so anyone crazy enough to build and run everything in-house may have a shot at being able to offer SIEM with a better price than the market average.
I’d say we are in a very interesting moment in the TDIR/SIEM space. While a few years ago it was fairly easy to point out where things were moving to, it is not that clear today. But that makes it even more fun to be a part of it, right?
Happy 2025!