Arkime → Vectra AI
Arkime ↔ Vectra AI: integration to migration path.
Arkime and Vectra are not the same product class — so this is not a rip-and-replace, and we say so first. Arkime deploys alongside Vectra as a full-PCAP forensic substrate, gets wired into the SOC runbook so every detection gains byte-level evidence, then takes over the Recall forensic surface — while Vectra's ML detection layer keeps running untouched, every step reversible in minutes.
The honest boundary is firm: this plan retires Vectra Recall, not Vectra ASI. The ML detection and Privileged Account Analytics stay — Arkime is the evidence behind detections, never the detector.
The idea
Add the byte truth first. Retire only Recall.
The topology that makes this zero-impact is a shared aggregation tap fanning the same mirror to two destinations: the Vectra Stream sensor and a dedicated Arkime capture node. Vectra keeps owning ML detection and host scoring while Arkime indexes session metadata to OpenSearch and writes full PCAP slabs under your retention. A SOAR playbook joins the two on Community ID, so a Vectra detection drills straight to the packets behind it. Only the forensic surface — Recall — is ever migrated; the ML detection plane stays exactly where it is.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We document every tap and the bytes-per-second sustained on it, Vectra detection volume by category, the last 30 days of Recall query patterns, the SIEM correlation rules that consume Vectra detection IDs, and per-zone retention requirements. Read-only against the Vectra API.
Arkime capture on one tap
One Arkime capture node, viewer and OpenSearch cluster ingest a single high-value tap while Vectra continues on the same feed. SPI is searchable for at least seven days and PCAP retrievable for at least one. A Zeek sidecar joins on the same tap if one is not already present.
Wire Arkime into the runbook
A SOAR playbook computes Community ID from each Vectra detection's 5-tuple, queries the Arkime viewer API for the matching session, and attaches the evidence links to the case — so every tier-2 ticket gains an Arkime panel pointing at the bytes behind the detection.
Expand Arkime to every tap
Every tap feeding Vectra Stream also feeds an Arkime capture node, sized per zone against the real session rate, with PCAP retention set to each zone's forensic or regulator requirement and OpenSearch sized for at least 30 days of SPI.
Reduce Recall dependency
Analyst investigations pivot to Arkime SPI and PCAP as the primary search surface; the top Recall saved searches are migrated to Arkime expressions and analysts are trained on the syntax. Recall is opened only for Vectra's normalised metadata view or ASI-feature exploration.
Decide on the Recall subscription
With Recall usage down to a small fraction of baseline, the Recall subscription is downgraded or cancelled at renewal. Vectra Detect / ASI and Privileged Account Analytics remain — there is no OSS replacement for them in this plan.
Steady state
Arkime is the forensic substrate, Vectra Detect / ASI is the live ML detection layer, the SIEM does correlation, and Privileged Account Analytics stays. This plan does not retire Vectra ASI. A future ML-replacement effort would be tracked under its own separate brief.
Feature parity
Where Arkime matches Vectra — and where it does not.
| Capability | Arkime | Vectra AI | Parity |
|---|---|---|---|
| Full-packet capture | Arkime capture daemon to PCAP slabs (/data/moloch/raw/) | Cognito Recall metadata plus sampled payload | OSS only |
| Session/flow metadata | Arkime SPI in OpenSearch (sessions3-*) | Cognito Recall metadata search | At parity |
| Behavioural/ML detection | None (SIEM correlation primitives only) | Attack Signal Intelligence (ASI) ML host/account scoring | SaaS only |
| Protocol decoders | Zeek sidecar (conn.log / ssl.log) joined on Community ID | Vectra internal vendor decoders | Partial |
| Encrypted-traffic handling | JA3/JA3S SPI fields (tls.ja3); JA4 via plugin | ASI fingerprints internally; raw values not always queryable | Partial |
| PCAP/retention control | OpenSearch ISM plus per-zone PCAP slab rotation; your cost curve | Vendor SKU-tiered retention | OSS only |
| Threat intel feed | Arkime WISE plugin enrichment | ASI vendor threat intel | Partial |
| Alerting | Via SIEM (Sigma over SPI plus Zeek notice.log) | Native ASI detections to SIEM / SOAR | Partial |
| Integrations & API | Arkime viewer REST API (/api/sessions) | Vectra API (/api/v2.1/detections) | At parity |
| Privileged account analytics | None | Privileged Account Analytics baselines | SaaS only |
| Deployment & HA | Self-managed OpenSearch HA plus multi-node capture | Vendor-managed sensor health | Partial |
| Cost model | Compute plus storage (OSS licence) | Per-Gbps subscription | Partial |
| Compliance (SOC 2 / data residency) | In-VPC bytes plus metadata; CC6.6 / CC7.2 self-attested | Recall vendor-hosted in most regions | Partial |
What we're honest about
The caveats most vendors leave out.
Arkime does not replace Vectra ASI
This is the framing the whole plan rests on. Arkime is full-PCAP capture and session search — a forensic substrate. Vectra's Attack Signal Intelligence fuses primitive detections into per-host and per-account scores with attack-progression context, and there is no OSS equivalent. The plan keeps ASI; selling Arkime as an ASI replacement would be selling fraud, so we never do.
Privileged Account Analytics stays
Vectra's identity-side behavioural baselines have no OSS replacement in this plan either. If the customer insists on full Vectra retirement, that is a separate identity-side UEBA-on-SIEM workstream we scope explicitly — not something Arkime quietly absorbs.
PCAP retention is the cost knob, and OpenSearch ops is on you
Ten Gbps sustained is roughly 108 TB per day of PCAP, so storage cost is measured in Phase 0 and tiered per zone — keep SPI long and cheap, PCAP short and expensive. The OpenSearch cluster is yours to run: HA, snapshots, rolling upgrades and on-call. We size it for HA from Phase 3 and can lean on a managed OpenSearch service if the team cannot staff it.
ATT&CK tags and host scoring do not survive the move
Arkime emits no ATT&CK metadata and no host score — it is the evidence, not the tag source. Vectra's per-detection ATT&CK mapping and fused host scoring are reproduced, if at all, by SIEM rule content over Zeek, Suricata and SPI primitives, which is a SIEM workstream and only primitive correlation, not supervised ML. We are explicit about what does and does not carry across.
Why this beats a flag day
Reversible at every step, soaked before anything is cancelled.
Every technical step rolls back in under 15 minutes — power off a capture node, remove a tap from the fan-out, or disable the SOAR enrichment, and Vectra is unaffected throughout. And nothing irreversible happens early: Arkime must cover every tap with session loss under 1% for at least 30 days, and Recall usage must sit at or below 20% of baseline for at least 30 days, before the Recall subscription is even considered for cancellation at renewal. The contractual step is always last, and only after the evidence is in.
See whether Arkime can carry your forensic substrate.
A call with a senior detection engineer. We measure bytes-per-second per tap, map your Recall query patterns and retention SLAs, and tell you honestly which forensic load Arkime can own and where Vectra ASI stays the detector — before you commit to anything.
Map my migration →