OpenCTI and MISP integration

The first decision is which platform is the system of record for each indicator. OpenCTI is where the team correlates, relates and investigates intelligence across its knowledge graph, while MISP is where events are created, distributed and shared with trusted communities. Each indicator should have one clear home before any connector runs. A copy in both platforms without a rule for updates, revocations and expiry will drift apart over time. Decide this per data type rather than once for the whole integration, because some indicators will originate in MISP and others in OpenCTI reports, and the flow should follow where the data started.

Importing all MISP events into OpenCTI is simpler to operate and gives analysts full visibility into what the community sent. The cost is volume and noise. Low-confidence attributes, stale indicators and events from feeds the team does not trust will all enter the graph and need cleaning up. Importing only selected events keeps OpenCTI focused, but it requires a selection rule that someone owns, such as event tags, source organizations or threat categories. It also leaves gaps that analysts must know about. Confirm with the MISP administrator which events are selected, and document the rule so an analyst can tell why a given event is missing from the graph.

MISP distribution levels and sharing groups decide what can leave MISP, and they apply at the attribute level as well as the event level. An item restricted to the originating organization should not be sent onward, and connector configuration should not override that restriction. Sharing groups limit distribution to named organizations, so content from one group may be unsuitable for another. When planning the return path, check the distribution of every source event first. The most restrictive setting in the chain should govern what the receiving instance may do with the data, and anything OpenCTI derives from a restricted source should carry that restriction forward.

The MISP Intel stream connector should send only indicators the team has approved for sharing. Without an approval step, anything OpenCTI holds could be pushed to a community that never agreed to receive it, including enrichment results, analyst hypotheses and data imported from other sources. Record approval in OpenCTI before the stream runs, usually through markings or labels that the connector filters on. Plan who approves indicators, how a withdrawal of approval is handled, and what happens when an approved indicator later becomes restricted by its source. The approval workflow is a control, so it should be tested, not assumed.

Before the first run, align OpenCTI's TLP and marking definitions with MISP's distribution settings. If the markings in OpenCTI map loosely to MISP levels, an indicator meant for limited sharing may be published more widely than intended, or a legitimate share may be blocked without explanation. Agree the mapping in writing, test it with a small set of events in a non-production environment, and confirm which markings the connector reads. Changing the mapping after data has flowed means reviewing everything already shared, so treat the alignment as a go-live gate that the security owner signs off.

Test the OpenCTI and MISP flow against a dedicated set of test data before any connector touches production events. The goal is to prove, in writing, that each direction of the exchange does what your team intends. Create a separate MISP event set, marked clearly as test material, and point the import, feed and stream connectors only at that set. Pair it with an isolated OpenCTI workspace or space so that test indicators, sightings and relationships never mix with the working knowledge graph. Agree the test cases and their expected results with the people who own sharing decisions before the first run, not after.

Start with imports. Load a known set of test events into MISP and run the MISP import connector into the isolated OpenCTI space. Confirm that each MISP attribute and object arrives as the expected OpenCTI observable, indicator or relationship, and that nothing lands as an unexpected entity type. Then reverse the direction: add an indicator or sighting in OpenCTI, let the MISP Intel stream connector push it, and check the resulting MISP event. Verify the distribution level and sharing group on the MISP side match the TLP marking and organization rules you set. A mismatch here is a data leakage risk, so treat it as a release blocker.

Next, test the lifecycle. Edit a test indicator in OpenCTI and confirm whether the change reaches MISP, and edit a MISP attribute and confirm what happens in OpenCTI. Delete one test item from each side and record whether the deletion propagates, is ignored, or leaves an orphan. Repeat the same cases for duplicates: import the same event twice, and send the same indicator from both platforms, then check that the result is a single object or a documented merge. Connector behavior on edits and deletes varies by version and configuration, so confirm it in the connector documentation and source repository for your exact release before you write the expected results.

Validate the analytical value, not just the transfer. Seed the test set with items you already know are related, such as two events sharing a file hash or an IP range that overlaps a CIDR block. Check that MISP's correlation engine links them as configured, and that OpenCTI's graph shows the expected relationships and no false ones. Review the logs of each connector at every step, looking for skipped records, mapping warnings, authentication errors and retries. Keep a simple record of the test ID, input, expected output, observed output and log reference, so auditors and the platform owners can trace each decision later.

Script the repeatable checks. The MISP API documentation describes the search and event endpoints, and PyMISP, the bundled Python library, can create test events, run searches and compare attributes programmatically. Use the same approach on the OpenCTI side through its GraphQL API. Scripted checks make it practical to rerun the full plan after every connector update, configuration change or MISP upgrade. Confirm the exact API behavior, supported filters and any version differences against the MISP documentation and the OpenCTI connector repository for the versions you intend to run, and only move the flow toward production once every case passes or has a documented, accepted exception.