Notifications
Clear all
Topic starter
18/08/2026 2:32 pm
TL;DR: Community ID lets teams correlate the same network flow across Zeek, Suricata, Sysmon, and EDR telemetry, and TENZIR shows how the hash can be computed retroactively from endpoint fields to restore missing pivot points. The practical value is not just cleaner telemetry, but faster investigation across network and endpoint layers when hunting DNS, TLS, and C2 activity.
NHIMG editorial — based on content published by TENZIR: Community ID correlation across network and endpoint telemetry
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should SOC teams use Community ID in multi-source telemetry environments?
A: Use Community ID as the shared join key between network and endpoint events, then enrich the joined record with process, user, and DNS context.
Q: Why does flow correlation matter when EDR and network tools already generate alerts?
A: Alerts often point to the same activity from different angles, but they do not automatically create a single investigative thread.
Q: What breaks when endpoint logs cannot be linked to network telemetry?
A: Investigators lose the ability to connect a connection to the process, user, and host that generated it.
Practitioner guidance
- Standardize flow identifiers across telemetry Compute Community ID in both network and endpoint pipelines so Zeek, Suricata, Sysmon, and EDR records share a common join key for investigations.
- Preserve the fields needed for retroactive hashing Ensure endpoint logs retain source IP, destination IP, ports, and protocol so analysts can generate the hash later when the original network sensor is missing or incomplete.
- Build hunt views around joined process and flow context Create investigation views that combine the hash with process name, user, host, and DNS context so analysts can move from traffic to attribution without manual record stitching.
What's in the full article
TENZIR's full article covers the operational detail this post intentionally leaves for the source:
- The exact TQL pipeline used to compute Community ID from Sysmon fields.
- The full Zeek and Sysmon example records, including field mapping and output structure.
- Practical workflow notes for pivoting between network and endpoint telemetry in Tenzir.
- The Community Edition and community resources referenced by the vendor for hands-on testing.
👉 Read TENZIR's walkthrough on computing Community ID across Zeek and Sysmon →
Community ID correlation: what it means for SOC hunting workflows?
Explore further
18/08/2026 3:19 pm
Community ID is a correlation primitive, not a control. Its value lies in making network and endpoint events joinable across tools, which is a visibility problem rather than an identity governance problem. That distinction matters because SOC teams often treat better joins as a security outcome in themselves. In reality, Community ID only improves the quality of evidence; practitioners still need strong telemetry coverage, process context, and response logic to turn joins into decisions.
A question worth separating out:
Q: Should teams compute Community ID at ingestion or only when hunting?
A: Compute it at ingestion whenever possible, because the join key becomes available for dashboards, hunts, and incident response without extra work later. If that is not feasible, retain the source fields so the hash can still be generated retroactively from whichever telemetry source is available.
👉 Read our full editorial: Community ID makes network and endpoint pivots far easier
