Why unified telemetry works: how Netgraph removes the seams a SOC bleeds through

Watch an experienced analyst work a real incident in a conventional SOC and time where the minutes actually go. Very little is spent on judgement. Most of it is spent on transitions: pivot from the SIEM alert to the EDR console to see the process tree; discover the EDR calls the host by a different name; re-search; pivot to the network tool to check what the host talked to; translate the query into that tool's syntax; export a CSV because the tools don't share; paste indicators into the identity console; lose the thread; re-orient. Each transition is small. An investigation contains dozens. And every one of them happens at a seam — a boundary between tools that was never designed to be crossed.

Seams are where a SOC bleeds. Not dramatically — drip by drip, in re-queries and renamed entities and "wait, which host was that again". And seams are where attackers live, because an operation that spans four telemetry planes is only as detectable as your ability to join those planes faster than the operation completes. We saw this concretely in the H1 2026 ransomware pattern analysis: every kill-chain stage was visible in some tool; the campaign was visible in none of them.

The classic seams, named

Every estate has its own scar tissue, but four seams recur so consistently they deserve names:

• SIEM ↔ EDR. The SIEM raises the alert; the evidence — the process tree, the parent-child chain, the file writes — lives in the EDR console. The analyst does the join by hand, per alert, forever. Worse, EDR alert logic and SIEM correlation logic are tuned independently, so suppression done in one plane leaks noise through the other.
• EDR ↔ NDR. The endpoint sees the process; the network sees the conversation. Lateral movement is precisely the thing that is half-visible in each — the endpoint sees an outbound connection with no context of scale, the network sees fan-out with no context of what binary drove it. The detection that needs both usually exists in neither.
• Cloud ↔ identity. Cloud posture and audit logs describe resources; the identity provider describes humans and service principals. The attack walks the bridge between them — a compromised credential exercising cloud permissions — while each tool files its half under a different entity name.
• Vuln ↔ runtime. The scanner knows what is vulnerable; runtime telemetry knows what is exposed, reachable and actually running. Kept apart, one produces unranked backlogs and the other produces alerts with no exposure context. (This seam is really a CTEM problem — we treat it fully in the CTEM strategy post.)

Notice what all four have in common: neither side is broken. The bleeding is a property of the boundary itself. Which is why buying a better tool for either side of a seam never fixes it.

What "unified" must actually mean

Because every vendor with two products and a shared login now claims "unified", it is worth stating the test precisely. Unified telemetry is four concrete properties, and an estate either has each one or it does not.

One schema — with the raw preserved

Every event, from every plane, normalizes on ingest to one schema. Netgraph normalizes to OCSF/ECS-aligned fields: host.name means the same thing whether the event came from an endpoint agent, a firewall or a cloud audit log; actor.user.name is the same field in an authentication event and a process event. Crucially, the raw event is preserved alongside the normalized view — normalization that discards the original is a forensic liability, and honest normalization always has edge cases where the analyst needs to see what the source actually said.

One query language — everywhere

One syntax for every question, in every surface: discovery, hunting, detection rules, dashboards. In Netgraph that language is NQL, and "everywhere" is the load-bearing word — the query you sketch while hunting is the query you save as a detection rule, which is the same language the platform's assistant generates and validates as you type. The alternative — three tools, three syntaxes, and a mental translation layer the analyst maintains — is a tax on every single question the SOC ever asks. Query-language fluency is the analyst's deepest skill investment; splitting it three ways ensures fluency in none.

One alert queue — with source attribution

Every detection plane writes into one central alert stream. In Netgraph the alerts table carries a source attribution — SIEM correlation, EDR, NDR, cloud, UEBA, EPP scan — but the queue, the triage workflow, the suppression logic and the case linkage are singular. This sounds administrative. It is not: a "single pane of glass" that renders six queues in six widget frames is still six queues. One queue means one prioritization, one dedup/aggregation pass, one place where nothing falls between chairs because it arrived from an unfashionable plane.

One entity model — the knowledge graph

The deepest property, and the one that distinguishes unification from co-location: every plane's events resolve to the same entities. The host in the EDR event, the IP in the flow record, the hostname in the DHCP lease and the asset in the inventory resolve to one node; users, service accounts and sessions resolve to one identity; and the relationships between them — logged into, connected to, can reach, stores — are first-class edges. This is Netgraph's knowledge graph, and it is what makes the four seams above disappear rather than merely sit closer together. (The full argument is in the graph-native correlation whitepaper.)

What it buys, operationally

A single triage loop that works every alert

Because there is one queue, automation applied to the queue applies to everything. Netgraph's L1 autopilot triages every new alert — enriches, judges, closes the benign, escalates the real — regardless of which plane raised it. An EDR detection and a UEBA anomaly get the same first-pass treatment within the same near-real-time loop. In a siloed stack, triage automation is rebuilt (or more often, skipped) per console, so coverage follows tooling fashion instead of risk.

Cross-domain detections you cannot express in a silo

The highest-value detections in the modern threat pattern are conjunctions across planes. The H1 ransomware signature — help-desk reset, then new-device enrollment, then east-west fan-out toward the management VLAN — is an identity event, an identity event, and a network pattern, joined by entity and time. In a unified estate it is one rule:

# One rule, three telemetry planes, joined on one entity model.
FROM identity.events
| WHERE event.action IN ("password_reset", "mfa_factor_added")
| JOIN endpoint.process   ON actor.user   WITHIN 4h
| WHERE process.name IN remote_admin_tools
| JOIN network.flows      ON host.name    WITHIN 4h
| WHERE flow.direction == "lateral"
  AND  flow.dest.tags CONTAINS "mgmt"
| STATS hops = count_distinct(flow.dest.host) BY actor.user
| WHERE hops >= 3
| ALERT severity = high,
        title = "Reset → tooling → management-plane fan-out"

Try writing that across three consoles. You end up with three weak alerts and a wiki page asking analysts to correlate them mentally — which is to say, you end up with the status quo the attacker is counting on.

Suppression and aggregation done once, at ingest

Noise control in a siloed stack is done per tool, with per-tool semantics, and the planes re-flood each other through the seams. With one pipeline, suppression and aggregation are applied once, at ingest, with identical semantics everywhere — a suppression decision made on an EDR-sourced pattern holds across the estate, and aggregation can group by real entities ("one alert covering these 40 hosts") instead of spamming per-event. The analyst experience compounds: less noise means more trust in the queue means faster honest triage.

You learn what your data is worth

An underrated effect: when every feed lands in one pipeline with one cost meter and one detection layer, you can finally measure which sources earn their ingest — which feeds participate in detections and investigations, and which are expensive ballast. Siloed stacks structurally hide this, because each tool's ingest justifies itself. Unified telemetry turns "should we keep paying to ingest X?" from a theological debate into a report.

"The metric that convinced us wasn't detection coverage — it was that investigations stopped having a 'gathering' phase. The context is just there, on the entity, when the alert opens. My analysts got hours of their day back and honestly, some of their morale." — SOC lead, large Indian enterprise.

The economics, honestly

The reflexive objection is cost: "centralize everything" historically meant paying premium SIEM ingest rates for every byte in the estate, which is how SOCs learned to leave the expensive planes out — and thereby re-created the seams as a billing artifact. That objection is aimed at an architecture, not at unification itself. The economics change when three things hold:

• Tiered storage. Hot, queryable telemetry for the operational window; cheaper warm/cold tiers for the long tail — with retro-replay able to reach back into it when a new TTP drops. You stop paying hot-tier prices for data whose value is retrospective.
• Open formats. Telemetry stored in open, columnar formats rather than a proprietary index means the data outlives any single engine and is never held hostage at renewal time.
• Compute decoupled from storage. Query cost scales with the questions you ask, not with the bytes you retain. Retaining a year of flow logs stops implying a year of flow logs' worth of licensed index.

Under that architecture, unified is routinely cheaper than the silo portfolio it replaces — because you stop paying four vendors to store overlapping copies of the same events, and stop paying analysts to be the integration layer. The expensive thing was never the unification; it was the legacy pricing model that made unification punitive.

Migration reality: coexist, don't rip

The final honest note: nobody migrates a SOC in a weekend, and a platform that demands rip-and-replace is demanding you go blind mid-swap. Netgraph is built to coexist — its federation layer forwards queries to your incumbent SIEM in that system's own dialect (KQL, SPL, AQL) while the unified estate builds up beside it. The practical sequence we see work: land new telemetry planes in Netgraph first, keep the incumbent queryable through federation for its retention tail, move detection content plane by plane as confidence builds, and let the incumbent's renewal date — not a forklift — decide the end. The seam between old and new SIEM is, for a transition period, one more seam; the difference is that this one is explicitly bridged and visibly temporary.

For the fuller platform picture this post sits inside, the next-gen SIEM solution page covers the ingestion-to-detection pipeline, and why the graph is the product makes the case that the entity model is the part you are actually buying.

Next in this series: exposure management is where unification pays off hardest, because every CTEM stage spans every plane — read An effective CTEM strategy: unifying SIEM, UEBA, SOAR, NDR, EDR, CDR, CSPM and BAS.