Platform · Federated SIEM
History and now,
one question.
Intrusions leave traces across every tool at once. One question covers your SIEMs, your lake or ours, object stores and live hosts.
network_activity
| where dst_endpoint.port == 443 and time > ago(180d)
| where dst_endpoint.ip in (ioc_list)
| summarize first=min(time), n=count() by src_endpoint.hostname, store| Hostname | First | N | Store |
|---|---|---|---|
| WKS-2231 | 2026-03-14 | 41 | acme-iceberg |
| WKS-2231 | 2026-08-30 | 6 | huntbase |
| SRV-DB-04 | 2026-07-02 | 2 | acme-iceberg |
| LT-0917 | 2026-09-03 | 1 | falcon (live) |
History and now, one question
Historical logs and this morning's telemetry answer the same question. Scout writes KQL, SPL, ES|QL or SQL per source. Every row names its store.
Your lake or ours
Query the Apache Iceberg lake you already have, or ship telemetry to the Huntbase Lake (Beta). No second copy.
Normalised on arrival
Everything lands as OCSF v1.3, so a watcher written once runs against Okta, Entra and your lake alike.
02Your lake
Bring your own lake.
Point Huntbase at the lake you already have and choose the tables in scope. No second copy, no migration weekend.
- Ship what you run. Generated configs for Fluent Bit, Vector and syslog, or push OCSF events directly.
- Live next to stored. The same question returns rows from your lake, your SIEM and the host itself.
- One shape for everything. Authentication, process, network, DNS, file and more, all as OCSF v1.3.
- 1Reach the lakes3://acme-sec-lake
- 2Register catalogREST catalog · acme-iceberg
- 3Attach tables3 tables
- 4Join federationQueryable next to huntbase
| Table | OCSF class | Status |
|---|---|---|
| auth_events | authentication | In federation |
| proxy_http | http_activity | In federation |
| dns_resolver | dns_activity | In federation |
| vpc_flow_raw | network_activity | Excluded |
03In the loop
The store feeds everything else.
Watchers check against it. Scout triages from it. Hunts query it. Endpoint answers join it. Everything else compounds on top.
Open by design
OCSF v1.3
Every stored and live row lands in one shape.
KQL · SPL · ES|QL · SQL
Scout writes each source's own language, with native KQL for Sentinel and Log Analytics.
Sigma
Watchers written once run on every normalised source.
Questions
Frequently asked questions
Which data can one query cover?
One question can run across the Huntbase Lake, your own Apache Iceberg lakes, SIEMs such as Splunk, Microsoft Sentinel and Azure Log Analytics, Elastic and SigNoz, and object stores on Amazon S3 or Google Cloud Storage. Every row in the result names the store it came from.
Do I have to move my logs into Huntbase?
No. Huntbase queries data where it already lives, so there is no second copy and no migration. If you want somewhere to send new telemetry, the Huntbase Lake (Beta) stores it as OCSF.
Which query language do I write?
Whichever you prefer, or none. Scout picks the language each source speaks, such as KQL, SPL, ES|QL, SQL or Cypher, and shows you the query before it runs. Sentinel and Azure Log Analytics get native KQL.
Why normalise to OCSF?
Data in one shape means a watcher or hunt written once runs against every matching source, whether it came from your identity provider, your endpoints or your lake.
Your history.
Your live estate.
One answer.
One answer across your estate, every row traced to its store, yours to act on.
- 01Sign up
- 02Run a guided hunt on the sample workspace, no connector needed
- 03Connect your own sources when you're ready
