MISP and OpenCTI integration

Two separate components move data between MISP and OpenCTI, and they run in opposite directions. The OpenCTI MISP import connector pulls MISP events into OpenCTI, where analysts can relate them to other intelligence in the knowledge graph. The MISP Intel stream connector works the other way: it consumes intelligence that has been created or curated in OpenCTI and feeds it into MISP for distribution. Decide first which direction your organization needs, because enabling only one connector gives you a one-way flow and a clear place to start. Most teams will run both only after they have agreed which platform is the system of record for each type of indicator.

Both connectors work through the OpenCTI platform rather than writing directly into each other's databases. In OpenCTI, Python workers consume messages from RabbitMQ, and that queue is how writes are applied asynchronously. A burst of imported MISP events therefore lands in a queue and is processed by workers at the pace the platform can absorb, instead of blocking the connector. When you size the deployment, count the workers and RabbitMQ capacity alongside the platform itself, and watch queue depth during the first large import. A growing backlog usually means the workers are undersized, not that the connector has failed.

Treat each connector as its own component. Each has its own configuration file or environment variables, its own API token for the MISP or OpenCTI side, and its own logs. Give each connector a dedicated, least-privilege account in the relevant platform, so that rotating one token or changing one filter does not affect the other connector. Keep the token values in your secrets store, and record which MISP user and which OpenCTI identity each connector acts as. When a sync stops or duplicates appear, the connector logs are where you start, so confirm they are collected centrally before go-live.

Before you install either connector, confirm two things with the connector documentation and your own environment. First, check which connector versions match your OpenCTI release, since the connectors are versioned separately from the platform and a mismatch can cause failed imports or unexpected object types. Second, confirm which MISP API features each connector calls, such as event search, attribute retrieval or the endpoints used to publish events, and check that your MISP version and the API user's permissions allow those calls. Note that MISP 2.5 is the recommended version for new deployments, so confirm the connector supports the MISP version you actually run.

Plan the test sequence around these two directions. Run the import connector against a small, known set of MISP events and verify the resulting objects in OpenCTI before enabling the stream connector. Then enable the stream connector against a test MISP instance or a restricted tag, and confirm that the data it pushes carries the distribution and sharing settings you expect. Keeping the two directions separate during testing makes it much easier to tell whether a problem comes from the connector, the queue or the filter.

Before the first import, decide what the connector is allowed to read and what it should bring into OpenCTI. Two controls in MISP set this boundary. Distribution levels on each event and attribute, together with custom sharing groups, determine which instances and users may see that data. The connector authenticates to MISP with an API key tied to a user account and role, so it cannot import anything that account cannot read. An key belonging to a broad administrative account may see far more than the analysis team expects. Check the role, organization and sharing group memberships of the key you plan to use, and record them with the filter decision.

Tag-based filters decide which MISP events enter OpenCTI. In practice, the team applies a tag to events that meet an agreed criteria, such as a particular threat actor, sector or confidence level, and the connector imports only the events carrying that tag. Set the filter before the full import and test it first. Run the connector against a narrow scope, such as one known tag with a small number of events, then check in OpenCTI that the expected indicators, observables and relationships appeared and that nothing unexpected did. Removing imported data later is slower than preventing it, because downstream connectors and analysts may already have used it.

MISP taxonomies and galaxies add tags that the filter can use. Galaxies such as MITRE ATT&CK attach cluster tags to events, and taxonomies provide structured tag namespaces. These data sets carry their own licenses, CC0 1.0 Universal or the 2-clause BSD license, which are separate from the AGPL license of the MISP software. Confirm with the connector documentation and release notes which tag formats, including taxonomy and galaxy cluster tags, and which distribution values each connector version supports. Then test the filter with a sample event that carries each tag type you intend to use, because a tag that matches in MISP may not be read the same way by the connector.

Write the filter down as a controlled decision. Record the tags, distribution levels, sharing groups, API key role and the person who approves changes. Agree how the team will handle an event whose tags change after import, such as a tag removed because an investigation closed. Confirm in the connector documentation whether removals and distribution changes are propagated, ignored or require a manual step. Repeat the test when you upgrade either MISP or the connector, since supported options can change between versions. Treat the filter as part of the sharing policy, not only as a technical setting.

The main risk in a two-way MISP and OpenCTI setup is that each platform re-imports what the other one sent. An indicator created in MISP can arrive in OpenCTI through the import connector, then leave OpenCTI through the MISP Intel stream connector, and come back to MISP as if it were new. Each pass can create a duplicate object, reset timestamps, or trigger another round of synchronization. Plan for this before you enable both directions, because the symptoms often look like normal activity until the object counts drift.

The first control is a distinct source marker. Choose one MISP tag, and one matching label or marking in OpenCTI, that means "this record came from the other platform." Confirm that the import connector applies the marker to every object it creates or updates, and that the marker survives later edits. Document the exact tag name, restrict who can add or remove it, and treat it as a configuration value that changes only through change control. A marker that analysts can drop by hand will eventually be missing from the records that need it.

The second control is a filter on the reverse stream. The stream connector should exclude any object carrying the origin marker, so data does not go back to the platform it came from. Confirm that the exclusion is applied to the stream query itself, not only hidden in the interface, and that it also covers updates and relationships, not just the first creation. Review distribution levels and sharing groups at the same time. A reverse export that widens sharing beyond the original scope is a data handling problem, even when no loop occurs.

The third control is a single system of record for each class of indicator. Decide which platform owns each category, for example indicators received from a sharing community versus analyst-created intelligence entities, and write that decision into a short ownership table. The owner creates and edits the object. The other platform reads it and does not write back changes to the same record. Ask your integration team to confirm which fields each connector overwrites on update, because an overwrite from the non-owner is one of the most common ways duplicates and conflicting values appear.

Test the setup with one known object in both directions before you rely on it. Create a test indicator in MISP with a known value and the origin marker expected on the reverse path, then follow it through OpenCTI and back. Check that the identifier, the marker, the timestamps and the object count all behave as designed after each hop. Repeat the test starting in OpenCTI. Run the same tests again after upgrading either platform, since connector behavior and schema handling can change between releases. Record the results so the next person can see what was verified and when.