Threat Hunting Tools

Blog

Hunting where the data lives: what federated search means in practice

One question, several systems, no copy of the data.

By Threat Hunting Tools staff · · 4 min read

What does federated search mean?

In a federated model, the hunting tool sends a query to each system that holds relevant data and combines the answers. The data stays where it is. The alternative is ingestion: copy data into the tool's own store first, then search it there. Most security teams already run several data platforms: a SIEM for detection and retention, an EDR console, an identity provider, cloud provider logs and often a data lake or warehouse. A federated hunt reads from them side by side.

Vendors in this guide describe the idea in different words. Mars Security's hunting guide says: "A federated hunt reads from the SIEM alongside the EDR, identity provider, and cloud logs," and adds that "the SIEM keeps its compliance and retention jobs." Nebulock describes its Helix federated search as a way "to get data just-in-time, not just-in-case." Anvilogic's homepage describes "one query across Splunk, Snowflake, Sentinel, S3, and more, without moving the data," and Anvilogic announced general availability of its Federated Search experience in July 2026. Vega describes federated analytics that queries every source in place, with "no migration, ingestion, or egress."

Is it all or nothing?

No. Artemis Security describes a mixed model on its platform overview: "Hot-path data ingested, high-volume data queried where it lives." Its connectors page lists some SIEM sources as ingested and others, including several data lakes and warehouses, as queried in place. A mixed model trades storage for speed on the data that detections read constantly. When comparing tools, ask which sources are queried in place and which are copied, because that affects cost and how fresh the data is.

What changes for the hunter?

  • Faster start. A hunt can begin as soon as the tool has read access to a source, rather than after a pipeline is built.
  • Fewer copies. There is one retention clock per source rather than two, and less data sitting in yet another store.
  • Native queries. Each system has its own query language. The tool has to translate one hunt into several dialects. Mars Security's press release, for example, states that it writes queries in the native query language of each source.
  • Uneven data. Field names, time formats and entity identifiers differ between systems. Joining a user in identity logs to the same user on an endpoint is the hard part of any cross-source hunt.

What should you check before relying on it?

  1. Access. Which permissions does the tool need in each system? Read-only access, scoped to the data a hunt needs, is the normal expectation.
  2. Named connectors. Does the vendor name the systems it reaches? Our data source grid records which source types each vendor's public pages name: SIEM, EDR, identity provider, cloud logs, data lake or warehouse and SaaS apps. Not named on a page does not mean not supported; it means you should ask.
  3. Query cost. Queries on a warehouse or a cloud log store may be billed by the data scanned. A continuous hunt program sends many queries, so ask how the tool limits scans.
  4. Retention per source. A hunt looking back 90 days is only as good as the shortest retention among the sources it reads.
  5. Latency. Some sources answer in seconds, some in minutes. For a scheduled hunt that is fine. For an active investigation, know which sources are slow.
  6. Where results live. The query runs in place, but results, notes and evidence are stored somewhere. Find out where, and for how long.

Where does the SIEM fit?

The SIEM remains a core data platform. In a federated model it is one of the sources a hunt reads, next to the EDR, identity and cloud data, and it keeps running its own detections, retention and compliance reporting. Several tools here also deploy the detections they write back to the platforms a team already runs. Federated hunting adds a way to ask questions across systems; it does not ask a team to move its data out of any of them.

How does this show up in our scores?

Working across existing SIEM and data lakes is one of the seven criteria in the scoring method, weighted at 20%. We look for two things: whether a tool hunts across existing sources without a new ingestion pipeline, and whether the vendor names those sources publicly. Mars Security and Anvilogic score 9 on this criterion in the current edition. The full breakdown is in the ranking.

A practical first federated hunt

Pick a question that needs two sources, such as "which accounts signed in from a new country and then ran an unusual process on an endpoint within an hour?" It needs identity data and EDR data. Run it once across both, check the join between accounts and hosts, and note where the data did not line up. That small exercise shows more about a tool's federated search than a feature list will. For framing the question, see writing a hunt hypothesis.

Sources

Related

Editorial assessment · From vendor product pages, docs and announcements · Updated 2026-10-18