A few days back, Microsoft made big news across the cybersecurity landscape: Sentinel now has a built-in Data Lake — a supposedly lower-cost, long-term storage tier designed to help security teams keep data longer.

It’s Microsoft’s official entrance into the security data lake wars, joining a fast-moving space where Splunk, Cribl, Amazon Security Lake, Delta Lake, Apache Iceberg, and the like are fighting for the pieces of SecOps data.

Organizations have another good lake option now with Microsoft Sentinel Security Data Lake

Microsoft’s new Data Lake in Sentinel enables organizations to decouple hot analytics from cold storage. That means:

  • Security teams can retain raw telemetry longer—crucial for forensics, compliance, and threat hunting.
  • Data ingestion into the “hot” Sentinel workspace can now be reserved for high-priority, detection-driven data.
  • And you can park lower-priority logs in the cold tier, indexed or not, at lower costs.

Analysts can query data using Kusto Query Language (KQL). See its launch announcement here and learn more technical details here.

The new lake follows the trend set by AWS Security Lake and open table formats like Delta Lake and Apache Iceberg, which offer ACID-compliance, can enforce schema, and support low-cost, queryable storage.

So, on paper, we’re entering a golden age: you get more data and pay less. But that lake abundance is causing another reality…

Fragmented organizational lakes get even more real

The reality is that based upon need/use-case, organizational data continues to get collected into multiple lakes, not one single lake. For a typical organization, based upon its structure, evolution, cloud architecture and differing cloud accounts, and usage of SaaS apps, data continues to get collected across multiple edges and local lakes. For example, a typical organization will end up with these lakes:

  • Raw EDR telemetry in Falcon Data Replicator (CrowdStrike)
  • Flow logs and application telemetry in AWS Security Lake
  • Identity data in Microsoft Entra ID and Azure AD logs
  • Archived detections in Sentinel’s new cold lake
  • SIEM-native data in Splunk, LogScale, or even homegrown lakehouses

Without a unified way to query across all of them, you’re stuck either:

  • Moving data around (again)
  • Building brittle ETL pipelines
  • Teaching your analysts to use different tools and consoles and query languages, manually pivoting through them.
  • Or worse—giving up and going blind in critical parts of your environment

And that’s the paradox of the modern security data lake era: we’ve broken apart the monolith, but forgot to connect the pieces.

Query Security Data Mesh for the Lakehouse Era

Federated Search, powered by Query Security Data Mesh, solves this new class of problem.

Instead of centralizing data, Query connects to each of your data lakes where it resides, allowing analysts, responders, and detection engineers to run live searches across platforms like:

  • Microsoft Sentinel Data Lake and Azure Log Analytics
  • Amazon Security Lake and bare-bones S3 (often the dumping ground)
  • Delta Lake lakehouses (high-velocity security logs)
  • Apache Iceberg in Athena (long-term analytics at scale)
  • CrowdStrike’s Falcon APIs, LogScale, and FDR dumps
  • Splunk, Cribl Lake, Elastic, and more

The key is that no data movement is required. Query performs:

  • Automatic search translation: Write in natural search syntax and Query translates to KQL, SQL, SPL, or other native languages of the backend.
  • On-the-fly normalization: Results are returned using OCSF, the industry-standard schema built for this kind of interoperability.
  • Federated joins: You can correlate between lakes—like joining authentication events in Sentinel’s cold tier to EDR alerts in CrowdStrike FDR—in a single search.

Use Case examples where federated search is a game-changer

Here’s how Query helps in real-world SecOps workflows:

1. Cold Tier Visibility Without Rehydration

Want to search six months of firewall logs in Sentinel’s new Data Lake? Without Query, you’d likely need to rehydrate those logs into your Sentinel workspace, pay for ingestion, and wait for indexing.

With Query:

  • You run your search directly against the lake
  • Pay no ingestion tax
  • Get normalized results instantly
  • Use the same detection logic across tiers

2. Cross-Lake Investigations

Security teams often need to correlate data across domains—say, Azure AD logins, CrowdStrike lateral movement alerts, and AWS CloudTrail events.

Query enables cross-lake investigations:

  • Search by identity across Entra ID and CrowdStrike
  • Correlate cloud events across AWS Security Lake and Azure logs
  • Create alerts on composite behavior spanning tools—without needing to ingest all logs into a single SIEM

3. Accelerated Detection Engineering

Organizations have been building detection logic in products like Splunk for years. With Query, security teams can continue to use Splunk as their detection console over data decentralized across the different lakes. The benefits:

  • Keep Splunk as your security console
  • Rapidly iterate on detection-as-code logic
  • Test rules across live production data in Sentinel, AWS, and Splunk simultaneously
  • Avoid the delay of staging data into test sandboxes

4. Agentic AI

Query Cybersecurity Mesh Architecture is the connective tissue enabling not just federated search but agentic AI and analytics as well. It empowers data decentralization, without sacrificing central visibility, and enables detection and response across cloud boundaries, vendors, and formats. For more details, please visit: https://www.query.ai/product/agents/

Summary

Microsoft’s announcement isn’t just a product update, but a big signal that the security data landscape is diversifying, federating, and unbundling from centralized monoliths.

Without a strategy to unify access across lakes, you risk drowning.

Query is how you navigate this new era.

It’s the access plane for the Security Data Lake generation. Whether you’re just starting with Sentinel’s new lake or already running Iceberg tables in S3, Query ensures that your data works for you—not the other way around.Let us help you. Book a Demo