SIEM Architecture Guide: Get choice and control, without the build

The SOC has outgrown existing models

Each era of security operations has made the most of the technology available at the time. In the on-prem era, SIEM grew out of log management. The earliest SIEMs pulled logs from firewalls, servers, and domain controllers into one central system. Audit and compliance use cases were the main focus, with detections coming along for the ride. Data volumes were manageable, the perimeter was clearly defined, and centralizing everything made sense.

The cloud era changed the scale, but the model stayed the same. Cloud-native SIEMs removed the hardware and stretched capacity, yet kept the core design: ingest everything into the vendor's store, index it, then run detections.

Today, telemetry is growing 30% a year while IT budgets grow closer to 7%. AI is already accelerating growth in log volumes to widen this gap even further. Architecture that forced cost vs coverage tradeoffs at human scale completely breaks down at machine scale.

Security teams still need the outcomes that SIEM was built to deliver–visibility, detection, investigation, and response–but current architectures and pricing frameworks make the economics untenable. Most SIEMs make you centralize data before you can secure it, and they bundle three separate decisions into one: what to collect, where to store it, and what to analyze.

This guide breaks the SIEM down into its functional components, compares the architectural models used to assemble them, and outlines a new way to SIEM: a complete SIEM with open seams between pipeline, storage, and analytics. You choose what to collect, where to store it, and what to analyze, without having to build, integrate, and maintain the pieces yourself.

The anatomy of a SIEM

Strip away the branding, and every SIEM is a set of functional components working in sequence. How those components are built, connected, and priced determines what a SOC can see, how fast it can respond, and what it costs to do both. For SOC leaders, each component is a cost and coverage decision. For detection engineers, each one is a dependency. When one shifts, every detection downstream feels it.

Pipeline and ingestion

The pipeline takes telemetry from endpoint, network, identity, cloud, SaaS apps and other sources into the system for monitoring and analysis. It's also the only place you have full control over data before it lands somewhere expensive. Three functions matter most:

Tiering. Not all telemetry carries the same security value, so tiering sorts data by how it will be used. EDR, identity, and cloud logs can contain critical signals on live threats, so they're highly valuable for the SOC and need high-speed analytics for real-time detection Verbose debug output, long-tail access records, and compliance-only data are not relevant for the SOC, but still need to be kept for compliance audits. They go to archives for long-term storage. DNS, proxy, and authentication logs are somewhere in the middle: they may be relevant for the SOC when combined with other signals, making them most relevant for threat hunting, and investigation.
Routing. Once data is tiered, routing sends it to the best downstream destination for its intended use cases: high-value data goes to "hot" storage for real-time analysis. Medium-value data to "warm" storage for correlation and search, and low-value data to low-cost "cold" storage for compliance reporting. Without routing, everything defaults to the most expensive destination.
Parsing and normalization. Raw logs arrive in dozens of formats. Parsing extracts the fields, and normalization maps them to a common schema, so a username from Okta, Entra ID, and a Windows event log all mean the same thing to a detection rule.

Schema

As data flows into the SIEM, it’s normalized into a schema, the shared vocabulary that powers analysis across detections, correlations, and searches.

A key consideration is whether the SIEM’s schema is proprietary or open. With proprietary schemas, every detection and saved search is aligned to the vendor's specific way of doing things, so portability goes out the window. Open formats were introduced to overcome this limitation, specifically the Open Cybersecurity Schema Framework (OCSF): a collaborative, open source initiative that provides a standard schema for common security events, while setting versioning criteria and governance processes so the schema can evolve over time.

Storage

Storage is where security telemetry lives after ingestion and normalization. It’s also where most of the SIEM bill lives. Ideally, the way storage is structured aligns with the tiering and routing workflows discussed above:

Hot: Indexed, structured, and fast. Hot storage supports real-time detection for quick triage and response and enables the first pivots of an investigation. Usually retained for days to a few months, at the highest cost per GB.
Warm: Searchable and cheaper, with slightly slower query processing times than hot storage. In general, warm storage supports threat hunts and investigations that need to look back weeks or months.
Cold: Low-cost object storage for full-fidelity history. Retained for a year or more to meet compliance mandates and to support long-tail investigations.

Storage also shapes detection. Most SIEMs run detections after data is stored and indexed, so detection is limited by what you can afford to keep in the hot tier and how quickly it gets indexed. Run detection before storage, and that gate disappears, along with some of the latency. Where detection happens relative to storage turns out to be one of the biggest differences between architectural models, as we'll see in the next section.

Detection

Detections are the queries and logic that analyze telemetry to identify potential threats. In general there are two main types:

Single-event detections match on one event: a known-malicious hash, like a suspicious process launch, a login from an unexpected country. They're fast and simple, and ideal for activity that signals an immediate threat.
Correlation detections connect multiple events over time: a password spray, followed by a successful login, followed by a new MFA device registration and a new mailbox forwarding rule. They catch slow-burn, multistage attacks that no single event reveals, but they need stored, queryable data to work against.

Detection content comes from two places. Out-of-the-box rule templates give teams a baseline, typically mapped to frameworks like MITRE ATT&CK. Custom detections fill the gaps specific to each environment. Custom development has traditionally meant a wizard-based rule builder or hand-written queries, followed by testing, tuning, and deployment. AI copilot workflows are changing that. A detection engineer describes the behavior or the CVE, and the copilot drafts the logic, maps it to ATT&CK, and suggests how to test it, with the engineer reviewing and approving every step.

Whatever the source, an enabled rule is not the same as a working rule. Detections depend on the right telemetry arriving in the right shape, which ties detection health directly back to the pipeline and the schema.

Alerts

When detections fire, they trigger alerts that get sent to analysts and stored in a table. The quality of alerts determine how much work the analyst inherits, and how effective their response workflows can be.

A bare alert says which rule fired. An enriched alert adds context on the assets and identities involved. That enrichment can save analysts incredibly valuable time when responding to critical incident response: who owns the host and how critical it is, what role the user holds, whether the account recently changed privileges, and what threat intelligence says about the indicators. This context helps analysts piece together what happened, without opening five consoles.

Triage

Triage flows directly from alerts. It classifies and prioritizes them so analysts work on what matters first, separating true positives from noise, grouping related alerts, and deciding what to escalate, watch, or dismiss.

This simple but critical component of SIEM determines whether analysts stay fresh or get bogged down with alert fatigue. It’s also where AI generally gets its first crack at optimizing SOC workflows.

Response

Response turns findings into action that mitigates and contains the threat: isolating a host, disabling an account, blocking an indicator, or opening a case. Response can run natively within the SIEM, or through integrations with downstream SOAR, ITSM, and case management systems. Many SOCs already have mature playbooks in those tools, so the ability to plug into existing workflows can matter as much as native capability.

Search

Search powers investigation and threat hunting workflows. Analysts search to scope incidents, build timelines, and trace the attacker’s steps to quickly contain a known threat. Hunters search to test their hypotheses of theoretical attack chains for unknown but potential threats.

Two key factors shape search workflows. The query language can determine whether skills and content transfer across tools. Proprietary languages require specialized knowledge, potentially limiting who can actually run investigations, which isn’t an issue with more open, widely used languages The schema determines whether a single query can span sources, or needs a different version for each one. And an investigation is only as complete as the data search can reach, including the cold data that cost pressure pushed out of the SIEM.

Reporting

Reporting serves auditors, executives, and the SOC itself. Frameworks such as PCI DSS, ISO 27001, SOC 2, NIS2, and DORA require evidence that logs are collected, retained, and reviewed. That evidence comes from custom reports and dashboards, or from prepackaged compliance content.

Three architectural models

How the above components are assembled determines the SIEM’s cost and flexibility and also goes a long way in determining the effectiveness of the SOC more generally. There are three basic ways to assemble the components above, each with a different trade-off between integration and choice.

SIEM Architecture Guide - Monolithic SIEM

In a monolithic SIEM, every component is tightly coupled into one rigid architecture, built and controlled by one vendor. Components arrive pre-integrated, so there's minimal configuration or DIY setup before teams start getting value. One vendor, one contract, one console.

But that means it isn't flexible or extensible. You're stuck with the vendor's chosen formats, schema, query language, and workflows and limited by their feature set and roadmap. Pricing is typically tied to ingest, so cost scales as data volumes grow, forcing a tradeoff between budget and visibility. And the exit is painful by design. Leaving means migrating data, rewriting detections, retraining analysts, and rebuilding integrations.

Monolithic SIEMs have spanned two generations:

Legacy SIEMs, such as Splunk and QRadar, weld storage, detection, and search into one proprietary stack, originally built for on-prem deployment. Customers pay to ingest, index, and retain.
Cloud-native SIEMs, such as CrowdStrike Falcon Next-Gen SIEM, Microsoft Sentinel, and Google Security Operations, were built cloud-first with better scale and elasticity. But they still own the data store, and ingestion-based pricing still bites. They softened the monolith but stopped short of decoupling it.

The opposite approach skips the monolith entirely. The SOC team assembles the SIEM itself, stitching together a pipeline from one vendor, a data lake from another, a detection engine from a third, and separate tools for search, triage, and case management.

This approach offers flexibility and control, with the ability to choose the components you want, avoid single-vendor lock-in, and keep data in the storage you prefer. In theory, you get exactly the SIEM you want. In practice, you become the integrator.

Components don't arrive connected, so the result is often incomplete: response or compliance reporting is missing, or schema mapping across tools is never quite finished. The integration headaches fall on the SOC, and the ongoing maintenance and operational overhead pulls engineers away from detection and response. Multiple vendors also means multiple bills, renewals, and contracts to manage.

Eight vendors. Eight schemas. Eight contracts. And the end result still looks a lot like a SIEM, just one the SOC has to hold together itself.

Composable SIEM: choice with integration

A composable architecture takes a different path. Components live in one platform and are designed to work together, but they aren't welded together. Teams choose which pieces to adopt based on their existing infrastructure and use case requirements, and each layer exposes open seams to connect with the tools they already have.

Composability doesn’t tear the SIEM apart. Instead, it allows the team to selectively decouple the functions that benefit from separation–pipeline, storage, detection, search–so each can scale and evolve independently, without unwinding the whole system. No single vendor controls access to your data, your detections, or your workflows.

The result is the best of both worlds: the flexibility, choice, and control of the DIY approach, with the solution-ready integration of the monolith.

A new way to SIEM with Cribl Detect

Cribl Detect offers a practical, high-performance implementation of the composable SIEM model, extending Cribl's AI Platform for Telemetry into a complete security analytics solution. It integrates the core functional components of a SIEM to enable detection, investigation, response, and compliance, with an open architecture built for choice and control.

SIEM Architecture Guide - Cribl Detect Architecture

Platform-first, solution-ready

The functional layers of Cribl Detect are Cribl-native and AI-ready, but none are mandatory. The components aren't tightly coupled, so you can adopt what you need and expand as you grow. Cribl Detect is fully capable of replacing an existing SIEM but can also work alongside an existing SIEM to detect earlier and close coverage gaps.