If you read Part 1 of this topic series, then you are likely wondering why there needs to be a future state of SIEMs other than the usual reason that anything must evolve/improve over time. However, it’s more dire and revolutionary than that.

SIEMs have long been the ‘go-to’ system for data collection, alerting and triage from a technology standpoint but have always been reliant on the knowledge, priorities and intellect of the individuals running the SOC for core content — detection and triage logic — that sets everything in motion. This — content — is the core value of the central part of a SOC that needs domain expertise, not just technology. Unfortunately, a bulk of resources is spent in on-boarding data, conforming to ‘data models’ (though that’s an overloaded complimentary term) and coding basic rules that generate noisy alerts. These tasks are supposed to be table stakes — a means to an end, and not the end itself. But too often SIEM implementations start and end with these necessary but not sufficient tasks. And end up burning out analysts and making downstream triage/response automation impossible.

It’s time to elevate the game to better detection, and hence, better response methods. This is not necessarily a ding on SIEM vendors; they do what they do best — ingest data, help analyze/investigate, help automate but the core detection content needs to come from subject matter and domain experts who’ve ‘been there and done that’ and not from technology vendors who are good at engineering but not necessarily good at the dynamic security landscape. Therefore, the state of a SIEM needs to change in order to strengthen the core — detection content — and therefore deliver significant productivity gains to the SOC where budgets for systems or people are not necessarily increasing commensurate to the needs.

There are three phenomena that are happening in order to compensate for the content weakness of SIEMs:

1. The lack of better detection leading to precise incidents that are truly actionable is why EDRs are implementing their own silo’ed detection/response logic at the end points, and other similar technologies are doing the same, mainly for lack of efficient and precise logic in the SIEM and sometimes for licensing cost reasons. The world is getting decentralized for convenience but at the cost of not correlating across enterprise data to get the richest of signals leading to the most precise incident alerts.
2. The problem doesn’t end there — it continues downstream to the orchestration and automation side of the SOC too. This is the reason SOAR systems’ playbooks are mostly enrichment (more contextual data) in order to better understand the alert and dismiss it as a false positive or accept it as an action-worthy incident. As a result, SOAR systems are making up for the lack of efficacy of the SIEM system, and that’s not a wise use of resources, and leads to inadequate automation. In a nutshell, other systems are making up for the lack of SIEM functionality — core detection logic that will drive better rates of predictable, repeatable and successful automation.
3. Finally, if there is no core system of record that assesses maturity factually, then it’s impossible to truly know the state of security preparedness of an enterprise. How can a CISO effectively answer the question, “what does our security coverage look like?” In order to be able to answer that correctly, there needs to be a system that dispenses detection content across enterprise priorities and frameworks such as the MITRE ATT&CK framework, and is able to generate metrics on efficacy, coverage, gaps, peer comparisons, maturity scores etc. SIEMs cannot perform all these functions — they just need to perform their core function well — that is, implement relevant, implementable, high efficacy detection logic which will come from elsewhere (discussed in the next part of this blog post series), and truly achieve a high rate of automation in the SOC.

Humans should not be chasing data and noisy alerts and triaging the basics, nor should other systems be compensating. And, neither should SOC executives be struggling to assess their level of maturity and security coverage. A SOC’s domain experts should not be making up for the lack of expert content in the SIEM rather they must be spending their time elevating and customizing it for their environments, easily, without needing to be programming experts nor threat landscape experts. There needs to be a dominant change in the SOC to bring in strong, relevant and high efficacy content to the SIEM — this meets the unsaid, implied need for productivity gains the SOC so desperately needs today.

These are the true answers to the “Why do SIEMs need a future state” question. In a nutshell, SIEMs need way better content driving detection (alerts), and that must not continue to come in a manual, ad-hoc, difficult manner from SOC teams — a Content Platform needs to drive this change. And this is the basis for the next part of this series that will discuss the "How"...