OpenCTI and Elastic Security integration

Treat the two data directions as separate workstreams with their own owners, credentials and failure handling. The outbound workstream moves observables and indicators from OpenCTI into the Elastic Security threat intelligence index, where indicator match rules can compare them against events. The inbound workstream imports Elastic Security incidents into OpenCTI as incidents or related objects. Both touch the same two platforms, but each has different data, different triggers and different ways of failing, so a design that plans them separately is easier to test and operate.

OpenCTI runs connectors in defined roles, including import, enrichment, file extraction, export and stream consumption. The outbound path usually sits in an export or stream role, and the inbound path usually sits in an import role. The role matters because it determines what starts the work, whether data is sent continuously or in batches, and where progress is recorded. Before you build, confirm in the documentation for your chosen OpenCTI release which connector covers each direction, which Elastic endpoint or index it writes to, and whether it supports the direction you need. Do not assume that a connector built to import can also export.

Outbound decisions include which entity types and indicator fields are sent, which TLP markings and confidence levels are allowed to leave OpenCTI, and how expired or revoked indicators are removed from the index so that stale values do not keep matching. Ask the connector maintainer or the release notes whether revocations propagate. Inbound decisions include how Elastic incidents map to OpenCTI incident objects, which identifier is stored so re-runs do not create duplicates, and which organization owns the imported objects. Record each mapping in writing before the first run, because changing it later can leave duplicate or orphaned objects in the knowledge graph.

Create a separate service account and API token for each direction, with only the permissions that direction needs. Then verify the flow with a small, labeled test set. Confirm that a test indicator appears in the threat intelligence index, that an indicator match rule in a non-production Elastic space fires on it, and that an Elastic test incident appears once in OpenCTI after a second run. Also check that the connector supports the Elastic Stack line you operate. Elastic currently publishes the 9.5 and 9.4 lines and maintains 8.19, so confirm compatibility against the version in your environment, not the latest one.

The first decision is whether the chosen integration method generates detection rules at all. Confirm that before promising anything to the business. Elastic develops its prebuilt detection rules in the elastic/detection-rules repository, where the rules and code are licensed under the Elastic License v2, and the latest prebuilt rules are delivered to the Kibana detection engine automatically. Your own rules, including any rule built from OpenCTI observables, sit alongside that stream of vendor updates. Treat each generated rule as a separate change control item with its own record, owner, approval and rollback path. If the method only pushes indicators into the threat intelligence index, the review gate below applies to the matching and enrichment design instead.

Rule type and observable scope drive most of the false positive risk. Elastic's subscriptions page lists correlation, indicator match and threshold rules within the detection engine. An indicator match rule fires when an event field equals a value from a threat intelligence source, so a broad observable, such as an IP address shared by many tenants on hosting or CDN infrastructure, can match large volumes of benign traffic. A threshold rule counts events over a window and can turn a noisy observable into an apparent campaign. A correlation rule combines several conditions. For each generated rule, review the observable's scope, its TLP marking, its score, its age and whether it is a shared infrastructure address before the rule is enabled.

Put a named reviewer in front of every generated rule. A detection engineer should check the query logic, the fields and index patterns used, the indicator filters and expiry, and the severity assigned, then record approval in your ticketing system. Test in a non-production Kibana space with rules disabled, and observe match counts over a representative period before enabling them. Document any alert suppression settings. Before you finalize the design, confirm feature availability by tier on Elastic's subscriptions page and self-managed subscriptions page. The detection engine appears under Platinum, which Elastic no longer sells to new customers, so new self-managed buyers should confirm whether they need Enterprise or Elastic Cloud.

Each generated rule, or rule family, needs one owner who accepts the expected alert volume, defines the on-call route and sets the criteria for retuning or disabling the rule. Without that owner, alerts from OpenCTI-derived detections reach the SOC with no one accountable for their precision. Ask the integrator to deliver a written rule register that lists the source observable set, rule type, approver, owner, review date and the false positive notes from testing. Review the register whenever OpenCTI indicator scoring changes or your Elastic Stack version is upgraded, because either change can alter what a rule matches.

The test plan should prove the integration works end to end in a non-production OpenCTI and Elastic environment before any indicator reaches a production detection engine. Start by seeding a small set of known test indicators, each with a deliberate TLP marking and an explicit expiry date, so every later check has a known expected result. Record each indicator's type, value, marking and expiry in a test register before the connector runs, so the team can compare what arrives against what was sent. Use fictitious values or documentation address ranges so that no test indicator can match real traffic. Then confirm that the threat intelligence index receives each indicator with the expected fields, including the TLP marking, the expiry and the mapped indicator type and value. Check field names against your own Elastic version, because mappings can differ between releases.

Next, test detection behavior in a dedicated test space. Send a synthetic event that contains a test value and confirm that the indicator match rule fires and creates an alert with the expected rule name, severity and threat fields populated from the indicator. Then run the negative cases. An expired indicator and a revoked indicator should stop matching after the expiry time or after the revocation reaches Elastic, so send events carrying their values and confirm that no new alert is created. Allow for sync latency, and measure timing against the schedule you configured rather than assuming it. Repeat the matching checks with your TLP filter in place to confirm that indicators marked above your sharing level never reach the Elastic side.

Confirm the reverse path with a synthetic Elastic incident or alert created in the test space. It should import into OpenCTI as the intended object type, with the source fields, observables and labels that your mapping specifies. Then run a load check against the sizing guidance in the OpenCTI deployment overview. That guidance lists 2 cores and at least 8 GB RAM for the platform, 2 cores, 8 GB RAM and 16 GB SSD for Elasticsearch or OpenSearch, and at least one platform node for every 3 workers. Load your expected production indicator volume into the test environment and measure worker queue depth, connector run time and index growth. If the measurements exceed the sizing assumptions, change the design before production rather than after go-live.

Finish with a rollback test. Remove the connector from the test environment, then check that nothing it created remains. Detection rules tied to the integration should be deleted or disabled, the threat intelligence index and any data streams or index templates it created should be removed or deliberately retained, and service accounts or API keys should be revoked. Alerts must not point to deleted rules. Record each object type and the console or API step used to confirm its removal, then ask your implementation partner to state in writing what their runbook removes and what it leaves in place. Sign off production only after the rollback result is documented.