Streaming network detections turn flow telemetry into portable findings

At a glance

What this is: TENZIR argues that flow telemetry can drive portable streaming detections for scan fan-out, beacon cadence, exfiltration bursts, and long connections when diverse sources are mapped into a common OCSF Network Activity schema.

Why it matters: This matters because SOC teams can move detection logic across sensors and pipelines without rewriting the analytic every time, but only if telemetry semantics and enrichment remain consistent.

Context

Flow telemetry is connection-level network data, not packet payload, so it can still reveal suspicious behaviour when the analytic is built around timing, direction, size, and fan-out. The governance problem is not whether the data exists, but whether different producers preserve the same field semantics strongly enough for one detector to behave consistently.

In this article, the identity angle is indirect but real: detection pipelines consume security telemetry from multiple sources, and the control point is the integrity of the mapped fields that a downstream finding depends on. For SOC teams, that makes schema consistency, provenance, and enrichment trust boundaries part of the detection control surface rather than back-end plumbing.

Key questions

Q: How should security teams design flow-based detections that work across different telemetry sources?

A: Start by normalising every source into a stable schema and then build detections against that schema, not the original log format. Keep field semantics, event time, and provenance consistent so the same logic can run across NetFlow, Zeek, Suricata, and cloud flow logs without rewriting the detector for each source.

Q: Why do cadence-based beacon detections work on flow records without payload inspection?

A: They work because beaconing is a repeated timing pattern, not a content problem. By measuring inter-arrival intervals, byte sizes, and dispersion around the median, a detector can identify regular check-ins from flow metadata alone. That makes it useful for encrypted traffic, but it still needs stable windows and a long-connection companion rule.

Q: What breaks when long connections are not covered in network detection logic?

A: A beaconing implant that keeps one session open may never produce repeated flows, so cadence analysis has nothing to compare. In that case, a detector focused only on short repeated connections misses an important pattern of control traffic. Adding long-connection coverage closes that blind spot and improves coverage of low-noise operator traffic.

Q: How should teams evaluate whether flow-based exfiltration detection is trustworthy?

A: Teams should check whether the enrichment that marks traffic as internal or external is accurate, current, and consistently applied. If those labels are stale or inconsistent, outbound burst detection may flag the wrong asset or miss the real one. The practical test is whether the same transfer pattern produces the same judgement across the pipeline.

Technical breakdown

Why a shared network activity schema matters for detection

A detection pipeline cannot reliably reuse logic across NetFlow, Zeek, and Suricata unless the records mean the same thing once they reach the analytic. OCSF Network Activity provides that contract by placing source, destination, protocol, timing, and traffic fields in stable locations while preserving source provenance in metadata. The detector then subscribes to a common stream and ignores the original transport or sensor type. That separation is what makes a scan rule, beacon rule, or volume rule portable. If the mapping drifts, the same analytic can become noisy or blind even though the input still looks structured.

Practical implication: treat schema mapping as part of detection engineering, not ingestion hygiene.

How cadence-based beacon detection works in streaming telemetry

Beaconing is a timing problem. The analytic groups flows by source, destination, and port, then calculates inter-arrival intervals and byte-size distributions over a rolling window. Median and MAD, or median absolute deviation, reduce the influence of one missed check-in, while skewness helps show whether the series clusters tightly around a stable cadence. That is why the method can surface regular check-ins without relying on payload inspection. It also explains the blind spot: if one connection stays open and does not reappear as repeated flows, cadence analysis has little to compare, so the companion long-connection detector becomes necessary.

Practical implication: pair cadence analytics with a long-connection detector so open sessions do not hide beacon activity.

Why enrichment changes exfiltration and boundary detection

Outbound exfiltration is not just a byte-count threshold. The detector in this article groups outbound bytes per internal asset and uses network-scope enrichment to decide whether the traffic crossed a trust boundary. That matters because raw flow data alone does not know which endpoint is internal, external, or temporarily trusted. Once enrichment stamps boundary context onto the record, the analytic can compare an asset against its own recent baseline instead of a global average. The result is a detector that is more operationally useful, but also more dependent on the integrity of the enrichment pipeline and the stability of the boundary labels.

Practical implication: protect enrichment sources and boundary labels with the same care you apply to the detection rule itself.

Threat narrative

Attacker objective: The attacker wants to reconnoitre targets, maintain command-and-control, or move data out of the environment while avoiding payload-based inspection.

1. Entry begins with ordinary network traffic that produces flow records, giving the detector visibility into scanning, beaconing, or bulk outbound movement without inspecting payloads.
2. Credential or payload capture is not the focus here; instead, the analytic looks for behavioural signatures such as fan-out, regular cadence, or sustained transfer patterns that indicate malicious control or exfiltration.
3. Impact appears when the stream identifies reconnaissance, command-and-control, or data-exfiltration behaviour early enough for the SOC to act before the activity blends into normal traffic.

Breaches seen in the wild

• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Portable detection depends on semantic discipline, not just telemetry volume. If a scan rule or beacon rule can move between NetFlow, Zeek, and Suricata, the real control is the stability of the mapped fields, not the sensor brand. That shifts detection engineering toward governance of schema meaning, provenance, and enrichment quality. Practitioners should treat field semantics as a security dependency, because inconsistent mappings can silently break an otherwise sound analytic.

Flow telemetry can expose meaningful attacker behaviour without payload inspection. That is important for SOCs because many high-value signals, including fan-out, regular check-ins, and outbound bursts, are visible at the connection layer. The limitation is not analytic theory but control design: teams still need clear thresholds, bounded windows, and separate handling for long-lived sessions. Practitioners should align flow analytics with response workflows that can act on partial but high-confidence evidence.

Detection findings become more useful when they are portable and routeable. Embedding tactic and technique context in the finding stream means downstream systems can correlate and triage without re-parsing rule metadata. This points to a broader market direction where detection logic, telemetry normalization, and response routing are being designed as one pipeline. Practitioners should evaluate whether their own detection stack preserves evidence and context as first-class data.

Trust boundaries in telemetry pipelines are now part of security governance. Once enrichment labels decide what is internal, external, or suspiciously high volume, the pipeline is making a security judgement before the alert is even emitted. That makes enrichment governance and lineage visibility essential for reliable detection operations. Practitioners should verify where boundary context comes from and how it is maintained across the pipeline.

What this signals

Flow telemetry detection is moving toward pipeline-native analytics. The practical lesson for SOC teams is that detection logic should be treated as a reusable data product, not a one-off rule attached to a single sensor. That approach makes tuning, testing, and correlation much easier when telemetry sources change.

Portable detections only stay portable when field semantics stay stable. The strongest implementation risk is not the analytic itself, but the silent drift that happens when mappings, enrichment, or event-time handling change between sources. Teams should watch for schema changes that alter the meaning of source, destination, timing, or byte-count fields.

Detection engineering is increasingly a governance problem. When a pipeline preserves provenance, routes findings separately, and embeds technique context in the finding stream, it becomes easier to operationalise alerts across tools and teams. That is the pattern SOC leaders should expect to see more often across streaming telemetry stacks.

For practitioners

• Standardise flow telemetry into one schema Map NetFlow, Zeek, Suricata, and cloud flow logs into a shared network activity model so detection logic does not depend on the source format.
• Separate findings from source events Publish detections on a dedicated findings stream while keeping raw telemetry available for storage, correlation, and later investigation.
• Tune cadence detectors against real traffic Use representative traffic to set minimum samples, interval bounds, size dispersion, and unanswered-attempt thresholds before production rollout.
• Add a long-connection detector beside beacon logic Cover the case where an implant holds one session open and never produces repeated check-ins, so cadence analysis alone does not miss it.
• Govern enrichment as a control surface Validate source provenance, internal and external labels, and asset context so boundary-based burst detection keeps trustworthy trust-boundary signals.

Key takeaways

• Flow records can support meaningful detection even when payload inspection is unavailable, provided the analytic is built around timing, size, and fan-out patterns.
• The portability of the detection depends on stable schema mappings and trustworthy enrichment, not on the original sensor type.
• SOC teams should combine cadence, burst, and long-connection logic to avoid blind spots that a single rule would miss.

Key terms

• Flow telemetry: Flow telemetry is network metadata describing communication between endpoints, usually without payload content. It includes source, destination, protocol, timing, and byte counts, and it is often sufficient to identify scanning, beaconing, or exfiltration patterns when the fields are normalised consistently.
• Beacon Cadence: A repeating timing pattern in outbound network traffic that can indicate command-and-control behaviour. Analysts measure the spacing and size of flows to find small, regular check-ins, then compare them against normal client behaviour and expected operational noise.
• Network activity schema: A network activity schema is a common record structure that maps different telemetry sources into the same field meanings. It allows detection logic to run against multiple sensors without rewriting the analytic, but only if the mappings preserve provenance and do not blur key semantics.
• Long-connection detection: Long-connection detection looks for sessions that remain open rather than producing repeated short flows. It matters because some implants or applications keep a single channel alive, which can hide from cadence-based analytics that depend on seeing repeated check-ins over time.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is a fit for practitioners who want to connect identity controls to broader detection and response programmes.