What makes a good SIEM in 2021?
As anyone reading my blog or otherwise following me online knows, I have dedicated a lot of my efforts to a specific SIEM tool in the last two years, namely Azure Sentinel.
Coming from a background of both commercial and open source on-premise SIEM and log management tools, it has been an interesting journey for sure.
Azure Sentinel is not alone in the field, and it needs to be seen as part of a growing number of products transitioning SIEM to a new era. There is a lot of respectable competition from products that show what cloud delivered SIEM can be - Chronicle and Exabeam come to mind as examples.
So what makes a SIEM catch my attention, and what do I consider to be the core value it needs to provide today? Thats what I wanted to investigate with this blog post.
First of all, do we still have SIEMs?
Now that we have SOAR platforms and XDR, isn’t SIEM a legacy product? Or maybe so changed that it needs to be rebranded as “next-generation” or something?
Personally I still use the SIEM term and believe in the product category. I do not believe in compulsory renaming of things just because we have new features, if the provided core value of the product remains the same.
Legacy SIEM that was based on on-premise log collection and static correlation rules is mostly gone. Current SIEM products incorporate SaaS delivery models, UEBA, automation, threat intelligence, machine learning capabilities… These really have changed the face of the products.
But as long as the main job continues to be threat detection based on data from different sources, they can and should be called SIEM.
So what about SOAR and XDR?
SOAR in my personal vocabulary describes a platform used only for orchestration and automation of events in external systems. In my experience the true SOAR value is best realized in MSSP or other multi-tenancy use cases, where you need to integrate across trust boundaries to make a centralized security operations workflow possible.
If we are dealing with a single system that has automation capabilities as a feature, I skip the sometimes seen “SIEM and SOAR” combination naming and just stick with SIEM. After all, can’t Information and Event Management include automation, without the need of extra terminology?
XDR is vague to many, but my description is the following. It’s a centralized threat detection and response console for vendor-specific security tools. Usually in the scope of endpoint, cloud workload, email and collaboration protection, sometimes also including networking products.
The obvious practical example for XDR is Microsoft 365 Defender, which integrates the different Defender products to a unified experience. One of the core features of SIEM is that it should connect to pretty much anything, so there is a fundamental difference here.
What makes a good SIEM today?
Based on what we’ve discussed so far, what are the most important aspects of a SIEM at the moment? Here is my take on these, in a somewhat prioritized list of nine features.
SaaS delivery model. The product needs to be maintenance-free for the SOC team when it comes to “under-the-hood” configuration of the SIEM platform.
Scalability for both storage and performance, with no limits on how much you can store or query.
Public and private endpoints for data ingestion, with support for all imaginable protocols and formats in cloud and on-prem. Serverless integration techniques preferred.
Analytics engine that has great performance, UEBA capabilities and a good query language for both threat detection and hunting.
Threat intelligence support for all indicator types and commonly used sharing protocols. Also some way to easily maintain manual lists, not just of threat indicators but also high-risk items, VIP groups and similar.
Automation capabilities inside the system that can read, write and transform any data and talk to external interfaces. Automation has to be triggerable from any change or event.
Robust and well-documented APIs for both integrating operative tools like ticketing systems or SOAR and delivering configuration, meaning CI/CD for every change the SOC team does.
Ability to present events and incidents as timelines and stories instead of just rows of log data and pie charts.
Community-focused vendor and a decent number of people that want to participate in creating a public knowledge-base for integrations, detection engineering and automation capabilities.
There are also certain things that a good SIEM definitely should not be. The biggest one being a compliance dashboard. SIEM is for the SOC team, not for the auditors. But I prefer to think by positives here, so I will leave that as the only “SIEM anti-pattern” I mention.
Next up: what about Azure Sentinel?
What happens when we compare this list to my current SIEM tool-of-choice, Azure Sentinel? I am preparing another article as continuation piece, where I will discuss practical experiences from my past two years of building stuff with Sentinel.