Notifications
Clear all
Topic starter
14/09/2026 10:10 am
TL;DR: Federated search replaces centralizing telemetry with reusable backend queries, and TENZIR’s analysis shows how fork, merge, and fork_merge let analysts copy streams, combine historical and live evidence, or fan one request across SIEM, lake, and endpoint platforms. The governance value is less about new collection and more about reducing analyst overhead, query drift, and brittle hand-built correlation across tools.
NHIMG editorial — based on content published by TENZIR: federated search operators in TQL for SIEM, lake, and endpoint investigation
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams implement federated search across SIEM and data lake platforms?
A: Start by keeping backend-specific query logic inside reusable branches and normalizing only the fields you need for correlation.
Q: Why does federated search reduce analyst effort in distributed investigations?
A: It removes the need to retype the same indicator, field mappings, and time filters into multiple tools.
Q: What breaks when teams try to centralize telemetry before they can investigate?
A: Investigations slow down because analysts spend time copying data, aligning schemas, and building separate collection paths before they can even ask the question.
Practitioner guidance
- Standardize backend query branches Encapsulate each SIEM, lake, or endpoint search in reusable branches so analysts change the request once and preserve backend-specific syntax inside the pipeline.
- Preserve provenance in every federated result Carry backend, origin, and retrieval metadata through the combined stream so investigators can distinguish where each match came from and how it was produced.
- Separate delivery from investigation workflows Use fork for duplicate delivery to parallel sinks during migrations, and reserve fork_merge for question-driven search across multiple systems.
What's in the full article
TENZIR's full article covers the operational detail this post intentionally leaves for the source:
- Concrete TQL examples for fork, merge, and fork_merge across Splunk, S3, and Velociraptor
- Branch-by-branch field mappings for OCSF network activity records and provenance retention
- Operational guidance for adapting backend credentials, secrets, and delivery settings in each pattern
- Example pipelines for migration, historical correlation, and federated investigation workflows
👉 Read TENZIR's analysis of federated search operators for SOC investigations →
Federated search operators: what they mean for SOC teams?
Explore further
14/09/2026 10:11 am
Federated search is a control-pattern response to telemetry sprawl, not a collection architecture replacement. The article shows that analysts still need multiple backends, but they do not need to manually translate every question into three dialects. That reduces query drift and improves repeatability, which are governance concerns as much as SOC concerns. Practitioners should treat federated search as an operational control layer over distributed evidence, not a substitute for data architecture.
A question worth separating out:
Q: How do security teams decide between fork, merge, and fork_merge?
A: Use fork when you need to send the same event to another sink, merge when an independent source should contribute evidence into the main stream, and fork_merge when one request must run across several backends. The decision depends on whether you are duplicating delivery, adding sources, or collecting answers.
👉 Read our full editorial: Federated search operators reduce SIEM query duplication
