OpenCTI and TheHive integration

The import changes OpenCTI from a store of reports and indicators into a graph that also holds the investigations behind them. Once TheHive records reach OpenCTI, cases appear as incident objects, alerts and observables become linked objects attached to those incidents, and the investigation context sits in the same graph as existing reports, indicators and threat actors. An analyst who searches for a domain can see the reports that mention it alongside the case in which it was observed. Before go-live, confirm in the connector documentation which TheHive object types are mapped, which OpenCTI entity each one becomes, and which fields carry across. OpenCTI structures its data on the STIX2 standards, so some TheHive fields may have no direct equivalent and should be checked one by one.

The main data risk is duplication. The same observable can arrive from TheHive, a MISP import, a feed or another connector, and the way objects are identified decides whether those copies merge or split. Two objects for one domain name split its relationships, weaken any scoring built on those relationships and make searches return partial results. Ask the connector owner how existing observables are matched, whether a re-import updates or creates objects, and what happens when a case is edited or closed in TheHive after its first import. Test with a small, known set of cases in a non-production instance, and count objects and relationships before and after each run.

Someone must own data quality for imported incidents, and that decision should be made before the first import. Ownership covers which cases pass the TLP filter and severity mapping in your configuration, who corrects a severity that was mapped wrongly, who removes sensitive content that should not reach a wider audience, and who resolves duplicates. The SOC that runs TheHive usually knows the case facts best, while the threat intelligence team usually owns labels, markings and reference data in the graph. Write this split into a RACI table. Access to imported incidents depends on your marking and access model, and some controls you may need, such as organization-based data segregation, are Enterprise Edition features, so confirm licensing early.

Do not assume the connector enriches or attributes anything. Confirm in its documentation whether it performs any enrichment, and plan as if it does not. In that case, the import carries forward what analysts recorded in TheHive, and any external context or threat actor attribution in the graph has to come from analysts or from a separate enrichment or feed connector. Set a review step that checks imported incidents contain only what the case recorded, and that analyst conclusions are labeled as conclusions. This keeps a later reader from mistaking a working hypothesis for a confirmed finding when they query the graph.

The TLP filter decides which TheHive cases, alerts and observables are allowed to reach OpenCTI, so it is the first control to settle before any connector runs. Treat it as a copy of the sharing rules your organization and its partners have already agreed, not as a setting an integrator chooses on the team's behalf. Each TLP level that the import is permitted to carry should be written down with the sharing scope it implies, and the connector configuration should be checked against that document. If a partner has agreed that TLP:AMBER material stays inside a named group, the import must not push that material into an OpenCTI instance that more people can read. The filter also needs an owner outside the integration team. Ask the threat intelligence or information-sharing lead to sign off the mapping of TLP labels to allowed flows, and ask the platform owner to confirm how OpenCTI marking definitions will represent those labels after import. Confirm the exact TLP version your sharing agreements reference, because marking names and levels must match what partners expect. Record who approves any change to the filter, and keep that record with the configuration. Severity needs the same discipline. TheHive and OpenCTI do not necessarily use the same scale or the same vocabulary, so the mapping between them must be written as a table and approved before data arrives. Name the TheHive severity values in use in your instance, name the OpenCTI values they will become, and state the owner who may approve a change to either side. When someone later adds a severity level in TheHive or changes an OpenCTI value, the change should go through that owner rather than being edited in the connector by whoever notices the mismatch first.

Some cases will arrive without a TLP label or a severity value, and the integration has to decide what happens to them. The safe default for a missing TLP is the most restrictive label your sharing rules allow for that flow, so unlabeled material does not travel further than anyone approved. For severity, choose a neutral default that is visibly marked as defaulted, so analysts can tell a real low rating from a missing one. Write both defaults into the mapping document and state whether such items are imported, held for review or skipped. Holding or skipping is a legitimate choice, but it must be deliberate and measurable. Defaults should be reviewable, not silent. Ask the analyst team to agree how they will find defaulted items in OpenCTI, for example through a label or a saved view, and how they will correct the TLP or severity in TheHive so the next import reflects the true value. Confirm with your platform team whether the connector and OpenCTI version you plan to run can apply and display such labels in the way you need, since this depends on the release in use and should be verified in a test instance rather than assumed. Before production, run a test set that deliberately includes each TLP level, each severity value, and cases with blank fields. Check that restricted material stays out of the wrong OpenCTI scope, that defaults are applied as written, and that corrections in TheHive are reflected after the next run. Keep the test results with the approved mapping so an auditor or partner can see how the rules were checked.

Run the TheHive to OpenCTI import against a non-production TheHive instance or a labeled sample of cases before any production data reaches the platform. The point of this test is to prove that what arrives in OpenCTI matches the mapping table your team agreed on, and that access and deduplication behave correctly under conditions you control. Treat the test as a gate: production connector credentials and the live TheHive organization stay out of scope until every check below has a recorded result.

Start with content. Load a sample that covers each case, alert and observable type your investigators actually use, including cases with and without linked observables and alerts that were promoted to cases. Confirm that each object lands as an incident, observable or related object in the form the mapping table predicts, that severity values translate to the OpenCTI scale you chose, and that the TLP marking on each imported object matches its source. Check a sample by hand in the OpenCTI interface and through the GraphQL API, since a UI view can hide a field that downstream playbooks or queries depend on.

Next, test access. Create or reuse at least one OpenCTI user without access to the restricted TLP data and one user who should see it, then confirm that a TLP:RED or otherwise restricted case does not appear in the first user's search, lists, relationships or graph views. Also check that the connector's own service account has only the rights it needs in both platforms. Confirm with your OpenCTI administrator how marking definitions and organization-based segregation are configured in your edition, because the controls available differ between Community and Enterprise deployments and this check depends on which one you run.

Then test repeatability and failure. Run the connector a second time against the same sample and confirm that no duplicate incidents, observables or relationships appear, and that updated TheHive records update existing objects instead of creating new ones. Next, stop TheHive for a defined window during an import, restart it, and watch the connector logs, the message queue and the imported object counts to see whether it resumes, retries or drops work. Record what happens to items that were in flight, because the answer determines how you will reconcile gaps in production.

Finally, write the expected results down. Keep a versioned test record that lists the sample cases by identifier, the expected OpenCTI object for each, the TLP and access outcome, the duplicate check result and the outage behavior, with the versions of both platforms and the connector at the time of the test. When OpenCTI or TheHive is upgraded, rerun the same cases against the recorded results rather than rebuilding the test from memory. Confirm the release and LTS details for your target versions in the OpenCTI product life cycle documentation and with your TheHive administrator before you schedule that retest.