Introduction

Security leaders and SecOps organizations face a paradox: the more data we collect to defend our organizations, the harder it becomes to analyze that data efficiently. For CISOs, CIOs, Heads of Detection Engineering, and SOC leaders, the challenge is no longer about collecting data, it’s about using it and using it effectively. Federated Search flips the script. Rather than centralizing all security data into a legacy SIEM or home-grown data lake, Federated Search provides real-time access to distributed data sources, all without copying or moving a single byte.

Federated Search isn’t just a convenience. It’s the foundational capability that enables scalable, cost-effective Federated Analytics, allowing detection engineers and the wider security organization to iterate faster and security operations to move at the speed of threat. Whether you are building a Cyber Security Mesh Architecture (CSMA) or want to build a dedicated security analytics or AI program, Federated Analytics will be an important cornerstone for that project.

In this blog you will learn about the main benefits of federated search and its use cases, about what federated analytics is, how it can improve outcomes for detection engineering, and wider use cases for federated analytics.

In traditional models, security data is centralized into SIEMs or data lakes for analysis, while data kept in source tools is manually retrieved for ad-hoc context or triage. The costs of moving and duplicating data are unsustainable at petabyte scale, especially with modern telemetry across EDR, cloud, Software-as-a-Service (SaaS), and identity platforms. Federated Search provides direct query access to these data sources, no matter where they live: Microsoft Entra ID, CrowdStrike Falcon API, Amazon S3, Microsoft Sentinel, or an on-prem Splunk instance. And so much more!

Key advantages of Federated Search include:

  • No data duplication: Queries are run against the source system in real-time, requesting only the data that is required.
  • Faster detection engineering cycles: Engineers can test, deploy, and iterate on detections without waiting on data pipelines.
  • Cost control: Avoids data movement tax, ingestion costs, and/or network transfer costs in centralized systems.
  • Access flexibility: Analysts and engineers can access just-in-time data from wherever it resides in whatever form: cloud or on-prem, structured, semi-structured, or unstructured.
  • Security aligned with architecture: Teams can retain fine-grained access controls in place in the source platforms.

Be it as part of CSMA, as a strategic measure for cost avoidance, or to empower Triage, CERT, Threat Hunting, and Detection Engineering, there are many reasons to adopt a federated search solution. However, getting answers from your data is more than just-in-time search, there are many analytics, machine learning, and/or AI use cases that can also benefit.

Federated Search as a Foundation for Federated Analytics

Federated Search serves as the foundation and normalization layer, with Federated Analytics expanding the ability to perform real-time analysis of data in distributed environments, also without bulk centralization, supporting use cases such as:

  • On-demand security investigations that span multiple tools and data domains.
  • Threat hunting across hybrid environments without duplicating logs into a centralized SIEM, especially for use cases that require complex statistical conditions.
  • Multi-source correlation between identity logs, cloud workloads, EDR detections, and any other security-relevant data.
  • Real-time enrichment with asset metadata, user context, or vulnerability posture from platforms like Microsoft Defender for Endpoint, Amazon Inspector V2, or Entra ID.

It’s not just about being able to “search”, it’s about pushing meaningful analytics to distributed systems, wherever the data is located. Whether that’s a join across a detection event and an enrichment table in Amazon Athena, or correlating CrowdStrike host telemetry with Azure AD logs, Federated Search lays the foundation. Security analytics requires access to high-fidelity, distributed data in real time. Federated Search unlocks this access by allowing analytics frameworks; whether rule-based, statistical, or machine learning-driven, to operate directly on live datasets.

Federated Analytics can support:

  • Statistical detection mechanisms: Analysts can execute aggregations, percentile-based scoring, and windowed counts across data stored in disparate backends. Furthermore, specialized statistical methods such as Z-Scoring, Haversine distance calculations, and more can be supported.
  • Anomaly detection: Unusual behavior patterns can be surfaced by running federated queries against baselines and entity-specific telemetry, without needing centralized normalization. Apply cut forests, K-Nearest Neighbors (KNN), or Sagemaker IP Insights to disparate datasets.
  • Machine Learning (ML) and Deep Neural Networks (DNN): Training and inference pipelines can tap into federated sources via SQL or API-based interfaces, enabling model accuracy improvements without expensive data relocation.
  • AI-based triage and prioritization: AI systems fed by Federated Search can enrich detections with contextual data in real-time, think correlating a suspicious process from an EDR with login anomalies from Entra ID.

The key is proximity to data. Federated Search ensures that analytics engines can work directly on the data where it lives. This can help with key outcomes such as reducing latency, preserving fidelity, and eliminating the need for duplicative ETL pipelines. This will require a change in mentality as well as someSecDataOps re-engineering to fully benefit, as you’ll be interfacing with federated search as a “data router” or “data bridge” instead of pulling features or indicators out of specific sources.

In the case of Query Federated Search specifically, you gain the additional ability of expressing all search intent and receiving all results normalized to the Open Cybersecurity Schema Format (OCSF). Having data normalized and standardized into predictable fields greatly reduces the need for multi-stage downstream security data management (SDM) or custom pipelines and improves the training and inference or simple searching of your data.

If this is your first time reading about the OCSF, or if you are coming back to it after an absence, consider reading our beginner and executive-friendly blog: Query Absolute Beginner’s Guide to OCSF. For a more detailed explanation of OCSF, see our: Definitive Guide to Open Cybersecurity Schema Framework (OCSF) Mapping blog.

Detection Engineering today is deeply constrained by centralization bottlenecks. Engineers are often dependent on ingestion pipelines that delay access to new data. Worse, testing and validating new detection logic is slowed by the time required to index, normalize, and prepare data in a centralized system.

Federated Search removes those constraints:

  • Engineers can directly query EDR telemetry in CrowdStrike or Sentinel, or data lakes in Amazon S3 or Azure Blob/Azure Data Lake Service, using a unified query layer.
  • Federated Search platforms can map disparate data models (e.g., using OCSF) to provide consistency across sources.
  • Detection rules and analytics can be authored and tested across multiple backends simultaneously, without needing to move or transform the underlying data first.

This decoupling of data and detection logic is key. Federated Search allows detection engineering to scale like software development: fast iteration, reusable logic, and platform-agnostic pipelines. While not all security analytics are detection engineering workloads, detection engineering can benefit from federated analytics workloads.

Furthermore, federated search and federated analytics decouples you from inherent gaps in capabilities of upstream systems. Be it SQL, SPL, KQL, FQL, or otherwise, every language has its own nuances and difficulties applying computational or statistical operations and aggregations. While you may not have full access to all of that with federated search, the human capital and operational expenses saved from not having to buy or build expensive SDM pipelines or detection-as-code tools will afford your team the capacity to selectively build missing pieces.

Conclusion

Federated Search Isn’t Optional. It’s Foundational. It will transform how your team works.

Federated Search is more than a way to save money on your SIEM bill (though it does that, too). It’s the foundation for a scalable, modern SecDataOps strategy. It gives your detection engineers velocity, your SOC visibility, and your leadership confidence in operational agility.

Whether you’re building a detection pipeline across cloud workloads, correlating data between Microsoft and CrowdStrike, or enabling your SOC to search real-time events without delay, Federated Search (and Federated Analytics as an extension) is the capability that makes it all possible.

If Federated Analytics is a capability you require for your SecOps, SecDataOps, Detection Engineering, or CSMA efforts, reach out to the Query team for a demo of our platform and to engage with our team. We’ve helped solution use cases with customers of all sizes from Fortune 500 educational institutions to investment firms to fintechs in the SMB space.

Stay Dangerous