Can open-source tools replace ThreatConnect case management?
OpenCTI's case management covers investigation records and links them to intelligence objects such as indicators, malware, threat actors and reports, but incident response tasks and artifact handling may need a separate tool. This topic is about OpenCTI, because MISP is an indicator sharing platform and not a case management system. If your team runs investigations in ThreatConnect cases through its v3 API, and a renewal, price change or data residency requirement is forcing a decision, the question is which parts of that workflow OpenCTI can carry and which parts you will need to place elsewhere.
Start with the investigation record. OpenCTI structures its data on the STIX 2 standard, so a case can be connected to the intelligence it relies on, and the GraphQL API can be used to read and write those links from your own scripts. Map each ThreatConnect case field to an OpenCTI case attribute, and record which fields have no equivalent. Also confirm how your target release handles case templates, attachments, status history and ownership in your own test instance. The Enterprise Edition adds audit logs and organization-based segregation, which matter if several teams or partners share one instance, but check the OpenCTI Enterprise Edition documentation for the exact feature set and license terms before you plan around them.
The gaps usually sit in incident response. Task assignment, time tracking, escalation, containment steps and evidence handling for files such as forensic images are not core parts of an intelligence platform, so plan for a separate case or incident response tool for those. TheHive is one option that OpenCTI can connect to, which means the intelligence stays in OpenCTI while response work moves to the other tool. Decide early which system is the system of record for each object type, write down the synchronization direction, and confirm with the vendors or your own testing how each integration handles updates and deletions. Ask any implementation partner for a field-by-field mapping before migration starts.
Which ThreatConnect case capabilities map to OpenCTI
This table maps the case capabilities a ThreatConnect team typically relies on to OpenCTI's case objects, knowledge graph, API and Enterprise features. Read each row as covered, partial or separate tool, then confirm the behavior in the OpenCTI release you plan to run, because case workflow details change between releases.
| Capability | OpenCTI mapping | Status and what to confirm |
|---|---|---|
| Cases as investigation containers | OpenCTI offers incident and case object types that group related intelligence and entities for an investigation. | Partial. Confirm which case types exist in your release and whether they fit your incident naming and ownership model. |
| Tasks assigned to analysts | Tasks can be modeled as case-linked work items in OpenCTI, with assignees and status tracked on the case. | Partial. Confirm task fields, due dates and assignment notifications, since ThreatConnect task workflows may need a separate ticketing tool. |
| Artifacts and evidence files | Files can be attached to OpenCTI objects and stored in S3-compatible storage such as MinIO. | Partial. Confirm file size limits, retention and how chain of custody is recorded for forensic artifacts. |
| Associations to indicators and groups | OpenCTI's knowledge graph links observables, indicators, reports and cases through STIX relationships. | Covered in principle. Confirm the relationship types you need for each case object and test them with real export data. |
| Workflow and approval steps | Playbooks are available in OpenCTI Enterprise Edition, under the OpenCTI Enterprise Edition License. | Partial. Confirm playbook triggers and actions against your approval steps, and plan a separate automation tool for anything else. |
| Audit trail of case changes | Audit logs are an OpenCTI Enterprise Edition feature. | Covered in Enterprise Edition only. Confirm log retention and export with the vendor before relying on it for evidence. |
| Access by team or organization | Organization-based segregation is an OpenCTI Enterprise Edition feature. | Covered in Enterprise Edition only. Confirm how it maps to your ThreatConnect owners and restricted cases. |
| Reporting and dashboards | OpenCTI provides a web application and GraphQL API that can feed custom reports and external dashboards. | Separate tool likely. Confirm which reports you need and whether they are built in OpenCTI or in a BI tool. |
| Incident response ticketing and SLAs | OpenCTI is not an ITSM or incident response ticketing system, and its connectors can exchange data with TheHive. | Separate tool. Confirm which ticketing, paging and SLA tracking system will own response timelines. |
Where OpenCTI, MISP and a separate tool each fit
ThreatConnect combines case records, tasks and intelligence objects in one product, so replacing it means splitting those jobs across tools. OpenCTI covers the knowledge graph and case records, MISP covers event sharing, and a dedicated ticketing or incident response tool covers the operational work that needs SLAs and approvals.
OpenCTI Community Edition
The Apache 2.0 edition of the platform, built on the STIX 2 data model, with case objects that link incidents to threat actors, malware, indicators and reports in one knowledge graph. It is the closest open-source match for the linking side of ThreatConnect cases. The trade-off is that you run the full stack yourself: Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO, plus the workers and connectors. Confirm which case templates, tasks and file handling you need before assuming the Community Edition covers them.
OpenCTI Enterprise Edition
The commercial tier of OpenCTI under its own license, adding playbooks, audit logs, organization-based segregation, full text indexing and SSO options such as SAML and LDAP. These features map to the parts of ThreatConnect teams use for multi-team access control and automated handling. The trade-off is a separate license fee that recurs, and a dependency on Filigran's terms. Ask for the feature list in writing and check which features your identity provider and audit requirements actually need.
MISP for event-centric sharing
MISP organizes work around events and attributes, with sharing groups, synchronization between instances and export formats for SIEM and network tools. It fits teams whose ThreatConnect use centers on sending indicators to communities or partners. It has no native case workflow with tasks, owners and status history, so investigations need either a case-style pattern built on event tags or an external tool. Check whether your sharing partners already use MISP sync before choosing it as the main system.
Separate incident response tool
A ticketing or incident response platform handles tasks with assignees, due dates, SLA timers, approvals and escalation, which are the operational parts of a ThreatConnect case that intelligence graphs do not model well. Teams often keep it in their existing ITSM or SOAR stack and link it to OpenCTI by reference. The trade-off is that analysts work across two systems, and you must maintain the link between an incident record and its intelligence objects. Ask who owns that integration and how audit trails are kept across both tools.
Integration and sync layer
Whatever mix you pick, something must move indicators, reports and case identifiers between tools without losing ownership or markings. OpenCTI connectors for MISP and TheHive show the pattern, and ThreatConnect data can be pulled through its APIs during migration. The cost here is engineering time to build, test and monitor the connectors, which recurs as APIs and schemas change. Define which system is the source of truth for each object type before writing any sync job.
Running OpenCTI cases beside ThreatConnect during transition
This is the common starting point when ThreatConnect playbooks still run enrichment, notifications and blocking, and the team wants to trial OpenCTI cases for investigation records. Keep the automation where it works today and move only the case narrative, tasks and linked observables into OpenCTI for a limited set of investigations. The trial should use one case type, one analyst group and a fixed time window so results can be compared fairly.
- Pick a bounded case type: Choose one incident class, such as phishing triage, and run it in both tools until the team trusts the OpenCTI record.
- Decide the writer: Name which system holds the authoritative status field during the trial, because two open statuses for one investigation cause disputes.
- Map playbook outputs: Note which ThreatConnect playbook actions write back to cases, such as enrichment tags, so those writes are repeated or replaced in OpenCTI.
- Plan connector runs: Confirm the OpenCTI connectors you need, including MISP or MITRE ATT&CK, and test their import volume against your sizing.
- Record the decision point: Set in advance what evidence will justify moving a playbook to OpenCTI or to a separate automation tool.
Before expanding the trial, confirm with your vendor whether ThreatConnect case data can be exported in a form that OpenCTI can ingest without manual rework.
Some organizations must keep ThreatConnect as the authoritative record, for audit, contractual or retention reasons, while analysts work in OpenCTI. In this model OpenCTI is a working copy, and the export direction is one way. Define the export cadence, the fields copied and the rule that edits happen only in the system of record, so the copy never drifts into a second source of truth.
- Export read-only: Pull cases, tasks and linked objects on a schedule and load them into OpenCTI as reference data, not as editable records.
- Preserve provenance: Store the originating ThreatConnect owner and case identifier on every imported object so auditors can trace it back.
- Map ownership and markings: Translate ThreatConnect owners into OpenCTI organizations and markings before import, so access controls match the source.
- Log each sync: Keep the timestamp, record counts and any rejected records for every run as evidence.
- Review the copy: Sample imported cases against the source each cycle to catch mapping gaps early.
Ask your ThreatConnect administrator which owners and fields your license allows you to export, and ask your auditor which copy of a record they will accept as evidence.
Many incident response teams move the operational work to a ticketing or incident response tool and keep threat intelligence in OpenCTI. In this split, the ticket is the case of record for response actions, approvals and communications, while OpenCTI holds the intelligence context. The ticket and the OpenCTI case should reference each other, so an analyst can move between them without re-keying data.
- Split responsibilities: Assign response tasks and approvals to the ticketing tool, and assign indicators, actors and campaign links to OpenCTI.
- Store cross-references: Put the OpenCTI case identifier in the ticket and the ticket identifier in the OpenCTI case, as external references.
- Mirror status changes: Decide which status transitions push from the ticket to OpenCTI, such as closure, and which stay manual.
- Limit duplicate artifacts: Attach files once, in the system that owns the response, and link to them from the other side.
- Check access rules: Confirm that responders who only work in the ticketing tool can still see the intelligence they need.
Confirm with your ticketing vendor whether webhooks or an API can write external references and status changes, since this determines how much of the link is automatic.
During transition, the same alert often appears in a SIEM, an endpoint tool and a ticket before it reaches a case. Each integration sends a different identifier, so the links break unless the team fixes a shared key. The safest approach is to define which identifier is canonical, store it on every object, and test one alert end to end before enabling the integration at volume.
- Carry the alert identifier: Store the SIEM or EDR alert ID on the OpenCTI case or incident object, so responders can search from either side.
- Keep indicator values normalized: Use one normalization rule for hashes, domains and IP addresses so the same observable matches across tools.
- Use stable case IDs: Treat the OpenCTI identifier as the anchor and pass it to the ticket and the SIEM case, rather than generating new IDs in each tool.
- Track time zones: Record event times in UTC so timelines from different tools line up during review.
- Test with one alert: Trace a single alert through all three systems and confirm every identifier resolves in both directions.
Ask your SIEM and EDR vendors which fields their connectors send and whether those fields can be written into OpenCTI or the ticket without custom code.
How to move open cases, tasks and artifacts into OpenCTI
This sequence moves active investigations out of ThreatConnect in a controlled order, so that each case arrives in OpenCTI with its links to intelligence intact and with a clear record of what was archived instead.
Inventory open and closed cases
The case owner or a platform administrator exports a list of every case in ThreatConnect with its status, owner, creation date, last update, number of tasks and number of attached artifacts. Sort the list into open cases, closed cases still referenced by active work, and closed cases with no current use. Confirm the counts against the ThreatConnect console before going further, because the export is the baseline you will reconcile against at cutover.
Decide which closed cases to archive
Agree with incident response, compliance and legal leads which closed cases must be migrated and which can stay in a read-only archive. Cases tied to regulatory reporting, litigation holds or open lessons-learned work usually need migration. Cases that only hold superseded indicator sets are often better kept as an exported archive. Record each decision in a register that names the case, the reason and the retention owner, so the archive can be audited later.
Map case fields and tasks to OpenCTI
Build a field mapping document that pairs each ThreatConnect case attribute, task, assignee, tag and artifact type with an OpenCTI object, such as a case of the incident or case type, a task, an identity for the owner, a marking for sensitivity, and an observable or file for each artifact. Note any ThreatConnect field with no clear OpenCTI equivalent and decide whether it becomes a label, an external reference or a note. The mapping is complete when the incident response lead has signed off on every row.
Export cases through the v3 API
An engineer with API access pulls cases, tasks, associations and artifacts through the ThreatConnect v3 API, following the pagination and filter guidance in the export topic for this group. Store the raw output in a versioned location with checksums, and keep the export scoped to owners your organization is permitted to export. The step is done when record counts match the inventory from the first step and every attachment has been downloaded or flagged as unavailable.
Prepare the OpenCTI platform and its dependencies
Before loading any data, the platform team deploys Elasticsearch 8.0 or later, or OpenSearch 2.9 or later, plus Redis 7.1 or later, RabbitMQ 3.11 or later and an S3-compatible store such as MinIO. Attachments depend on that object store, so confirm bucket creation and access before import. Also confirm that the OpenCTI platform, its Python workers and the connectors you need are running in a non-production environment. The step is complete when the platform loads, workers consume RabbitMQ messages and a test file uploads to the object store.
Load and validate test data in non-production
Import a representative subset of the exported cases into the non-production OpenCTI instance using the mapping from the earlier step. Check that each case has the expected tasks, that artifacts open correctly from the object store, and that markings and organizations match the ThreatConnect owners. Ask the analysts who worked those cases to confirm the content reads correctly. Fix mapping errors and rerun the load until the sample passes review.
Validate links to indicators and reports
Verify that every case still links to the indicators, reports and threat actors it referenced in ThreatConnect. Relationships that depend on STIX objects should resolve in OpenCTI, and any that do not should be listed with the reason. Run a count comparison of linked objects and spot-check at least one case per priority tier. The step closes when the list of broken or unmapped links is short, documented and accepted by the case owners.
Cut over new investigations
Freeze new case creation in ThreatConnect for the migrated scope, run the final export and import, and reconcile counts against the inventory. Switch analysts and any intake forms or alert integrations to OpenCTI for new investigations, and keep ThreatConnect read-only for the archive period. Confirm with the incident response lead that the first live case in OpenCTI is handled end to end. Tasks that depend on ThreatConnect playbooks need a separate automation tool or manual steps, and those gaps should be listed in the cutover record.
What still needs a separate tool after the move
OpenCTI's case management covers the investigation record, not the response workflow around it. Cases in OpenCTI group intelligence objects, such as incidents, indicators, observables and reports, and can be linked to the knowledge graph. The functions that teams often rely on in ThreatConnect for running response work, including task assignment to named responders, approval steps before containment actions, paging of on-call staff, SLA timers and evidence chain of custody for forensic material, should be treated as open questions until you have checked them against the exact OpenCTI release you plan to run. Release versions follow the date-based scheme described in the OpenCTI product life cycle documentation, so the feature set you validate should be pinned to a specific version.
Build a gap register before cutover. For each ThreatConnect case function your analysts use, record who uses it, how often, and whether the function is a data concern (the record itself), a workflow concern (who acts and when), or a forensic concern (proof that evidence was not altered). Confirm each row by testing it in a staging deployment: create a case, assign tasks to two users, attach a file, and check what the audit trail and export show. Ask your OpenCTI support route and the vendor directly which of these are provided by Enterprise Edition features such as audit logs and playbooks, and which are not, because the answer determines whether you need an additional tool or only configuration.
Assign an owner to every gap that remains. Ticketing and service desk tools typically own task assignment, approvals and SLA timers, and a self-hosted ITSM platform is the usual choice when those steps must be audited with the rest of incident handling. Paging belongs to an on-call or alerting tool, and forensic chain of custody usually needs a dedicated evidence store with hashing and access logs, separate from the intelligence platform. Decide these owners with incident response and legal stakeholders, document the handoff of each case between tools, and state which system is the system of record for evidence, since splitting a case across tools without a clear reference is a common source of gaps during an investigation.
Questions buyers ask before replacing ThreatConnect cases
What does replacing ThreatConnect cases with OpenCTI cost?
The cost is mostly people and infrastructure, and only part of it is licensing. OpenCTI Community Edition is licensed under Apache 2.0, so the software itself carries no license fee, while Enterprise Edition is a separate proprietary license you must price with Filigran. Infrastructure recurs every month: the platform, workers, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage such as MinIO. One-time costs include migration scripting for cases, tasks and artifacts, analyst retraining and integration work for any separate playbook or ticketing tool. Ask any quote to split these components, state who pays for each, and separate the one-time work from the annual run cost.
How long does a ThreatConnect case migration to OpenCTI take?
The timeline depends on case volume, how many custom fields and workflows you rely on, and how much of the case history must be preserved. Start by inventorying case templates, task types, artifact types and the intelligence objects each case links to, because mapping those is usually the slowest step. A parallel run, where analysts open new incidents in OpenCTI while old cases stay in ThreatConnect, reduces risk but lengthens the schedule. No duration is fixed here; ask for a timeline in the written scope, based on your own export and a sample migration.
Can our team run the OpenCTI case work without outside help?
A team with container, database and message queue experience can operate OpenCTI, but the platform has several moving parts to own. Plan for skills in Elasticsearch or OpenSearch, Redis 7.1 or later, RabbitMQ 3.11 or later, S3-compatible storage and GraphQL. The documented sizing starts at 2 cores and at least 8 GB RAM for the platform, and 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, with at least one platform node for every 3 workers. Decide who patches, backs up and upgrades the stack before you start, because those tasks recur.
What do the OpenCTI LTS license key and release cadence mean for maintenance?
They determine how often you must upgrade and what you receive between upgrades. Regular releases follow a date-based x.YYMMDD.z pattern and ship from daily to weekly. LTS releases appear about every six months, each supported for one year, so consecutive LTS versions overlap by six months. LTS builds are distributed as container images but require a specific LTS license key, and after a one-month stabilization period they receive only critical bug and security fixes. Confirm with Filigran which license terms apply to your deployment and whether your chosen track matches your change control windows.
Do we need OpenCTI Enterprise Edition for playbooks and audit logs?
Yes, if you need those features as Filigran packages them. The OpenCTI Enterprise Edition documentation lists audit logs, playbooks, organization-based segregation, full text indexing, AI insights and SSO for OpenID, LDAP, SAML, certificate and header authentication. Community Edition does not include those features under its Apache 2.0 license. Before deciding, list the ThreatConnect playbooks you actually run, then check whether a separate automation or SOAR tool, or a scripted connector, can cover them. Confirm current feature availability with Filigran, since editions change.
How does DeployOpen scope a fixed-scope case management migration?
DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. For a case management move, the written scope typically covers the platform design and sizing, deployment in your cloud account, data centers or air-gapped network, mapping of cases, tasks and artifacts, integration with your ticketing or SOAR tools, hardening, backup and documentation. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for each deliverable to be listed separately so you can see what is included and what you retain in-house.
Where the cost of self-hosted case management comes from
The largest recurring cost of self-hosted OpenCTI case management is the infrastructure underneath it, and most of that cost is not the case module itself. OpenCTI's documented dependencies are Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. Each one is a service you size, patch, back up and monitor. The platform needs at least 2 cores and 8 GB RAM, the search cluster needs its own nodes (the documented starting point is 2 cores, 8 GB RAM and 16 GB SSD per node), and the documented guidance is at least one platform node for every 3 workers. Ask your infrastructure team to price these as separate line items on your own hardware or cloud accounts, and ask whether your storage class and backup policy apply to the search index, which holds case data.
Connector and worker operation is the cost people most often miss. OpenCTI's Python workers consume RabbitMQ messages for asynchronous writes, and connectors handle import, enrichment, file extraction, export and stream consumption. Each connector you enable adds compute, credentials to rotate and a failure mode to watch. If your ThreatConnect cases pull in feeds or enrichment, count the connectors that replace them. Analyst time and engineering time are the other large components. Analysts need to learn case templates, tasks and artifact handling, and engineers own the integration work, the scheduled upgrades and the on-call rota. The OpenCTI Enterprise Edition, licensed under its own proprietary license, adds features such as audit logs, playbooks, organization-based segregation and SSO options, so decide early whether you need them and request the license terms in writing.
Separate one-time work from recurring work when you build the budget. One-time costs include the design of case mapping, migration of open cases and artifacts, integration with your ticketing or SOAR tool, and testing of incident response runbooks. Recurring costs include hosting, storage growth, upgrades, security patching and support. Non-LTS OpenCTI releases ship from daily to weekly, while LTS releases occur every 6 months and are supported for 1 year, so an LTS track reduces upgrade frequency but still needs a planned maintenance window every cycle. When you request quotes from integrators or support providers, ask for the written scope, the upgrade and backup responsibilities, who handles incident escalation, and which items are fixed price and which are billed as time and materials.
Risks to plan for before cutting over cases
Moving cases is less about the copy and more about what the copy loses or duplicates. The five risks below cover history, attachments, analyst habits, duplicate records, edition gaps and upgrade work, and each one has a mitigation a named owner can carry out before the cutover date.
Losing case history and attachments
ThreatConnect cases carry comments, task status, assignments and file attachments, and an export may keep some of these as flat text or drop them altogether. Before any bulk load, run a sample of closed and open cases through the export and confirm that timestamps, authors, task states and each attachment survive in OpenCTI or in an archive. Decide in advance which closed cases must be retained as read-only records and where they will be kept.
Changing analyst workflow
Analysts who have worked in ThreatConnect's case screens will find OpenCTI's incident response views organized differently, and tasks may not map one to one. Run a walkthrough with two or three analysts using a copy of a real closed incident, and write down each step where the old tool did something implicit. Plan a short period where both tools are open side by side so the team does not improvise a workaround under pressure.
Duplicate records across tools
If new cases are opened in OpenCTI while old ones remain open in ThreatConnect, the same incident can exist twice, with different owners and different indicator sets. Set a freeze date after which no new cases are opened in ThreatConnect, and agree on one reference format, such as a shared case identifier kept in both systems, so that a responder searching either tool finds the same record. Audit for duplicates after the first two weeks.
Edition gaps for playbooks and audit logs
Audit logs, playbooks and organization-based segregation are listed as OpenCTI Enterprise Edition features, and the Community Edition is licensed under Apache 2.0. If your ThreatConnect playbooks or audit trail requirements depend on these capabilities, confirm with Filigran whether the Community Edition meets them or whether an Enterprise license is needed, and check the OpenCTI Enterprise Edition License terms. Where playbooks are not covered, assign a separate automation tool before cutover.
Upgrade pressure from release cadence
OpenCTI publishes regular releases that ship from daily to weekly, plus LTS lines every six months with one year of support each. Running a non-LTS version in production means frequent upgrades, while LTS releases require a specific license key and receive only critical bug and security fixes after the first month. Choose the release track before cutover, schedule an upgrade test environment, and budget staff time for it as a recurring task.
How DeployOpen scopes and delivers case management replacement
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For case management, that means mapping your ThreatConnect case, task and artifact workflows to OpenCTI and agreeing in writing which parts of the investigation process move and which stay in a separate tool.
How we scope
- Inventory the ThreatConnect cases, task templates and artifact types your analysts use today, with examples from recent investigations.
- Map each case field, task state and linked intelligence object to an OpenCTI equivalent, and record every gap in the written scope.
- Agree in writing which playbook steps move to OpenCTI connectors and which need a separate automation or incident response tool.
How we build
- Deploy OpenCTI with its dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage) in your own cloud accounts, data centers or air-gapped network.
- Configure organizations, markings and authentication such as OpenID, LDAP or SAML, using the features your chosen edition supports.
- Build and test the case import, linking and connector paths against sample investigations before any live analyst work moves across.
How we hand over
- Document the case mapping, configuration, connector versions and the runbook for analysts working in the new workflow.
- Run a walkthrough with analysts and incident responders on representative cases, and record the open items that remain.
- Provide the evidence your internal audit or external assessor will ask for, while leaving the assessment itself to them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately from the build.
- Plan upgrades around OpenCTI's release model, including LTS lines that require a specific license key for use.
- Confirm your backup, restore and security testing schedule as part of the retainer scope agreed before work starts.
