Which open-source tools replace XSOAR Threat Intelligence Management?
If your threat feeds, indicator scoring and distribution to controls sit inside Cortex XSOAR, a renewal, licensing change or data residency rule forces you to decide where that intelligence lives next. OpenCTI and MISP together cover most of the Threat Intelligence Management module, but Unit 42 intelligence is not part of either. OpenCTI, built on a STIX2-based knowledge schema with a GraphQL API, handles the knowledge graph side: relating threat actors, campaigns, malware and observables to each other and to the MITRE ATT&CK framework. MISP handles indicator sharing and distribution: collecting attributes, correlating them, and exporting them to formats such as Suricata, Snort, Zeek and RPZ. The split between the two is the main design decision, and it should be made before any feed is migrated.
Start by listing every XSOAR feed integration and every place an indicator leaves the platform, such as a firewall block list, an EDR watchlist or a partner share. Map each one to either OpenCTI (analysis and context) or MISP (exchange and control export). Many teams run both, connecting them through the OpenCTI MISP connector, but you should confirm the current connector behavior and supported versions with the vendor documentation before you commit. Also confirm what XSOAR-side scoring you rely on today, since neither tool reproduces a single built-in reputation score by default. Scoring rules will need to be defined and tested against known-good and known-bad indicators in your own environment.
Without Unit 42 content, expect to replace managed intelligence with feeds you select and contract for yourself, and to accept a different kind of coverage. Ask each feed provider for licensing terms that allow your intended storage and sharing. Also plan for the operational footprint: OpenCTI requires Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and MISP runs on PHP with MySQL or MariaDB and Redis. Check the current OpenCTI product life cycle for LTS license requirements before choosing a version line, and check the MISP download page for the recommended release, since MISP 2.4 is end of life.
How each XSOAR threat intel capability maps to open source
This table maps each threat intelligence capability named for Cortex XSOAR Threat Intelligence Management to OpenCTI, MISP, or a gap you must build or confirm. Read the coverage column first, since it flags where Unit 42 content, indicator scoring and incident linking need your own design work. The main takeaway is that the open-source platforms cover the intelligence store and sharing well, but the vendor-specific content and the XSOAR-to-incident glue are yours to build.
| Capability | OpenCTI | MISP and coverage notes |
|---|---|---|
| Threat data tied to incidents | Models threats, indicators and campaigns on a STIX2-based schema, with links to case objects. Incident handling itself lives in a separate tool such as TheHive. | Stores attributes and events, but incident tracking is outside MISP. Build the link between MISP events and your case system and confirm the case tool you choose supports it. |
| Feed ingestion | Import connectors pull external feeds into the platform. Coverage depends on which connectors you deploy and maintain. | Ships default intelligence feeds and supports feed import. Confirm each feed's license terms before ingesting it into a shared instance. |
| Hundreds of feed integrations from a marketplace | No single marketplace count is supplied for OpenCTI. Connectors are community or vendor-built and must be inventoried individually. | No equivalent catalog. Expect to write or adapt feed fetchers for each source you need. Ask each feed owner about API access and rate limits. |
| Automated distribution of intelligence | Stream consumption and export connectors can push data to other tools. Test each target before relying on it. | Automatic synchronization between MISP instances and trusted communities, with distribution levels and sharing groups down to individual attributes. Strong fit for sharing. |
| Indicator scoring logic | Confidence and scoring fields exist in the data model, but the scoring rules you apply are a design decision. Confirm how enrichment connectors write scores. | Correlation finds exact matches and advanced patterns, including fuzzy hashes and CIDR overlaps. Scoring policy for your controls must still be defined by your team. |
| Native Unit 42 intelligence access | Gap. No Unit 42 content is included. You must license or source equivalent intelligence separately. | Gap. Unit 42 content is not included. Replace it with the feeds and communities your organization is entitled to use. |
| Pushing indicators to controls | Export connectors can feed downstream tools. Build and test the path to each firewall, EDR or SIEM you run. | Exports MISP JSON, STIX 1 and 2, CSV, Suricata, Snort, Zeek and RPZ formats, plus an API with restSearch. Confirm each control accepts the format you pick. |
| Playbook-level enrichment in XSOAR | Gap. Enrichment steps must be rebuilt in your automation tool, such as Shuffle, calling the OpenCTI GraphQL API. | Gap. Enrichment steps must be rebuilt in your automation tool, calling the MISP API through PyMISP or the OpenAPI description. |
OpenCTI, MISP and when each fits
OpenCTI and MISP solve different parts of the threat intelligence job that XSOAR Threat Intelligence Management covers. OpenCTI models intelligence as connected knowledge, while MISP is built to collect, correlate and share indicators quickly. Many teams run both, so the decision is less about picking one and more about which role each plays in your workflow.
OpenCTI as the knowledge graph
OpenCTI stores intelligence in a schema based on the STIX2 standards, so threat actors, campaigns, malware, indicators and reports link to each other as a graph. It exposes a web application and a GraphQL API, and it can use the MITRE ATT&CK framework through a dedicated connector. It fits teams that need analysts to understand relationships between actors and campaigns, and that will build their own queries and dashboards. Check the Enterprise Edition license before relying on features that sit outside the Apache 2.0 Community Edition.
OpenCTI Enterprise Edition caveat
The OpenCTI Community Edition is licensed under Apache License 2.0, but the Enterprise Edition uses a proprietary license. Confirm with the vendor which capabilities your requirements need and whether they fall under the Community Edition or the Enterprise Edition. LTS releases also require a specific LTS license key, so ask about key issuance, renewal and support terms before you commit to a release line. Budget for the stack OpenCTI depends on, including Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage.
MISP as the indicator exchange
MISP is built to collect, store, distribute and share cyber security indicators. Its correlation engine finds relationships through exact matches and advanced patterns, including fuzzy hashes and CIDR overlaps, and its sharing model applies distribution levels and custom sharing groups down to individual attributes. It fits SOCs that exchange indicators with peers, ISACs or trusted communities, and that need fast indicator distribution to controls. Its license is GNU AGPL version 3, so review your obligations if you modify and host it for others.
MISP export formats and PyMISP
MISP exports MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ formats, which covers most detection and blocking controls that consume indicators. Its API is described in OpenAPI and includes restSearch, and the bundled PyMISP library lets automation scripts push and pull indicators. Confirm that each of your enforcement points accepts the format you plan to use, and test the export output against them. Taxonomies and galaxies carry their own CC0 or BSD licenses, separate from the AGPL software.
Running OpenCTI and MISP together
The two platforms are often run together and integrate with each other, with MISP feeding indicators and events into OpenCTI for graph analysis while OpenCTI supports the analyst workflow. Decide which platform is the system of record for each indicator type before you connect them, to avoid duplicate or conflicting data. Ask the integrating team to document the connector, the direction of sync and the sharing rules that apply to each data flow. Treat this as a design decision that needs an owner, not a default setup.
Running OpenCTI and MISP next to the rest of XSOAR
In this pattern XSOAR remains the incident and playbook system, and intelligence management moves to a separate platform. Analysts keep their existing layouts, war room and playbooks, while indicators are pulled from OpenCTI or MISP through an API or a connector and written into XSOAR as indicators or enrichment results. This is the lowest-disruption route when the main gap is feed handling and scoring rather than case work.
- Indicator writes: Confirm whether your XSOAR version can create or update indicators through the integration you choose, and whether the write uses a bulk import or one call per indicator.
- Scoring ownership: Decide whether the score comes from the intel platform, from XSOAR reputation logic, or from both, and document which one wins on conflict.
- Enrichment lookups: Confirm the query path for playbooks that need a live lookup during an incident, including timeout behavior.
- Deduplication: Check how repeated indicators from several feeds are merged so analysts do not see duplicate entries.
- Content transfer: Verify which custom integrations and scripts you still depend on, since they stay in XSOAR regardless of where intelligence lives.
Before committing, confirm each integration against the current XSOAR documentation for your release, not against this summary.
Running OpenCTI alone suits teams that want a STIX 2 knowledge graph for relationships between threat actors, campaigns, malware and indicators, with a GraphQL API for downstream tools. OpenCTI is a platform with its own web application, workers, connectors and dependencies, so the operating footprint is the main planning item. The connector model handles feed import and enrichment, and OpenCTI can use MITRE ATT&CK through a dedicated connector.
- Dependencies: Plan for 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.
- Sizing: The deployment overview documents 2 cores and at least 8 GB RAM for the platform, and at least one platform node for every 3 workers.
- Release track: Choose between regular releases and the LTS line, noting that LTS releases require a specific license key.
- Push to controls: OpenCTI exports data through connectors, so confirm which export connector feeds your firewalls, EDR or SIEM and whether it supports your indicator types.
- Authentication: Confirm the identity option you will use for the platform against the authentication documentation.
Confirm whether your XSOAR playbooks can query OpenCTI directly or need an intermediate service before you size the stack.
Running MISP alone fits teams whose main need is collecting and sharing indicators with peers, sector communities or CERTs. MISP is a PHP application with MySQL or MariaDB and Redis, and it exposes an OpenAPI-described API with restSearch and the PyMISP library. Its distribution levels and sharing groups control how far each attribute travels, which matters when intelligence comes from partners under agreements.
- Version choice: MISP 2.5 is the recommended version for new deployments, and 2.4 is end of life with security fixes only, so do not start new instances on 2.4.
- Installation: The project lists an Ubuntu 24.04 installer, Docker images, Ansible roles, Puppet and RPM packages. Pick the one your operations team already supports.
- Export formats: Confirm that the format your enforcement points need, such as Suricata, Snort, Zeek, RPZ or CSV, is available and maintained for your use.
- XSOAR connector: Confirm the MISP integration version available for your XSOAR release, its supported actions and whether it writes events or only reads attributes.
- Sharing terms: Review distribution and sync settings with legal and partner owners before enabling automatic synchronization.
MISP's own download and features pages are the right next read for version and format details.
Many teams run both: MISP ingests and shares community indicators, while OpenCTI holds the structured graph and ATT&CK context used by analysts. OpenCTI integrates with MISP, but the mapping between MISP events and OpenCTI objects is a design decision you must test, not a default you can assume. One platform should be the system of record for each indicator, or the same indicator will carry two scores.
- System of record: Decide which platform owns indicator lifecycle, expiry and revocation, and which one only forwards.
- Mapping: Test how MISP attributes, tags and galaxies land in OpenCTI objects, including how STIX 2 fields are populated.
- Feedback loop: Confirm whether a revoked or whitelisted indicator in one platform propagates to the other.
- Operating load: Two stacks mean two upgrade cycles, two backup jobs and two sets of dependencies to monitor.
- Connector path to XSOAR: Decide whether XSOAR reads from one platform, both, or a unified export, and confirm that choice in the integration documentation.
Document the system of record before you build the sync, because it determines every later support decision.
However the intel platforms are split, indicators reach XSOAR playbooks and enforcement controls through three paths: a query API called from a playbook, a connector that imports indicators on a schedule, or an export that publishes a list to a control such as a firewall, proxy or EDR. Each path has different latency, failure and ownership characteristics. Treat every path as something to verify in your environment rather than something this page can certify.
- Query path: Confirm the API permissions, rate limits and response size for the lookup your playbook makes during an incident.
- Scheduled import: Confirm the polling interval, how removed indicators are handled, and what happens when the source is unavailable.
- Control push: Confirm the export format, update frequency and whether the control accepts incremental updates or needs full replacement.
- Identity and secrets: Confirm which service accounts hold API keys, where those keys are stored and how they are rotated.
- Audit trail: Confirm that indicator changes and pushes are logged in a form your auditors can review.
For each path, ask the vendor or community for the documented behavior on your exact release and test it end to end before relying on it.
What changes when Unit 42 content is no longer built in
The main change is that native Unit 42 intelligence stops arriving inside the platform. In Cortex XSOAR Threat Intelligence Management, Palo Alto Networks describes native access to Unit 42 intelligence alongside breadth from hundreds of feed integrations in the Cortex Marketplace. Without it, you need a deliberate plan for where indicators, actor profiles and campaign context come from. Start by listing which Unit 42 data your playbooks and enrichment steps actually call, and which feeds are only used for dashboards. That inventory tells you how many sources you must replace and which ones are critical to detection.
Open-source replacements cover the structure and sharing of intelligence more than the content itself. MISP ships default intelligence feeds, shareable taxonomies, warning lists and MISP galaxies covering threat actors, malware, ransomware, tools and MITRE ATT&CK. OpenCTI brings its own connectors for importing, enriching and exporting data, and it can use the MITRE ATT&CK framework through a dedicated connector. Confirm which default feeds are enabled in your MISP build and which OpenCTI connectors you will run, since neither gives you the proprietary Unit 42 reporting.
For proprietary or commercial content, the decision sits with you. Any commercial or community feed you add must be licensed directly with its provider, and terms differ on internal use, sharing with partners, caching, retention and redistribution. Ask each provider whether the license covers self-hosted ingestion into MISP or OpenCTI, whether it limits how indicators may be shared through MISP sharing groups, and what happens to the data when you stop paying. Record those answers before you cut over, because a feed you cannot lawfully store or share is not a replacement.
Moving indicators, feeds and incident links out of XSOAR
This sequence moves threat intelligence feeds, scoring logic and incident references from Cortex XSOAR into OpenCTI and MISP while XSOAR keeps running, so each feed can be checked against the old output before cutover. The end state is a documented intelligence pipeline that your analysts and controls can rely on without the XSOAR runtime.
Inventory feeds, indicators and integrations
The threat intelligence lead exports a list from XSOAR of every feed integration, the indicator types each one supplies, the reputation or scoring rules applied to them, and the playbooks or jobs that read those indicators. Record which Unit 42 content is in use, because it will need an open-source or commercial replacement feed. The list is complete when every active feed has an owner, a destination (OpenCTI, MISP or retired) and a named consumer.
Export custom content from XSOAR 8
Using the XSOAR 8 export path under Settings, Server Settings, Custom content, export all custom content, and downloading individual playbooks from the content item menu, the automation engineer saves scripts, playbooks and integration configurations into a version-controlled repository. Confirm the export contains every scoring script and indicator playbook from the inventory. Expect the export to hold the logic, but not the XSOAR runtime that executes it, so each script is tagged for rewrite or retirement.
Stand up OpenCTI and MISP
The platform team deploys OpenCTI with its dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage) and MISP on Ubuntu 24.04 using the project installer, inside your own infrastructure. Confirm sizing against the OpenCTI deployment overview and choose an LTS line for production, noting that LTS releases require a specific license key. The step is done when both platforms answer through their web interfaces and API, and backups for each are tested.
Re-point feeds to the new platforms
The integration engineer connects each inventoried feed to OpenCTI connectors or MISP feed and synchronization settings, and checks that indicator types, timestamps and confidence fields arrive intact. Where a feed has no connector, the team decides whether to write one or drop it. The output is a feed-by-feed table showing source, destination, ingestion status and last successful import.
Rebuild scoring and distribution rules
The threat intelligence lead rewrites each XSOAR scoring rule as an explicit decision in OpenCTI or MISP, covering indicator confidence, expiry, distribution level and the sharing groups that may receive each event. Use MISP distribution levels and sharing groups to control who sees what, and MITRE ATT&CK mappings from OpenCTI or MISP galaxies for context. The step closes when a reviewer has signed off each rule against the original XSOAR logic, with differences recorded.
Reconnect incident references and controls
The SOC engineer maps each XSOAR incident field that holds an indicator or intelligence reference to an identifier in OpenCTI or MISP, then rebuilds the push path to blocklists, firewalls, EDR or SIEM lookups using the platforms' APIs or export formats such as STIX, CSV or Suricata. Confirm that a test incident displays linked intelligence and that a test indicator reaches each control. The output is a list of pushes that work end to end and a list of pushes still open.
Run old and new feeds in parallel
For a period agreed by the SOC and the business owners, XSOAR and the new platforms ingest the same feeds, and the team compares indicator counts, scores and control actions daily. Investigate every mismatch and record whether it is a defect, a deliberate change or a feed gap. Cutover is ready only when the disagreements are explained and accepted in writing, and the XSOAR-side logic that cannot run elsewhere has a documented replacement or retirement decision.
Cut over and retire XSOAR feed jobs
The team disables XSOAR feed integrations and indicator jobs in a single change, keeps the XSOAR export and read-only access for audit, and updates runbooks to point analysts at OpenCTI or MISP. Confirm that no playbook still calls a disabled feed and that the feed owners have accepted the new source. The step is done when the change record is closed and the retirement evidence is stored with the exports.
What OpenCTI and MISP need to run in your environment
Running OpenCTI yourself means operating a small platform of its own. The OpenCTI platform serves the web interface and GraphQL API, and Python workers consume RabbitMQ messages so that writes happen asynchronously. Connectors for import, enrichment, file extraction, export and stream consumption run alongside them. Redis (7.1 or later) and RabbitMQ (3.11 or later) are required dependencies, and the search layer is Elasticsearch (8.0 or later) or OpenSearch (2.9 or later). Attachments and exports need S3-compatible storage such as MinIO. The deployment overview documents a minimum of 2 cores and 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for the search service, and at least one platform node for every 3 workers. Treat those figures as the floor. Ask your team to size the search and storage tiers against the indicator volume and the feeds you plan to ingest, and confirm the worker count with the connector list you intend to run.
MISP has a different footprint. It is built on PHP with CakePHP, uses MySQL or MariaDB for storage and Redis for caching and background work, and is licensed under the GNU AGPL version 3. The project recommends MISP 2.5 for new deployments and states that 2.4 is end of life with security fixes only, so new installs should start on 2.5. The recommended platform is Ubuntu 24.04 with the provided installer, although Docker images, Ansible roles, Puppet and RPM packages are also listed. Recent 2.5 point releases introduced a new database migration system with PostgreSQL support, so check that your chosen database path matches the release you deploy before committing to a configuration.
Upgrade planning is where most ongoing effort sits. OpenCTI uses date-based versions, and non-LTS releases ship from daily to weekly. Its LTS releases arrive every six months, each supported for one year, and require a specific LTS license key even though they are distributed as container images. After a one-month stabilization period, an LTS line receives only critical bug and security fixes. Decide early whether you run the LTS line for stability or track regular releases, and confirm with Filigran which license key applies to your edition. MISP has no LTS license, but its own release history means you should schedule upgrades against the 2.5 point releases and the project's security notices, and keep a tested rollback for database migrations.
Questions buyers ask before replacing XSOAR threat intel
What drives the total cost of replacing XSOAR threat intelligence with OpenCTI and MISP?
The cost comes from four components: the servers for each platform, staff time to integrate and operate them, paid feeds or enrichment sources you choose to keep, and any commercial edition you decide you need. The open-source software itself carries no license fee for the Community Edition of OpenCTI or for MISP. OpenCTI's documented sizing calls for at least 2 cores and 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, plus RabbitMQ, Redis and S3-compatible storage, so infrastructure grows with feed volume and worker count. Ask any implementation partner for a quote that separates one-time build work from recurring operations and upgrades, and that states which feeds and enrichment sources are assumed.
Do I need OpenCTI Enterprise Edition to replace XSOAR threat intelligence?
Not necessarily, but you need to check the features your team depends on before deciding. The Community Edition is licensed under Apache License 2.0, and MISP is licensed under AGPL version 3, so both can run without a license fee. OpenCTI's Enterprise Edition uses a proprietary license, and its feature set is documented separately, so confirm with Filigran or the documentation which capabilities you would need that only appear there. Treat that check as part of scoping, before you commit to a feature list in a quote.
Are OpenCTI LTS releases free to run in production?
LTS releases are not handled the same way as regular releases. OpenCTI LTS builds are distributed as container images but require a specific LTS license key to use, so confirm with the vendor which key your deployment needs and who holds it. After a one-month stabilization period, LTS releases only receive critical bug and security fixes, and LTS branches arrive every 6 months with each supported for 1 year. Build the key request, renewal and upgrade schedule into your operating model from the start, because a lapsed or unassigned key can stall an upgrade.
How long does it take to replace XSOAR threat intel with OpenCTI and MISP?
The duration depends on how many feeds, enrichment steps and incident links you need to rebuild, and on how much of the existing content is documented. A rough inventory of your current XSOAR feed integrations and indicator-scoring rules is the first step, because it sets the size of the work. Most of the time goes to feed mapping, validating indicator scores against past incidents, and building the connectors that push indicators to your controls. Ask for a written timeline tied to a defined scope, and ask how the partner will run MISP and OpenCTI side by side with XSOAR until the outputs match.
What does my team need to provide for an OpenCTI and MISP project?
Your team needs to supply the people and decisions that only your organization can make. You will need a list of current XSOAR feeds, playbooks that enrich or score indicators, and the controls that consume indicators, such as firewalls, EDR and SIEM. You will also need an owner for scoring policy, a decision on distribution levels and sharing groups in MISP, and access to the infrastructure where the platforms will run. Ask the partner to name these inputs in the written scope so you know early where your team's time will go.
Can my own SOC team replace XSOAR threat intelligence without an outside partner?
Yes, a capable team can do it in-house, but it should plan for the skills involved. Deploying OpenCTI needs experience with Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage, and MISP needs PHP, MySQL or MariaDB, and Redis. Connector development, STIX2 mapping and the correlation rules you rely on for scoring are specialist work. Consider whether your team can cover operations and upgrades after launch, since OpenCTI LTS and MISP 2.5 both move on fixed release cycles that someone must track.
What happens to Unit 42 intelligence when I leave XSOAR?
Unit 42 intelligence is part of XSOAR Threat Intelligence Management and is not available in OpenCTI or MISP by default, so you will lose that native access when you move. Plan to replace it with the feeds your organization is licensed for or with open sources you can verify, and document which indicators came from which source so analysts can judge their quality. Review your contractual terms with Palo Alto Networks about how intelligence and data may be used after the subscription ends, and ask your legal team to confirm those terms before you cut over.
Does the replacement meet the security and compliance evidence my auditors ask for?
The platforms can produce the logs, access records and configuration history that auditors usually request, but the evidence depends on how you configure them. Confirm which authentication method you will use, such as OpenCTI's supported authentication options or the MISP OIDC plugin, and document access reviews for both platforms. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification, so ask your auditor which evidence they will accept before you finalize the design.
How DeployOpen scopes and delivers a threat intel replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a replacement of the Threat Intelligence Management capability, we start from the written scope, then build OpenCTI and MISP in your environment, wire them to your existing controls, and hand over the runbooks your analysts need.
How we scope
- Inventory the XSOAR threat intel feeds, indicator sources and enrichment integrations currently in use
- Agree which intelligence must link to incidents and which controls need pushed indicators
- Confirm where OpenCTI and MISP will run, including cloud accounts, data centers or air-gapped networks
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
How we build
- Deploy OpenCTI with its search, cache, message queue and object storage dependencies sized to the written scope
- Configure MISP instances, sharing groups and feed ingestion that match your distribution rules
- Build connectors that push selected indicators to firewalls, EDR or SIEM controls under your approval
- Test ingestion, scoring and export paths against sample data before any production feed is switched on
How we hand over
- Document architecture, configuration, feed lists, scoring rules and indicator export procedures
- Provide the evidence and control records that your compliance assessors may request, without issuing any attestation
- Walk analysts and engineers through daily triage, incident linking and removing stale indicators
- Deliver a clear list of what Unit 42 content no longer provides and how your team will cover those gaps
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan OpenCTI and MISP upgrades against their published release lines and end-of-life dates
- Re-test integrations and feeds after upgrades or changes to your security stack
- Agree support scope, response expectations and renewal terms in writing before a retainer starts
