AI for Enterprise Security
What is federated search in security operations?
Federated search queries each security data source in place, in its own language, and returns the results to one investigation. There is no data normalization step and no copy of your logs in a vendor cloud. Crogl reads your SIEM, EDR, identity provider, ticketing system, and data lake where the data already lives.
Works where the data lives
The Console Tour
One alert. A dozen consoles. An expert for each one.
An analyst working a single alert pivots across a dozen disconnected consoles. CrowdStrike holds the endpoint detail. Splunk holds the originating event. Okta holds identity context, Proofpoint the email vector, Cortex XSOAR the case, AWS CloudTrail the cloud activity, and Snowflake whatever the SIEM never retained.
Each tool speaks its own query language, and each one has its own in-house expert. The analyst spends more time navigating tools than applying experience, and the investigation depends on whichever expert is on shift that day. That dependency, not raw alert count, is what lengthens investigations, grows the backlog, and extends dwell time.
The usual answer is to move the data. Centralize it, normalize it into one schema, and query the copy. That works for the sources a team can afford to bring in. It also takes months of pipeline engineering, costs money per gigabyte, and leaves every source outside the pipeline outside the investigation as well.
Federated search takes the other route. The question travels to the data instead.
Two ways to answer one question
Federated search vs. data centralization
Both approaches are legitimate, and most enterprises run some of each. They differ in what they cost you and in what they leave outside the investigation.
Federated search
Query in place
- How it works
- Send the question to each source in its own language and assemble the answers into a single investigation.
- Strength
- Every connected source is in scope from day one, including the ones nobody had budget to centralize.
- What it costs
- A connector and read access for each source, and a query that runs at the pace of the slowest system it touches.
- Blind spot
- Any source with no connector or no granted access, which is why the requirements below are worth reading.
Data centralization
Centralize first
- How it works
- Copy the data into one platform and normalize it into a shared schema before an investigation can use it.
- Strength
- Fast repeated queries over the sources a team chose to bring in, with predictable performance.
- What it costs
- Pipeline engineering, storage and licence cost per gigabyte, and schema mappings that break when a source changes.
- Blind spot
- Every source that never made the cut, which is usually the long tail where the interesting evidence sits.
Crogl does not ask a team to pick one first. When a normalized core already exists, Crogl queries it like any other source and extends the investigation past what that core covers.
Which data sources can Crogl query?
The systems your investigation already depends on.
These are examples by category rather than the whole connector library. Crogl ships more than 30 out of the box, and the system your team needs may not be named here.
| Source type | Examples Crogl queries |
|---|---|
| SIEM | Splunk, Microsoft Sentinel, IBM QRadar, Google Chronicle, Sumo Logic, Elastic SIEM |
| Endpoint detection and response | CrowdStrike |
| Identity | Okta, Azure AD |
| Email security | Proofpoint, Microsoft 365, Google Workspace |
| Data lakes and warehouses | Databricks, Snowflake |
| Object storage | Amazon S3 |
| Data pipelines | Cribl |
| Ticketing and case management | ServiceNow, Jira |
| Threat intelligence | CRISP reports, ISAC advisories, vendor bulletins |
Do not see your tool?
Crogl ships connectors for the tools you already run, and reaches anything with an API. Chat with a new system and Crogl builds the connector itself, in minutes rather than a vendor release cycle. Crogl also supports Model Context Protocol for tools that speak it.
No schema normalization. No recoding. If your data is there, Crogl can query it.
Federated search and SIEM migration
Your SIEM becomes a data source you can swap.
Most teams stay on a SIEM they have outgrown, because moving means rebuilding every detection, remapping every schema, and running thinner coverage while it happens. That cost exists because the investigation logic lives inside the SIEM, encoded in its query language and its field names.
Federated search moves that logic out. Crogl queries your SIEM the way it queries any other source, so the platform becomes one data source among many rather than the brain of your SOC. When you switch, you point Crogl at the new system. Crogl can query the old and the new platform during the transition, so coverage continues while the migration runs.
That is the whole argument behind SIEM migration without losing detection coverage, and it is downstream of querying in place.
Does federated search move my data?
No. The query travels. The data stays.
Federated search is the reason Crogl can promise data sovereignty rather than describe it as a setting. Crogl deploys inside your controlled environment, on-premises, in your private cloud, or fully air-gapped. The queries run from there against systems you already own.
No investigation result, no alert content, and no query output transits an external network. A U.S. defense agency runs Crogl in a classified, air-gapped environment for exactly this reason, and investigates more than 1,000 alerts a day inside it.
Crogl does keep something locally. As its knowledge graph learns which fields across two systems refer to the same user or asset, it retains representative samples as evidence for those relationships. That is a working set for the graph, not a copy of your operational estate, and it stays in your environment with everything else.
What federated search requires
Not magic AI. Operationally relevant AI.
Querying in place is an engineering property, not a spell. Three things have to be true for a source to join an investigation.
A connector
Crogl reaches a source through a connector that speaks its query interface. Thirty-plus ship with the product, and a team can build new ones in minutes rather than waiting on a vendor release.
Read access
Crogl queries with credentials your team grants and scopes. A source nobody has authorized Crogl to read stays outside the investigation, which is the correct behavior.
A source that can answer
A federated query runs at the pace of the slowest system it touches. Crogl reports which sources it queried and what each returned, so a slow or unavailable source is visible rather than silently dropped.
Common Questions
What is federated search in security operations?
Federated search queries each security data source in place, in its own query language, and returns the results to one investigation. Nothing is copied into a central store first and no shared schema is required. The alternative is centralization, where data is ingested and normalized before any investigation can use it.
Does federated search move or copy my data?
No. The query travels to the data rather than the data traveling to a vendor. Crogl runs inside your environment, on-premises, in your private cloud, or fully air-gapped, and queries your systems from there. Crogl retains representative samples locally as evidence for learned relationships, not a copy of your operational estate.
What is the difference between federated search and data centralization?
Centralization copies data into one platform and normalizes it into a shared schema, which gives fast repeated queries over the sources a team chose to ingest and leaves everything else out. Federated search queries each source where it already lives, which puts every connected system in scope and costs a connector plus read access for each one.
What does Crogl need in order to query a data source?
A connector that speaks the source's query interface, and read credentials your team grants and scopes. Thirty-plus connectors ship with the product and teams build new ones in minutes. A source that nobody has authorized Crogl to read stays outside the investigation.
Can Crogl investigate across a SIEM and a data lake at the same time?
Yes. A single investigation can query a SIEM, an EDR, an identity provider, a data lake, and a ticketing system, then cross-reference the results into one documented finding. A Fortune 500 financial institution runs cross-lake investigations this way in minutes, down from about an hour.
Normalization is optional. Cross-system investigation is not. A team that has centralized a high-value core should keep it, and Crogl will query that core alongside the identity system, the ticketing platform, and the cloud API that never made it into the pipeline. That is what produces threat coverage across every connected source rather than coverage of the pipeline.
Federated search is what makes an AI SOC able to investigate the environment as it exists, rather than the tidy subset someone had budget to centralize. The rest of the Crogl platform is built on top of that one property.
Test It Against Your Stack
The honest test is your own data, not a demo environment.
Install Crogl, point it at the sources you already run, and watch which ones it queries during a real investigation. Every query it issues and every result it reads are logged.
Deployed in air-gapped federal environments, critical infrastructure, and Fortune 500 financial institutions.