The Future State of SIEMs - Part 3 ("The How")

If you read Part 1, https://medium.com/@Anvilogic/the-future-state-of-siems-part-1-the-what-149056482fef, and Part 2, https://medium.com/@Anvilogic/the-future-state-of-siems-part-2-the-why-efffc64ffb6f?sk=81c7396126ab6cd0b5822408f05d51b9, of this topic series, then you are ready to learn how the revolution should happen in the SIEM and surrounding SOC stack such that relevant, high-efficacy, ready-to-deploy content will stream into the SIEM and result in highly actionable alerts leading to high rates of automation in downstream systems. This is not an evolutionary “how” rather it introduces a new paradigm that not only makes highly accurate detection content available to SOCs thereby increasing the rate of orchestration and automation but also future-proofs SOCs against the changing threat landscape as well as security architecture in that they will no longer be centrally dependent on a single SIEM.

There are several key elements in this new architecture of a Content Platform, including a content repository and frameworks but the most important is the capability to empower security experts to build necessary content (=detection logic) without needing to be tool experts or code developers. Such a flexible, code-less, UI wizard-driven content builder utilizes content objects that have gone through the frameworks and are ready to be linked together to form high efficacy scenario detections that result in fewer but more accurate, actionable alerts for SOC teams to triage.

The above architecture will be underpinned by a secure collaboration channel, which allows SOC teams to collaborate with one another, both internally within the SOC as well as externally with peers in other enterprises, optionally. Collaboration is possible at the code level, wherein actual code can be exchanged, or at the comments and best-practice levels which are more free-form text exchanges. Code-level exchanges are only possible because of the embedded standardization frameworks in this architecture.

This concise description of the next-gen SOC content platform architecture is imperative, and will split the monolithic SIEM stack such that Content will no longer be a part of the SIEM, rather it will be supplied by the framework-led, collaborative content platform which will serve all enterprise rules engines, such as a central SIEM, several micro data lakes, end-points etc., resulting in the future discussed here - https://medium.com/@Anvilogic/being-a-soc-content-platform-4ccd27c2472a. 

For more on how this will work in your SOC, sign up for our free trial at www.anvilogic.com. 

The Future State of SIEMs - Part 2 ("The Why")

If you read Part 1 of this topic series, https://medium.com/@Anvilogic/the-future-state-of-siems-part-1-the-what-149056482fef, 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. This is also described in a previous blog posting, https://medium.com/@Anvilogic/being-a-soc-content-platform-4ccd27c2472a. 

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” …