Migrate from Anomali ThreatStream to MISP

Migrating from ThreatStream to MISP: what the move involves

A team leaving ThreatStream for MISP should expect two different kinds of work. Indicators and feed subscriptions move through exports and re-subscriptions, which are mechanical and can be batched. Partner sharing and integrations must be rebuilt, because sharing agreements, trust relationships and SIEM and firewall connections are configured per platform and do not carry over with the data. Most of the effort sits in the second category, so plan for it first. The work is usually shared across three groups. Threat intelligence staff own the indicator inventory, decide which feeds still matter and define sharing groups and distribution levels in MISP. SOC engineers own the detection side: they re-point SIEM rules, blocklists and firewall feeds at MISP outputs and test that alerts still fire. Platform engineers install, harden and back up the MISP instance, configure authentication and manage the upgrade path, including the MISP 2.5 installation choice. Ask any implementation partner to name who fills each role on the client side, because a migration stalls when one of these owners is missing. The effort and risk depend mostly on how many integrations and partner relationships exist, how much ThreatStream export history must be kept, and how many feeds need a replacement source. Confirm each of these in your own environment before scoping. Because the move touches live detections and external sharing, DeployOpen plans it as a fixed-scope engagement with deliverables, cutover steps and acceptance checks agreed in writing before work starts. Ask for a written scope that lists each integration, each partner feed and the test that proves it works.

Which ThreatStream capabilities map to MISP, and what needs rework

This table maps each ThreatStream capability to its MISP equivalent and marks it as clean, needs rework or gap. Use the status to plan effort: clean items can move with configuration, rework items need mapping or client changes, and gaps need a decision before cutover. The main takeaway is that indicator exchange maps well to MISP, while analysis-heavy workflows and partner trust groups need the most planning.

ThreatStream capability	MISP equivalent	Status
Indicator storage and search	Events and attributes with tags, searchable in the web interface and through restSearch	Needs rework: map observable types and tags to MISP attribute types and tags
Export formats	MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ	Clean: confirm which STIX version each partner and tool expects
Feed ingestion	Default feeds and custom feed configuration in MISP	Needs rework: re-subscribe to each provider, since ThreatStream subscriptions do not carry over
Correlation	Correlation engine with exact matches, fuzzy hashes and CIDR overlaps	Clean for IOC matching: confirm whether ThreatStream confidence logic needs a separate equivalent
Distribution and sharing groups	Distribution levels and sharing groups down to individual attributes, with instance synchronization	Needs rework: recreate partner trust groups and test synchronization with each partner
REST API	OpenAPI-described API with restSearch and the PyMISP library	Needs rework: rewrite client calls, authentication and pagination in each integration
SIEM and firewall outputs	Suricata, Snort, Zeek, RPZ and CSV exports consumed by pull or scheduled jobs	Needs rework: re-point each pull to a MISP export and confirm SIEM and firewall parsers
Threat models, actors and campaigns	Galaxies for threat actors, malware, tools and MITRE ATT&CK, without a full STIX relationship graph	Gap for analysis-heavy use: plan for OpenCTI if relationship modeling is required

What data moves, and which integrations must be rebuilt

A ThreatStream to MISP move is not a single export. Indicators, feeds, partner sharing and downstream consumers each follow a different path, and each has its own failure mode. Plan them as separate workstreams with their own verification steps.

Indicators exported in batches

Export observables from ThreatStream in batches sized to the per-format caps in its export guide, since a single large export may be truncated. Confirm the exact limit for each format you use before you start, because the limits differ by format. Map the ThreatStream fields to MISP attributes deliberately: tags, confidence and expiry often do not carry across one to one, so decide whether each maps to a MISP tag, an attribute flag, or a field you drop. Reconcile record counts per batch against the source before you import anything into production.

Open feeds and TAXII sources

Inventory every feed and TAXII collection ThreatStream polls, including any premium feeds your subscription covers. Recreate each one in MISP as a feed or TAXII source, and confirm that the provider's terms allow redistribution to your MISP instance and to any partners you share with. Some commercial feeds do not permit this, so ask the provider in writing before you enable sync. Disable the ThreatStream feed in parallel for a short overlap period, then compare event volumes and indicator counts from both sources.

Partner and ISAC sharing groups

Partner and ISAC sharing in ThreatStream does not move automatically. Rebuild each trust relationship in MISP using sharing groups, distribution levels and sync settings that match what each partner received before. Agree the new configuration with each partner, since their own instance may need a new sync key and organization record. Test with one partner first and confirm that events arrive with the expected distribution and that restricted content stays restricted.

SIEM and firewall consumers

SIEM rules, EDR watchlists and firewall blocklists usually pull from ThreatStream through its own connector or a scheduled export. Re-point each consumer to a MISP output, such as a CSV, Suricata or Snort rule export, or to the REST API using restSearch through PyMISP. Confirm the field names and value formats each consumer expects, since a mismatch can silently drop matches. Keep the old feed running until each consumer has produced expected alerts against the new source.

The migration sequence from inventory to decommission

This sequence moves indicators, feeds, partner sharing and integrations from ThreatStream to MISP without a gap in detection coverage. Each step closes with a written output, so the team can show what was moved, what was checked and what was switched off, and when.

Inventory indicators, feeds, partners and integrations
The threat intelligence lead, with the SOC and detection engineering teams, lists every ThreatStream input and output: the feeds and TAXII collections subscribed to, the indicator sets and tags in active use, the sharing groups and partners who receive or send intelligence, and each SIEM, firewall, EDR or ticketing integration that consumes ThreatStream data. Record the export formats each consumer expects, since MISP's output formats differ from ThreatStream's. The step is done when every consumer has an owner and a target format, and the owners have signed off the list. The output is a migration register that all later steps use as their checklist.
Stand up a pilot MISP 2.5 instance
The platform team installs MISP 2.5 in a test environment inside the organization's own infrastructure. The MISP download page recommends Ubuntu 24.04 with the provided installer for MISP 2.5, and also lists Docker images, RPM packages, an Ansible role and a Puppet module, so choose the option your team can operate and patch. Confirm the current release notes on the MISP GitHub releases page before installing, and do not deploy new MISP 2.4 instances. Configure authentication, backups and logging before any data arrives. The step is done when the pilot passes a documented health check and an administrator can log in through the chosen identity method.
Import and validate a sample batch
Export a representative batch from ThreatStream in the formats the register lists, keeping each file within the per-export limits you confirm in ThreatStream's documentation. Import the batch into the pilot, then compare attribute counts, types, tags, timestamps and distribution settings against the source. Run a sample of indicators through the correlation engine and check that known matches still appear. The threat intelligence analyst signs off on the discrepancies. The step is done when the mismatch log is empty or every entry has an accepted explanation, and the output is a validation report attached to the migration register.
Subscribe feeds and partners to MISP
Recreate each feed subscription in MISP using its feed or synchronization settings, and set up sharing with partners through MISP's distribution levels and sharing groups. Re-create agreements that govern each sharing group, and confirm that each partner's MISP or TAXII endpoint accepts your instance before enabling it. Keep the feeds in a disabled state until the parallel run in the next step starts. The step is done when every feed and partner in the register has a MISP configuration that is tested but not yet used for production decisions, and the output is a sharing matrix showing who receives what.
Run both platforms in parallel
Enable the same feeds and partner inputs on ThreatStream and MISP for a period agreed in the migration plan. Compare the indicators each platform produces, the alerts each generates in the SIEM and the number of detections that differ. The detection engineering team investigates every gap, whether it comes from a missing feed, a format difference, a correlation rule or a parsing issue. The step is done when the agreed period ends and every discrepancy is resolved or accepted in writing. The output is a parallel run report that becomes the evidence for cutover.
Cut over consumers one at a time
Switch each consumer from ThreatStream to MISP in the order the register sets, starting with lower-risk integrations such as enrichment lookups. Re-point each SIEM, firewall, EDR or ticketing integration to the MISP endpoint or exported file, verify that the consumer receives expected data, and keep the ThreatStream path available until the consumer has run cleanly. Record the change in the register with the date, the owner and the rollback step. The step is done when every consumer in the register runs against MISP and its rollback path is documented. The output is a signed cutover log.
Decommission ThreatStream after retention is met
Confirm with legal, compliance and records owners which ThreatStream data must be retained, for how long and in what form, and check that the export archive is complete and readable. Confirm the retention requirements against your own policies and any contract terms with Anomali, since obligations vary by sector and data type. Revoke ThreatStream API keys, remove integrations, end feed subscriptions and close sharing agreements, then ask Anomali in writing to confirm the termination steps and the handling of retained data. The step is done when the archive is verified, access is revoked and the closure is documented. The output is a decommission record stored with the migration register.

Running ThreatStream and MISP in parallel without duplicate alerts

The core risk in the overlap period is that two platforms raise the same alert or, worse, that one platform silently stops raising it. Before any SIEM or firewall rule changes, decide which system is authoritative for each detection source. A practical pattern is to keep ThreatStream as the alerting source of record while MISP ingests the same indicators in read-only mode, then flip ownership one feed or one integration at a time. Tag or label MISP-originated events so that a SIEM correlation rule can tell them apart from ThreatStream-originated hits, and suppress the duplicate path only after both sides have been compared over a full working cycle of your own choosing.

Sequence the changes so that detections are never removed before their replacements are proven. For each SIEM content item or firewall feed, record the ThreatStream source, the MISP export that replaces it (for example, a Suricata or Snort rule export, a CSV feed or a STIX 2 bundle), and the field names the rule depends on. Then confirm each integration against the current vendor or product documentation for both sides rather than assuming parity. Export formats, field mappings, update intervals and expiry handling differ between platforms, and MISP's OpenAPI-described API and its documented export formats are the starting point for checking them. Keep the ThreatStream integration enabled until the MISP path has produced matching results on known test indicators.

Plan the rollback path before the first switch. Keep ThreatStream feed subscriptions, API credentials and SIEM connectors intact until the decommissioning decision is signed off, and keep a dated copy of each exported configuration in your own change record. Define the trigger for rollback in advance, such as a missed indicator class, a failed sync or a firewall block that cannot be reproduced in MISP. Confirm with your ThreatStream contract owner how long access remains available after the end of your subscription term, since the terms govern what you can still export and how long the old feeds keep running.

What drives migration cost and duration

This table lists the factors that change the effort of moving from ThreatStream to MISP, separating one-time migration work from recurring hosting and maintenance. Read each row as a lever: the driver, why it moves cost or time, and how to reduce it before requesting a quote. Quotes follow from a written scope, so the inventory in each row is what you should bring to that conversation.

Driver	Why it matters	How to reduce it
Indicator volume and export batches	ThreatStream export caps per format force many smaller exports, and each batch needs validation and import into MISP events. Volume drives import time and attribute deduplication work.	Export by date range or tag, deduplicate before import, and confirm the export caps for each format in your own ThreatStream tenant.
Feeds and sharing partners to re-establish	Each TAXII feed, open feed and partner sharing agreement must be re-subscribed or rebuilt as MISP sync or sharing groups. Trust agreements and partner onboarding are often the longest tasks.	Inventory every feed and partner now, retire stale sources, and ask partners early about their MISP or TAXII readiness.
SIEM, firewall and custom API integrations	Each consumer of ThreatStream output (SIEM lookups, firewall block lists, scripts calling its API) must be re-pointed to MISP exports or the REST API and re-tested.	List each integration with its owner, data format and update frequency. Plan to test detections in parallel before cutover.
Degree of ThreatStream customization	Custom tags, workflows, approval rules, observable types and imported third-party data change how much logic must be rebuilt in MISP taxonomies, galaxies and automation.	Export your tag and configuration inventory, and decide which rules still matter before rebuilding them.
MISP hosting model	Server sizing, storage growth, backups, restore testing and version upgrades recur for the life of the platform. MISP 2.5 is the recommended version for new deployments, so upgrade planning is a standing task.	Choose a supported install path, define backup and restore tests, and budget upgrade windows as recurring work.
Internal analyst time	Analysts must validate imported data, tune correlation, and retrain on MISP workflows. This is often the largest cost in practice and is easy to underestimate.	Schedule parallel running with named analysts and define acceptance criteria for imported indicators.
Degree of compliance evidence needed	Regulated teams may need documented data flows, access reviews and change records for the new platform, which adds one-time documentation work.	Agree the evidence list at scoping. Note that DeployOpen prepares evidence, while auditors issue any assessment outcome.

What usually goes wrong in a ThreatStream to MISP move

Most problems in a ThreatStream to MISP move come from data that looks copied but arrives with different meaning, scope or status. The cards below cover the failure points we see most often, each with a check to run before cutover.

Lost context in flat exports

A CSV export keeps the value and a few columns but drops tags, confidence, source attribution and related objects. Once imported, indicators look complete while their reasoning is gone. Before exporting, list every field your analysts rely on, then confirm each one survives in a test import. Use STIX or MISP JSON where relationships matter, and treat CSV as a fallback for simple lists only.

Expired indicators imported as active

Indicators that ThreatStream had already expired can return as live attributes in MISP, where they may trigger blocks or alerts on stale data. Compare the expiry and last-seen fields in the source export with the import settings. Set a decay or expiry policy in MISP before the first sync, and review a sample of imported indicators against their original dates.

Sharing groups with wrong distribution

Recreating partner sharing by hand often sets distribution levels too broadly, so indicators meant for one ISAC reach every synchronized instance. MISP applies distribution at event and attribute level, and the choice is hard to reverse once data has synced. Map each ThreatStream group to a named MISP sharing group on paper first, and have each partner confirm what they should receive before enabling synchronization.

Feed licence terms not carried over

Commercial feeds licensed through ThreatStream usually carry terms on redistribution, retention and attribution that do not transfer to MISP by default. Importing that content into a sharing instance can breach the provider's terms. Collect each feed's current licence from the provider, record who may use it and where it may be shared, and confirm this with your legal or procurement team before re-subscribing.

Firewall rules pointing at stale lists

Firewall, proxy and DNS rules that consume ThreatStream lists keep working until the old feed stops updating, then quietly go stale. Inventory every consumer, including SIEM content and blocklists on endpoints, before the cutover. Point each one at the MISP export or automation endpoint, and watch for a gap in update timestamps during the first days after the switch.

MISP 2.4 installed by mistake

Install guides and older packages can still reference MISP 2.4, which the project no longer recommends for new instances and which receives security fixes only. Standing up a new instance on that line adds an upgrade project on day one. Confirm the target version against the MISP download page, install MISP 2.5 on Ubuntu 24.04 using the provided installer, and record the version in your build documentation.

How the migration differs by team size and starting point

A small team usually has a short list of indicator sources, one SIEM or firewall that consumes them, and little sharing outside the organization. The migration is mostly a matter of getting a clean indicator set into MISP and making sure the detection stack still fires. Because the volume is modest, exports can often be run in a few passes, and the team can verify each pass by hand before moving on. The main risk is assuming the export is complete when it is only the first batch.

Inventory feeds first: List every subscribed feed, manual import and scheduled export, including the ones nobody remembers setting up.
Export in tracked batches: Split exports by date range or feed so each CSV or STIX file stays within the per-export limits and each batch can be counted against the source.
Re-point one consumer at a time: Move a single SIEM rule set or firewall list to MISP output, confirm matches, then move the next.
Decide what to drop: Small teams often carry stale indicators. Retire expired items instead of importing them all.
Use default feeds deliberately: MISP ships with default feeds. Enable only those the team can review and maintain.

Before cutover, confirm with the team's SIEM and firewall vendors which indicator formats and update methods their versions accept.

Questions teams ask before moving from ThreatStream to MISP

How much effort does moving from ThreatStream to MISP take?

The effort depends mostly on how many indicators, feeds, sharing relationships and integrations you run today, and on how many of them need rebuilding rather than copying. Most of the work sits in four areas: exporting indicators in batches, configuring feeds and TAXII sources again in MISP, recreating sharing groups and synchronization with partners, and re-pointing SIEM and firewall integrations to MISP outputs such as the REST API, PyMISP or NIDS exports. Indicator migration is usually the smaller task. Sharing agreements and integration testing take longer because they involve people outside your team. Ask any implementation partner for a written breakdown by these four areas, based on your actual counts.

How long does a ThreatStream to MISP migration take?

The schedule is set by the number of partners whose sharing must be recreated, the size of your export work, and how much change control your SIEM and firewall teams require. No fixed duration applies to every environment, so treat any single figure with caution. Partner onboarding often runs on the partners' timetable rather than yours, which can extend the project. Run ThreatStream and MISP in parallel for a defined period so detections stay current while each integration is switched. Confirm the parallel-run window, cutover order and rollback steps in writing before work starts.

What does the internal team need to provide during the move?

Your team needs people who own the data and the systems it feeds. The main roles are a threat intelligence lead who decides which feeds and indicators stay in scope, a SIEM or detection engineer who knows each rule that consumes indicators, a firewall or network owner who approves changes to blocklists, and someone with authority to sign sharing agreements with partners. MISP is operated by your team after handover, so at least one person should be trained on the MISP admin console, the REST API and synchronization settings. Ask whether the engagement includes documentation and knowledge transfer for each role.

Can our team migrate from ThreatStream to MISP without outside help?

Yes, a capable team can do this internally, especially if the estate is small, the integrations are few and the team already runs security tooling on Linux. The harder parts are the ones teams underestimate: validating that exported indicators keep their types, confidence and expiry, recreating sharing groups with the right distribution levels, and proving detections still fire after each integration change. An outside partner can take on defined deliverables such as the export pipeline, the MISP deployment on Ubuntu 24.04 with the provided installer, integration testing and runbooks, under a fixed scope agreed in writing. DeployOpen implements, integrates, hardens, documents and supports self-hosted platforms in your own infrastructure, and does not operate your ThreatStream account for you.

Do indicators, feeds and sharing transfer intact to MISP?

Indicators can be moved, but they do not arrive as a one-click copy, and some metadata may need mapping. Export from ThreatStream in batches within its per-format limits, check the output format you choose, and import into MISP events and attributes with checks on type, value, tags and expiry. Feeds must be re-subscribed in MISP, since default feeds and TAXII sources are configured separately. Sharing is not transferred automatically: partners must be connected to your MISP instance through synchronization or community sharing and assigned suitable sharing groups. Confirm with Anomali which export formats and limits apply to your account, and confirm with MISP which import behavior applies to each format you use.

What happens to our ThreatStream data retention during the move?

Retention on ThreatStream is governed by your contract and Anomali's own terms, not by the migration itself, so confirm in writing how long Anomali keeps your data after subscription changes and how you request deletion or a final export. Keep an archive of the exports you take, store it under your own retention policy, and record which indicators were imported, when, and with what sharing settings. Your compliance lead should review where the archive lives, who can access it and how long it stays, particularly if the data came from partners who set their own handling rules. Ask Anomali for a documented end-of-service data process before you cancel anything.

Is MISP ready for us if we need data to stay on our own servers?

MISP is open source software licensed under AGPL-3.0 that you deploy in your own infrastructure, so indicators, events and sharing data stay on servers you control. The project recommends MISP 2.5 for new deployments and lists Docker images, RPM packages, an Ansible role and a Puppet module alongside the Ubuntu installer. MISP 2.4 is end of life, so new installs should not start there. Decide early whether you need an air-gapped deployment, since feed updates must then be moved across the gap, and confirm with MISP support which database and platform options fit your standards.

Official MISP sources for the migration

Start with the MISP download page before you plan the installation. It recommends Ubuntu 24.04 with the provided installer for MISP 2.5, lists Docker images, RPM packages, an Ansible role and a Puppet module as alternatives, and states that MISP 2.4 is end of life with security fixes only. If your pilot will run on a different base operating system or container platform, confirm the supported path on that page and note any gap for your platform team to close. The MISP download page is the reference for install choices, and the MISP GitHub repository is where you will find configuration templates and the installer source.

For format and integration questions, read the MISP features page against your ThreatStream export inventory. It lists the export formats MISP supports, including STIX 1 and 2, CSV, OpenIOC and the NIDS formats for Suricata, Snort and Zeek, and it describes the REST API and PyMISP library that your SIEM and firewall integration owners will need. Check each format your current integrations consume, because the mapping work is what determines whether a re-pointed integration behaves the same way. The MISP GitHub releases page and the MISP support page cover release-specific changes and where to ask questions.

Before the pilot, check the exact version, database option and upgrade notes against the release notes on the GitHub releases page, since the project publishes point releases often. The pillar facts mention a PostgreSQL option introduced with a new database migration system, so confirm whether your team will use MySQL or MariaDB or PostgreSQL before any data load. Record the version you test with in the pilot plan, and repeat the release check before production cutover so that the sharing and integration tests run on the build you will actually operate.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that applies to a move from ThreatStream to MISP. We agree scope, deliverables and timelines in writing before work starts, so indicator export, feed re-subscription, partner sharing and SIEM and firewall re-pointing are all defined up front.

How we scope

Inventory every ThreatStream feed, export job, TAXII subscription, sharing relationship and downstream integration in use.
Confirm which export formats and per-format result limits apply to your current ThreatStream account and tenant.
Agree in writing which SIEM, firewall and endpoint consumers will be re-pointed to MISP, and who owns each cutover.

How we build

Deploy MISP in your cloud account, data center or air-gapped network, using the installer, Docker, Ansible or Puppet path your standards allow.
Script batched exports and imports, then reconcile record counts and attribute types against the source before each cutover.
Rebuild sharing groups, distribution levels and feed subscriptions in MISP, and test NIDS exports against your Suricata, Snort or Zeek sensors.

How we hand over

Deliver configuration, runbooks, integration maps and the reconciliation evidence gathered during the migration.
Document the sharing agreements and synchronization settings so partner administrators can verify their own side.
Walk your operations team through daily feed management, correlation review and the decommissioning steps for ThreatStream.

How we support

Keep a post-cutover review window in the written scope so issues found in live detections are fixed under agreed terms.
Offer ongoing support, MISP upgrades and continuous security testing as a retainer after handover.
Confirm with your team which upgrade path and support channel you will rely on, including the project's own support resources.