TheHive + Cortex → Splunk SOAR
TheHive + Cortex ↔ Splunk SOAR: integration to migration path.
You do not rip out a working SOAR. TheHive + Cortex stands up alongside Splunk SOAR first, ingesting the same Splunk ES notables, so it carries real case load on day one without touching a single Splunk SOAR playbook. Then the case layer, the action layer and the App dependencies move over cohort by cohort — no flag day, no forced re-credentialing, and every phase rolls back in minutes.
The honest exception sits at the very end: Splunk SOAR retirement is reversible only inside a 30-day read-only evidence window. We say so up front, because the rest of this only matters if you can trust it.
The idea
Dual-route the alert first. Retire the contract last.
The topology that makes this zero-downtime is fan-out at the source: Splunk ES sends each notable to
both SOARs at once. The existing Splunk SOAR adaptive-response action stays exactly as it is, while a
second action POSTs the same notable to TheHive's alert API with a deterministic sourceRef keyed
to the notable ID, so the two records dedup cleanly and a documented routing rule decides system-of-record per
cohort. TheHive can carry production load immediately because nothing has been taken away from Splunk SOAR —
and only once a cohort is proven do we move its case work, then its action layer, then its Apps, each layer
independent and each reversible.
The phases
Six steps. Each one reversible.
Baseline and inventory
We read your Splunk SOAR estate without touching it: every playbook with its trigger, App dependencies, custom Python and Prompt blocks, plus a 90-day execution count, then every App with its assets and credentials. Each is tagged rewrite-as-Cortex, accept-gap, or keep-SOAR.
Stand up TheHive + Cortex; one-way bridge from Splunk ES
TheHive 5 and Cortex 3 go live as HA clusters in your environment, and Splunk ES gets a second adaptive-response action that POSTs each notable to TheHive alongside the untouched Splunk SOAR ingest. A canary cohort runs in both SOARs at once.
Cut the commodity cohort to TheHive primary
Phishing, brute-force and commodity-malware playbooks are re-implemented as TheHive case templates plus Cortex analyzers and responders, then the routing rule makes TheHive system-of-record for that cohort. Splunk SOAR still receives the alerts but auto-closes them within 24 hours. Rolled out at 10 percent, 50 percent, then 100 percent.
Move the action layer to Cortex; Splunk SOAR becomes callable-only
For the residual ESCU-tight and vendor-locked cohorts, TheHive owns the case while a Cortex responder calls Splunk SOAR's playbook-run API only for the action steps that still need a vendor App. Named-RBAC approvals stay on the Splunk SOAR Prompt block, triggered from a TheHive task.
Rewrite residual Splunk SOAR Apps as Cortex analyzers and responders
Each remaining Splunk SOAR App is either replaced by a community Cortex analyzer, rewritten as a PAP-gated Cortex responder, or formally accepted as a documented gap kept on Splunk SOAR. Credential rotation runbooks move to Vault, OpenBao or SOPS as we go.
Retire Splunk SOAR (or freeze it as residual)
Either every Splunk ES adaptive response points at TheHive and the licence lapses, or Splunk SOAR is frozen as a documented, scoped residual for the accept-gap surface. Residual responses are disabled one at a time on a 7-day soak; the audit log is exported to your SIEM and App credentials revoked in waves before the contract is cancelled.
Feature parity
Where they match, and where they don't.
| Capability | TheHive + Cortex | Splunk SOAR | Parity |
|---|---|---|---|
| Case management | TheHive Cases / Observables / Tasks (first-class) | Splunk SOAR Containers + Workbooks | At parity |
| Playbook / workflow authoring | Cortex Responder chains + Case Templates (Python) | Splunk SOAR Playbooks (visual editor to Python) | Partial |
| Integration / connector catalogue | Cortex Analyzers (~150, community) | Splunk SOAR App Store (~700 Apps) | Partial |
| Enrichment / analyzers | Cortex Analyzers (JSON over stdin/stdout, locally hostable) | Splunk SOAR phantom.act() App actions | At parity |
| Alert ingestion | TheHive /api/v1/alert from ES adaptive response (you build it) | Splunk SOAR adaptive-response container ingest | Partial |
| Threat-intel module | MISP-native bidirectional (analyzer pull + responder publish) | Splunk SOAR MISP App (per-action, not continuous) | At parity |
| PAP (Permissible Actions Protocol) | First-class PAP 0-3; analyzers and responders refuse if pap exceeds max_pap | Tag conventions + playbook conditionals only | OSS only |
| TLP markers | First-class TLP enums on observable / alert / case | Custom tag or CEF convention | OSS only |
| Approval / collaboration | TheHive task acceptance (assignee / role, audit-logged) | Splunk SOAR Prompt block, RBAC-bound | Partial |
| Investigation timeline | Case timeline + Cortex job log | Splunk SOAR HUD / Mission Control timeline | Partial |
| RBAC + multi-tenant | TheHive 5 per-Org isolation + TLP-driven view filtering | Splunk SOAR roles + role-based prompts | At parity |
| Audit / retention | Cassandra / JanusGraph + ES under your custody, your retention | Splunk SOAR PostgreSQL audit, vendor-managed retention | Partial |
| Deployment + HA | Self-hosted: 3+ Cassandra nodes, ES, attachment store | Vendor-managed (SOAR Cloud / Mission Control) | Partial |
| Cost model | Self-hosted compute + ops; no per-action licensing | Per-action / per-user licensing | Partial |
| Compliance (SOC 2) | Self-operated boundary (you own controls) | Vendor-operated SOC 2 boundary | SaaS only |
What we're honest about
The caveats most vendors leave out.
The Cortex catalogue is smaller than the App Store
Splunk SOAR's App Store carries roughly 700 vendor-curated, one-click Apps; the community Cortex analyzer catalogue is closer to 150. The day-one ability to grab a brand-new vendor integration instantly is something you give up — so we pre-build a runbook for authoring a new Cortex analyzer in a sprint, and any App with no clean OSS analogue is inventoried in Phase 0 as a rewrite or a deliberate accept-gap.
PAP and TLP semantics are first-class only on the OSS side
TheHive and Cortex enforce PAP and TLP at the data layer — an analyzer simply refuses to run when an observable exceeds its configured ceiling. Splunk SOAR has no first-class equivalent; the same intent is encoded as tag conventions and playbook conditionals. Every TheHive-to-Splunk-SOAR bridge call must re-encode that gate as its first conditional, or a Cortex-gated observable can be acted on by a Splunk SOAR playbook that does not honour it.
No Mission Control HUD timeline or incident-similarity ML
Splunk SOAR's HUD and Mission Control investigation timeline and its incident-similarity clustering have no exact open-source twin. TheHive's case timeline plus the Cortex job log is close, not one-to-one, and the inline Prompt-block approve/reject UX is not reproducible OSS-side without an external workflow step. We budget the UX training and brief the gap rather than pretend it away.
You own availability and the SOC 2 boundary
Splunk SOAR Cloud is a vendor-operated SOC 2 boundary with managed credential vaulting and HA. Self-hosting TheHive flips that custody inbound: if the cluster is down you have no SOAR, and you own the controls an auditor used to read off Splunk's report. That is exactly why we run it as a managed service — at least three Cassandra nodes across zones, a tested DR runbook with a measured RTO, and at least one audit cycle of overlap before the boundary moves.
Why this beats a flag day
Reversible at every step, gated before the contract goes.
Every phase before retirement reverts in under 15 minutes — disable one Splunk ES adaptive-response action, or flip a routing rule back to Splunk SOAR primary, and you are exactly where you started with the open TheHive cases kept as history. We never cancel the Splunk SOAR contract on faith: each migrated cohort soaks at 100 percent for at least 30 days with close rate at or above baseline and zero PAP-gate violations before the licence is allowed to lapse, and even then a 30-day read-only evidence window keeps the door open.
See whether your SOAR estate moves cleanly.
A call with a senior detection-and-response engineer. We inventory your Splunk SOAR playbooks and Apps, separate the commodity cohorts from the ESCU-tight and vendor-locked ones, and tell you honestly which move to TheHive + Cortex now, which call back into Splunk SOAR, and which stay — before you commit.
Map my migration →