How IceGuard works
IceGuard lets you ingest, store, search and detect against all your security data at >10x the log and query volumes of legacy SIEMs. It's deployed in your cloud account, and your data never leaves.
Ingest everything, from anywhere
We collect logs from every security-relevant source: cloud, identity, endpoint, network, applications, SaaS and AI agents.
Bucket and queue sources such as cloud audit logs and network flows are collected by our managed collectors in each cloud region, then compressed and shipped to the primary region over a private connection. API sources such as your IdP and SaaS products are polled on a schedule. Push sources such as Webhook, OpenTelemetry and Syslog are received via managed endpoints over standard protocols.
Every event is normalized to OCSF and enriched with entity context, then written to your object store. We manage the entire pipeline.
Ingestion starts at <$0.30 per GB, and drops to <$0.10 per GB at scale, including the cloud services running in your account.
| Topic | Legacy SIEM | IceGuard |
|---|---|---|
| Cost | Exorbitant pricing ($3-6 per GB) forces you to filter, sample and route logs to cold store using a third-party pipeline. | Fair pricing (<$0.30 per GB) lets you ingest all relevant data. No third-party pipeline or cold store required. |
| Complexity | Users are responsible for managing collection, parsing, and normalization (if any). Pipelines and cold stores add operational complexity. | Fully managed collection, parsing, normalization and enrichment. Direct ingestion keeps operations simple. |
Control your data
Data is stored in object store using open formats (Iceberg and Parquet), within your own cloud account. We have no standing access to it.
There are no hot and cold tiers. Everything you retain is searchable at full speed, and you can keep it for as long as you need at object store rates. There is no extra license cost for retention.
We manage index tuning, caching, table maintenance and retention. You do not need data engineers or DBAs to operate the platform.
| Topic | Legacy SIEM | IceGuard |
|---|---|---|
| Retention | Hot data is limited. Extended retention is expensive. Cold data must be rehydrated. | Everything is hot. Data can be retained indefinitely at object store rates. |
| Ownership | Proprietary formats inside the vendor's system. You're locked in, and have no control over vendor access. | Open formats in your account. We do not have standing access. |
Search months of data in seconds
You search using IceQL, a KQL-compatible query language extended to simplify operations on deeply nested, semi-structured logs.
Every column is indexed, and the indexes are cached on each worker. When a query arrives, we check the indexes first, and only pull the data required from object store. This lets us return searches over months of data in seconds, even at petabyte scale.
Data is stored in a columnar format, so queries only need to read the columns they require. This lets us perform aggregations over long time periods quickly and efficiently.
Query capacity scales independently of storage, so the cluster can seamlessly scale to handle hundreds of complex, concurrent queries without throttling.
| Topic | Legacy SIEM | IceGuard |
|---|---|---|
| Speed | Searches slow down as data volumes grow. Aggregations are slow and inefficient. | Consistent, fast search at any scale. Aggregations are fast and efficient. |
| Concurrency | Compute is coupled with storage, and hard to scale. Complex, concurrent searches get throttled. | Compute scales out seamlessly to high volumes of complex, concurrent queries. |
Detect continuously
Stateful detections are run continuously over data as it arrives. To accomplish this without overloading the cluster, we update each stateful detection incrementally. As a result, attacks can be detected as they occur, instead of waiting for the next scheduled run of a legacy SIEM detection.
Detections are written in IceQL, and can be managed in the UI or as code. Findings are shipped to the destination of your choice, or can be investigated directly in IceGuard.
Context such as behavioral baselines or threat intelligence is easy to ingest, manage and make available to any detection.
| Topic | Legacy SIEM | IceGuard |
|---|---|---|
| Latency | Stateful detections run every 15 to 60 minutes. This delays detection and response. | Stateful detections run every 10 to 20 seconds. Complex attacks can be detected as they occur. |
| Capacity | Stateful detections consume a lot of resources, so there are hard limits on how many you can run. | Stateful detections are efficient by design, so you can run as many as you want. |
| Context | Context lives in manual lookup tables which are hard to maintain and inefficient to incorporate into detections. | Context is easy to create from underlying tables, and can be incorporated without performance impact. |
Frequently asked questions
How is IceGuard different from a legacy SIEM?
A legacy SIEM is a monolithic cluster designed before object storage, columnar formats and elastic compute existed. Data is sharded across workers with local disks, which is why it is expensive to store, slow to search and awkward to scale. Exorbitant per-GB pricing pushes you to ingest less, and scheduled searches leave detection 15 to 60 minutes behind the event. We keep the SIEM's job, cross-source visibility and near real-time detection, and rebuild the engine underneath it: data in your object store, compute that scales independently, detection that runs on the stream, and one query interface over everything you retain. We go deeper in Why are legacy SIEMs so slow and expensive?.
How is IceGuard different from a data warehouse?
A data warehouse uses many of the same infrastructure advances as IceGuard, but it was built for business analytics. Security telemetry is append-only, time-oriented and semi-structured, with sparse schemas, high-cardinality fields, large text payloads and regular schema changes, and it needs full-text search, large aggregations and continuous detection over newly arriving data. A warehouse gives you storage and SQL, and leaves you to build ingestion, normalization, entity context, log-shaped indexing, streaming detection and investigation on top. We optimize storage and search for those access patterns, and manage collection, normalization, enrichment, indexing, table maintenance, retention, and detection for you. For why stitching that together yourself tends to disappoint, read The decoupled SIEM is an oxymoron.
How is IceGuard different from a federated search engine?
Federation queries data where it lives instead of centralizing it. That works well in demos and for small sources you query occasionally, but breaks down at scale. You can't index or cache data you don't own, and vendor APIs throttle large, concurrent queries, so searches are slow and time out. Filters that can't be pushed down pull raw data across clouds on every query, and you pay for compute twice, at the source and in the federation engine. Partial failures, schema changes and debugging span systems no one fully controls. IceGuard centralizes your security data in your own object store, so we can index, cache and parallelize every search, run detection on the stream, and keep cost predictable as usage grows. We built Trino - a query engine that specializes in federation - so we know where federation works and where it breaks. Read more in Should you federate at scale?.