SIEM Next-Genness 3.0
When I wrote SIEM Next-Gennes 2.0, I focused on re-defining the axes to evaluate architecture and features separately. This was because you can have a fully featured product that’s a sluggish nightmare to use, or a blazing one that you can’t do too much with.
I took the established SIEM vendors that I’m familiar with and placed them on the chart, but I hadn’t spent too much time looking at the newer entrants. I had tabs open with Vega, Abstract, Tuskira, Artemis Security, 7AI, and Anvilogic for ages, but they didn't really fit in my SIEM Next-Genness 2.0 evaluations, so here is 3.0 with an extended architectural scope, and some tiny adjustments to the feature axis.
Compared to my LinkedIn post, I also included Exaforce in the chart. I wasn’t really sure whether they explicitly play in the SIEM space, or could do so on customer request. Well, there’s no surprise that at the very modest figure of $125m Series B they will try to eat Splunk’s lunch even if Splunk clearly labeled their Fortune 500 sandwich when they put it in the fridge.
Because the main differences of these new SIEMs compared to the ones I evaluated earlier this year are architectural, I cannot confirm whether you get more features compared to the likes of Hunters, CrowdStrike, Palo Alto Networks, Gurucul, Elastic, or Datadog.
These new ones are different under the hood, and can also claim AI-nativeness. But they are also more dependent on customers having some data stack in place (e.g. storage, or AWS data pipeline services in place).
Achitecturally
This is a list in order of how SIEM products are deployed and designed to store and process data.
Hardware deployment - Box in closet
𝐇𝐨𝐫𝐢𝐳𝐨𝐧𝐭𝐚𝐥 𝐬𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 - More boxes in closet
Virtualized deployment - a virtual machine that can either run on a box in your closet, or as a box in somebody else’s closet (like AWS’s). If you have unused boxes in your closet, you can deploy additional virtual machines to scale your SIEM.
Containerized deployment - a container that can either run on a box in your closet that also has an operating system, or in somebody else’s box in a closet that has an operating system. Cool thing is that you can manage the containers rather flexibly with the Greek word for pilot.
𝐂𝐥𝐨𝐮𝐝 𝐧𝐚𝐭𝐢𝐯𝐞 - these solutions are built on top of hyperscaler infrastructures and may even be available in cloud marketplaces. Cloud-native products can either be deployed in your own hyperscaler environment or consumed as SaaS, where the vendor managed the environment and you just give your web UI to your security analysts.
𝐌𝐢𝐜𝐫𝐨𝐬𝐞𝐫𝐯𝐢𝐜𝐞𝐬 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 - with the risk of sparking the monolith vs microservices conundrum, this indicates “newer” SIEMs that are deployed in containers, use K8s for scaling, and run components independently of each other to help mitigate knock-on effects. Most (if not all) microservices-based SIEMs are consumed as-a-service, because otherwise the customer needs to inherit or the complexity of managing the monstrosity.
Native data pipeline management - This refers to applying filtering, normalization, routing, and correlation of data prior to ingestion/storage. It’s a way to reduce both costs and volumes. There’s a whole market on data pipelines for SIEMs (look at Cribl, DataBahn and co). Some SIEMs are starting to develop these features natively
Bring-your-own-storage and security data lakes - Customers provision their own cloud object storage (S3, Blob, GCS) as a cheaper alternative, inheriting some of the operational complexity.
Security context graph - Increasingly trendy topic, this create structured relationships between entities which can be used by agents to deterministically traverse edges between entities, identities, assets, controls, and decisions.
Federated architecture - Runs detection and search directly against data where it lives, so nothing is ingested or moved
Index-in-place - Builds searchable indexes over low-cost object storage without rehydrating data, delivering hot-search speed at cold-storage cost. Also maps heterogeneous source formats to a common schema (OCSF, ECS) at query time
Featurally
This is list in order of newer and supposedly more useful features to detect and respond to threats.
Machine Leaning - some good old pre-GenAI statistical analysis to identify deviations from the baseline.
Deterministic 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞 𝐚𝐧𝐝 𝐀𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐨𝐧 - workflows or scripts that are usually the result of a SOAR acquisition or rarely by in-house developments. This boils down to doing a bunch of API work using workflow logic. But mind you, good workflow engines are very comprehensive and most of these natively available in SIEMs are not that advanced.
𝐃𝐞𝐭𝐞𝐜𝐭𝐢𝐨𝐧-𝐚𝐬-𝐜𝐨𝐝𝐞 - allowing your engineers to write their detection rules in YAML and using SIGMA rules.
𝐒𝐞𝐥𝐟-𝐭𝐮𝐧𝐢𝐧𝐠 𝐝𝐞𝐭𝐞𝐜𝐭𝐢𝐨𝐧 - your engineers may be too busy writing their detection rules in YAML, so the tool can optimize these rules by itself based on investigation results and flagged false positives
Copilots - using LLMs to provide a natural language interface for the product. Analyst says what they want, and the copilot can spew out an SQL query or navigate the product to perform some actions. I think copilots are on the low end of LLM productivity gains.
Self-writing detection - using LLMs to write detection rules. Particularly suitable if the product supports detection-as-code.
𝐀𝐈-based response and automation - architecting LLMs with memory, retrieval, and guardrails to investigate threats, propose remediation, carrying them out, and perhaps do all that autonomously.
Reachability-based prioritization: it’s not really SIEM home turf, but these products also eat up everything else, so there would be no surprise to see these natively. They are traversable breach paths and ranks exposures by whether they are actually reachable, exploitable, and defended
Agent Intent Disambiguation - this describes the ability to tell apart dumb agents and malicious actors. Tough stuff.