Zeek → ExtraHop Reveal(x)
Zeek ↔ ExtraHop Reveal(x): integration to migration path.
Network detection is something you cannot turn off and back on safely — a blind spot during a cutover is a blind spot an attacker walks through. So Zeek deploys alongside Reveal(x) on the same tap first, proves parity per detection class against the live appliance, then becomes authoritative one class at a time — Reveal(x) held as a silent backstop the whole way, every step reversible in minutes.
The honest exception is ML: Reveal(x)'s Detection Library has no clean OSS equivalent. We decide whether to keep it, replace it, or accept the gap before Phase 5 — never pretend a Zeek script equals supervised ML.
The idea
Share the tap. Move detections class by class.
The topology that makes this zero-outage is a regen tap (or SPAN-to-multiple) feeding both sensors the same packets — never daisy-chained, so neither tool is a single point of failure for the other. Zeek's protocol logs land in your SIEM keyed by Community ID, the lingua-franca join shared with Reveal(x)'s detection feed. Because both tools watch the identical wire, we can run each Zeek detection class in a shadow queue until it matches Reveal(x)'s precision, then flip authority class by class — Reveal(x) staying enabled in an observational queue as a 30-day backstop before any detection is disabled.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We document each monitoring point's bandwidth and drop rate, the decoder-by-decoder traffic share, every enabled Detection Library detection with its 90-day fire rate, Recall retention, ATT&CK coverage and your Reveal(x) integrations. Read-only against the appliance.
Zeek cluster on a regen tap
A Zeek cluster stands up on the same physical tap as the Reveal(x) sensor at the first monitoring point, shipping protocol logs to your SIEM under a zeek index. No Reveal(x) detection is disabled and no SIEM alert routes from Zeek yet.
Signature detections in parallel
Zeek notice.log emits for every detection class with a clear Zeek implementation — protocol anomalies, JA3/JA4 hits, file-policy violations, SSH brute-force, SMB lateral-movement — but those notices route to a shadow queue. Analysts tune; no on-call paging from Zeek.
Migrate detections one class at a time
For each class that reaches shadow-queue parity, Zeek becomes authoritative and pages on-call, while the matching Reveal(x) detection is left enabled but routed to a silenced observational queue for 30 days as a backstop. Waves run low to high blast-radius.
Scale Zeek to every monitoring point
The Zeek cluster lands on every point where Reveal(x) has a sensor, sized to peak Mbps plus 30% headroom with capture loss under 0.5%. Custom Spicy or BinPAC analysers are written for any operationally relevant protocol where Reveal(x) decoder coverage exceeded Zeek.
Long-tail: ML, Recall, hash-tracking
We make an honest disposition of the SaaS-only capabilities — keep Reveal(x) as a thin ML-only NDR, replace ML with a SIEM-side layer, or accept the gap in writing; rebuild Recall as OpenSearch over Zeek logs with a matching retention SLA; rebuild hash tracking via files.log plus a sandbox.
Retire Reveal(x) sensors
Either full retirement — all sensors powered off, ODS consumers cut, licence terminated, only if the ML gap was accepted or replaced — or partial retirement, keeping a smaller Reveal(x) SKU for ML detections only.
Feature parity
Where Zeek matches Reveal(x) — and where it does not.
| Capability | Zeek | ExtraHop Reveal(x) | Parity |
|---|---|---|---|
| Flow/transaction records | conn.log keyed by uid | Wire Records (per-transaction) | At parity |
| Protocol decoders | ~20–35 stock plus zkg packages | ~70+ proprietary decoders | Partial |
| Custom protocol parsers | Spicy (LLVM) plus BinPAC, first-class | Vendor-roadmap-paced decoders | OSS only |
| Behavioural/ML detection | None (script plus Sigma approximate) | Detection Library (ML plus signature) | SaaS only |
| Custom detection logic | Zeek scripting language (git / CI) | Detection Library opaque; enable/threshold only | OSS only |
| Encrypted-traffic handling | JA3/JA4 via ssl.log / x509.log packages | ETA (Encrypted Traffic Analysis) | Partial |
| File extraction | files.log plus FileExtract (MD5 / SHA256) | Vendor-controlled, in Records | At parity |
| Hash-based file tracking | files.log plus external VT / sandbox (UX rebuilt) | Vendor-curated hash reputation plus trajectory | SaaS only |
| Historical search | OpenSearch / Splunk over Zeek logs | Recall (vendor-managed, SKU-tied) | Partial |
| Community ID | community-id package | Internal flow IDs only | OSS only |
| Alerting / routing | notice.log plus Notice::policy | Open Data Stream (ODS) detection export | At parity |
| Deployment & HA / scale | Cluster framework (manager / proxy / worker, AF_PACKET) | Vendor sensor SKU sizing | At parity |
| Integrations & API | SOAR glue over Zeek alerts | Native CrowdStrike / ISE / SOAR webhooks | Partial |
| Cost model | Compute plus ops only | Per-Gbps SaaS licence | Partial |
| Compliance (SOC 2 / data residency) | All metadata in-VPC; CC6.6 / CC7.2 self-attested | Cloud-managed control plane sees metadata | Partial |
What we're honest about
The caveats most vendors leave out.
ML detections have no OSS parity
Reveal(x)'s Detection Library covers patterns — lateral movement, beaconing, account anomaly — that signature and behaviour rules approximate at best. The honest paths are to keep Reveal(x) as an ML-only NDR (partial retirement), build a SIEM-side ML layer at lower fidelity, or accept the residual risk in writing. We pick that before Phase 5, not after.
Decoder breadth is a real gap
Reveal(x) ships 70-plus proprietary decoders; Zeek covers roughly 20–35 stock. Enterprise legacy protocols — Oracle TNS, MSSQL TDS, Citrix ICA, MS-RPC sub-operations, AFP, MQ — have no clean Zeek source. We inventory each in Phase 0 and decide per protocol: write a Spicy parser, accept the gap, or keep Reveal(x) for that decoder only.
Recall and hash-tracking are rebuilt, not ported
Vendor-managed per-transaction search and curated hash reputation become OpenSearch over Zeek logs and a files.log-plus-sandbox pipeline. Per-transaction search is shallower for protocols Zeek does not log natively, and the tracked-across-the-wire UX is rebuilt in the SIEM. We document the gap rather than claim equivalence.
Cluster ops is real labour
Reveal(x) sensors are vendor-monitored; capture-loss tuning, worker rebalancing, NUMA pinning and Spicy parser maintenance are now on you. OSS-as-cost-saving fails if that headcount is not budgeted — so we run it as a managed service with alerting on capture loss and a DR runbook, not a fire-and-forget install.
Why this beats a flag day
Reversible at every step, soaked before anything is cancelled.
Every per-class authority flip rolls back in under 15 minutes — re-route the SIEM rules and Reveal(x) is authoritative again for that class. And nothing irreversible happens early: each migrated class soaks at least 30 days at parity with Reveal(x) left in an observational queue as a backstop, and the sensor itself sits in a 14-day observational window before any licence is cancelled. The contractual step is always last, and only after the evidence is in.
See whether your Reveal(x) detections move cleanly.
A call with a senior detection engineer. We inventory your decoder load and enabled detections, classify each as signature, behaviour or ML, and tell you honestly which classes Zeek can own and where Reveal(x) earns its keep — before you commit to anything.
Map my migration →