A detection rule and a hunting query may run against the same telemetry, but they want very different architectures.

The detection rule is known before the event arrives. It may need to maintain state across a stream, evaluate every event, and produce an answer within seconds or milliseconds.

The hunting query is created after the fact. It may scan months of history, join several data sources, and tolerate seconds or minutes of execution time without changing the outcome.

We routinely ask both workloads to run in the same place because security architecture has spent years treating data placement as the primary design decision. Decide where the telemetry lives, then put the analytics there.

That made sense when storage was the expensive part of the system. It makes less sense now.

Cheap object storage, high compression ratios, and indexes designed for large historical datasets have changed the economics of centralization. At the same time, federation has made it practical to query data that cannot or should not be moved. Both are useful developments.

Neither tells us where detection should execute.

The more useful design question is simpler:

Where should each workload run, given what it needs from the data and how quickly it needs an answer?

That produces a different architecture.

Storage has three credible answers

There are roughly three ways to handle security telemetry today.

Traditional centralization sends telemetry to a SIEM or lake, normalizes it, indexes it, and retains it according to policy and budget. The advantage is control. You know what you collected, how long you kept it, which schema it uses, and whether a query covered the complete dataset.

Historically, the problem was cost. SIEM pricing made ingest and retention expensive enough that organizations routinely discarded useful telemetry simply because keeping it searchable cost too much.

Federation leaves telemetry in the systems that produced it and queries those systems when needed. There is no second copy and potentially much less infrastructure to operate. It also provides access to sources that are difficult to export.

The compromise is that you inherit each source's retention period, availability, API behavior, schema, query semantics, and rate limits. The data may be physically distributed, but so are the dependencies required to answer a question.

Hyper-indexed object storage separates durable storage from the query engine. Telemetry can sit in relatively inexpensive customer-owned object storage while indexes, compression, and query acceleration make large historical datasets practical to search.

This third model matters because it weakens one of the strongest historical arguments against centralization.

If retaining a large dataset no longer requires paying SIEM-era prices for every gigabyte, "we cannot afford to centralize this" becomes a narrower objection. Federation still has important uses, but cost alone becomes a less convincing reason to make it the default architecture.

There is also something revealing about how the indexed-storage category is generally positioned. Its vendors tend to describe themselves as the data layer beneath the SIEM rather than as replacements for the detection system itself.

That distinction is useful. Storage and detection are related, but they are different architectural problems.

Workload placement depends on three things

A security workload's natural execution point follows from a few fairly mundane properties.

First, do you know the query before the data arrives?

Detection logic usually exists in advance. You know the fields, predicates, thresholds, relationships, and time windows you intend to evaluate.

A hunting query is often created in response to new information. Until the analyst or agent forms the hypothesis, there is nothing useful to pre-position.

Second, does the workload run continuously?

Many detections maintain state over a stream. A rule may track failed authentications per user, command sequences on a host, or activity within a rolling time window.

A hunt is usually transactional. Submit a query, receive an answer, decide what to do next.

Third, what is the cost of latency?

If a detection arrives thirty seconds late, an intervention opportunity may already be gone.

If a retrospective hunt takes thirty seconds longer, the result is still useful.

Those differences matter more to workload placement than the price of the storage tier underneath them.

Latency constraints vary

"Detection" is too broad a category to place as a single workload.

At one end are streaming detections. They maintain state and evaluate continuously, typically with latency budgets ranging from sub-second to a few seconds. Sequence detection, per-entity thresholds, and behavioral state machines belong here.

Inline enforcement is the extreme case. A process, packet, or authentication decision may need to return in tens of milliseconds. Once the action has been allowed, a later verdict has a different operational value.

Then there are detections that tolerate seconds or minutes. Cross-source correlations often fall into this category. Joining identity, endpoint, network, and application context may justify some delay if the additional evidence materially improves the result.

Finally, there is retrospective detection: apply a newly discovered indicator or behavior to historical data and find previous occurrences.

That last workload looks a lot like search, and modern centralized storage architectures are very good at it. Cheap, indexed historical storage is especially valuable here because it extends the period over which retroactive detection remains possible.

Streaming detection has different requirements.

Why search is the wrong execution model for streaming detection

The common criticism of federated detection is latency. A query fans out to several systems, each system responds at a different speed, and the slowest dependency determines completion time.

That is true, but latency is only part of the problem.

Search and streaming detection have different execution models.

A search starts with a request. The system evaluates it against some dataset, returns a result, and stops.

A streaming detector is already running when the event arrives. It may be holding state from thousands of earlier events and continuously updating that state as new ones appear.

Consider a simple rule: maintain a five-minute sliding window per account and trigger when a threshold is crossed.

You can reproduce something similar by repeatedly querying a database, but polling introduces awkward semantics. Windows overlap or leave gaps. Events can arrive out of order. The same condition may be rediscovered on consecutive polls. Shortening the polling interval increases cost without removing those boundary conditions.

Modern SIEMs have addressed this by adding stream processing to the ingest path. They evaluate rules as telemetry arrives rather than repeatedly querying stored data.

That is a sound implementation. It also exposes the remaining constraint: the telemetry still has to arrive.

For detections with a seconds-level budget, sending telemetry to a central processing layer may be entirely acceptable. For enforcement-adjacent decisions, transport, buffering, serialization, and ingest can consume most of the available latency before the rule starts evaluating.

The location of the data source therefore matters even when the central engine is very fast.

There is a second constraint that has nothing to do with performance. Some telemetry cannot be exported at full fidelity or at the required rate. SaaS security products may rate-limit APIs, delay access, charge for export, expose only summarized records, or provide no practical streaming path at all.

A centralized detector can only evaluate what reaches it.

This leads to a useful property of detection logic: because much of it is known in advance, it can be distributed ahead of time.

Instead of moving every event to a common location before deciding whether it matters, the system can move the rule toward the event source and evaluate there.

That does not eliminate centralized analytics. It changes what needs to cross the boundary.

Hunting wants almost the opposite architecture

Threat hunting starts from a different premise.

The question often does not exist until after the data has been collected. A new indicator appears. An investigation uncovers an unexpected relationship. An analyst notices behavior that was never encoded as a detection.

There is nothing useful to deploy in advance because the system does not yet know what it will be asked.

This is where centralized historical storage remains extremely attractive.

A normalized dataset gives you one query model instead of a collection of vendor-specific APIs. You control retention. Historical completeness is easier to reason about. The source that generated an event cannot later remove the only copy. A fifteen-month hunt does not depend on whether fifteen individual products happened to keep fifteen months of useful history.

Indexed object storage improves this further by reducing the economic penalty for long retention.

Federation still matters, but its strongest use cases are more specific:

• telemetry that cannot be exported at sufficient fidelity
• sources constrained by residency or sovereignty requirements
• datasets whose export cost exceeds their expected analytical value
• systems queried too rarely to justify continuous ingestion
• operational data that only exists inside a vendor-controlled interface

Those are substantial cases. Large enterprises will probably always have some of them.

They do not imply that all historical analysis should be federated.

In practice, a mature environment is likely to use both: deterministic centralized history where collection is practical, federated access for the remainder.

Agents make the economics more interesting

Autonomous investigation changes this balance because software can generate far more queries than human analysts do.

A human investigation might involve dozens of queries. An agent can issue hundreds or thousands, branch into several hypotheses simultaneously, abandon weak branches quickly, and repeat that process across every investigation in the environment.

That creates very different load characteristics.

In a federated architecture, each investigation may produce repeated calls into third-party systems. API quotas that were tolerable for human usage can become constraints on investigation throughput. Query-driven egress increases. Vendor-specific concurrency limits become part of the security system's control plane.

The workload can also become partially adversary-driven. If suspicious activity triggers investigation and investigation triggers large numbers of remote queries, activity generated by an attacker can indirectly influence query volume and cost.

Centralized data handles this pattern more predictably. Compute cost still rises with agent activity, sometimes substantially, but the organization controls the query infrastructure and the data it is querying. Capacity planning becomes an internal systems problem rather than a collection of external API contracts.

This does not make federation unsuitable for agents. It makes selective federation more attractive than universal federation.

The same architectural principle that helps with detection starts to become useful for investigation as well: move computation toward the source when you know enough about the computation to do so, and move data when the question genuinely requires broad, retrospective access.

The layers do not need to exchange raw telemetry

Once detection is distributed, it is easy to picture an architecture in which every component still forwards all of its underlying events upward.

That defeats much of the point.

A local detection layer can send a much smaller set of information:

• detections and verdicts
• entity state and risk assertions
• supporting evidence
• detector health and coverage
• state transitions
• summaries required for investigation

The central layer can send instructions in the other direction:

• updated detection logic
• changed thresholds or policies
• investigation requests
• response actions
• collection directives

Raw telemetry can still move into centralized storage where doing so is useful. It simply does not need to move there as a prerequisite for every detection decision.

This is compatible with any of the three storage models described earlier. An organization might centralize high-value telemetry into indexed object storage, federate into a few SaaS products that cannot be exported, and run local detection at endpoints, identity providers, network enforcement points, cloud control planes, and regional data nodes.

The storage architecture and the execution architecture become independent choices.

That is probably closer to how large security systems will actually evolve.

Each model fails differently

The differences become clearer when something goes wrong.

Federated search has a completeness problem. A source may have rolled past its retention period, hit a rate limit, become temporarily unavailable, or changed its schema. The query can still return a syntactically valid result.

"No matches" and "I could only search part of the relevant data" are very different answers, but many federated systems do not make the distinction obvious enough.

Federation also leaves primary evidence inside systems that may themselves be compromised. If the attacker controls the application, account, or security product that stores the only copy of its telemetry, the evidence used to reconstruct the intrusion is exposed to the same failure domain.

A central copy has value here even if nobody ever runs a detection against it.

Schema is another recurring problem. Federation does not remove normalization work. It shifts more of that work toward query time.

Open schemas such as OCSF help considerably, particularly as source vendors adopt them natively. They do not remove differences in field availability, semantics, retention, or implementation quality.

Centralization has its own failure modes. Collection pipelines break. Parsers mis-handle new formats. Export throttling creates gaps. Transformations discard fields that turn out to matter six months later.

The advantage is mostly operational visibility. If you own the collection path, you can instrument it, measure lag, detect dropped events, monitor parser failures, and preserve health history.

Indexed object storage adds another set of trade-offs. Good performance still depends on sensible partitioning, indexing, and data layout. Choices made during ingestion can be expensive to revisit. The storage may belong to the customer while the indexes or encoding remain proprietary, so claims of portability need to be examined carefully.

Cheap retention solves an important problem. It does not solve every analytics problem above it.

Architecture reviews should start with workloads

This changes the questions worth asking vendors and internal platform teams.

For each workload, determine its acceptable latency and where execution occurs. Measure latency from the creation of the event, not from the point at which the analytics engine receives it.

Ask what happens when a source cannot provide complete data. A system should be able to distinguish an empty result from an incomplete result and expose the reason.

Understand what evidence is retained outside the source's own administrative boundary and whether that evidence is sufficient to reconstruct what the security system knew at a particular point in time.

Then look at the contracts between layers. What schema carries detections, entities, evidence, health state, and commands? Who controls it? Can another implementation participate without reproducing a proprietary internal model?

Those questions reveal much more about the architecture than whether the product describes itself as centralized, federated, or data-lake-native.

Where this leads

Cheap indexed storage has made centralized historical analysis far more attractive than it was under the economics of traditional SIEMs. Federation remains necessary for data that cannot reasonably be collected. Most large environments will use both.

Neither should determine where detection runs.

Streaming detection benefits from evaluating as close as practical to the point where the relevant data is produced. The tighter the latency requirement, the stronger that pressure becomes. Historical investigation has the opposite preference: broad, durable, normalized access to as much history as possible.

The result is a system in which logic moves more freely than data.

That introduces another problem. Detection logic now runs across endpoints, networks, cloud environments, SaaS platforms, regional collectors, and other execution nodes. Those nodes have different capabilities, owners, software versions, and failure modes. Rules can drift. Coverage can disappear without anyone noticing. A distributed detection architecture that cannot prove what was running where and when is difficult to trust.

So the hard part is no longer deciding where to put the telemetry.

It is operating a distributed detection system without losing control of it.

_{In part two of this multi-part series, I'll cover strategies on managing distributed detection that mitigates "distributed chaos".}