OpenCTI and Splunk integration

Entity type scope is the first decision to settle, because it determines what reaches the Splunk KV Store and therefore what your correlation searches can match. Indicators are the natural starting point for lookups, since each one carries a value or pattern that a search can compare against events. Observables, reports, incidents and other entity types serve different questions. Reports and incidents describe analyst work, and observables can be numerous, so exporting them by default can grow the KV Store quickly and add records that no detection ever reads. Treat the export scope as a deliberate allow list that follows detection needs, and document why each entity type is included.

Build the allow list from detection use cases, starting with the questions each Splunk search must answer. Write each use case as a plain question, such as whether a domain seen in proxy logs appears in threat intelligence, or whether a file hash from endpoint telemetry matches a known sample. For each question, record the entity type that carries the value, the field the search will compare, any labels or markings that must be present, and the person who will review and retire the entry. As an illustrative example, a proxy domain lookup might need domain-name indicators filtered by a confidence threshold your team sets. Review the list with the owners of those detections before the first export.

Indicators and observables are related but distinct. In STIX 2, an indicator carries a pattern that describes conditions on cyber observables, such as a domain name or file hash, so the pattern points to the observed values it describes. OpenCTI follows the STIX 2 knowledge schema, so an indicator is linked to the observables it describes, and an observable can exist without any indicator. A lookup needs a plain value to match, so confirm whether the connector exports the pattern string, the observable value, or both, and which fields arrive in Splunk for your connector version. A pattern alone may need parsing before it matches raw events. Decide separately whether observables without an indicator belong in the allow list, because including them widens matches and inflates the KV Store.

Keep one lookup per use case. A single shared table makes it hard to trace which detection produced a match, to set different retention for different use cases, or to remove one use case without touching the others. Name each KV Store collection and its lookup definition after the use case, and map each one to its allow list entry. Before going live, validate the list against your own detections: run existing correlation searches with and without the new lookup in a test environment, and confirm which entity types and fields actually arrive in Splunk. Treat this list as a starting point that still needs validation against your detections and against what the connector exports in your environment.

Start sizing with the documented OpenCTI baseline, then treat it as a floor. OpenCTI's deployment overview gives the platform 2 cores and at least 8 GB RAM. It gives Elasticsearch or OpenSearch 2 cores, 8 GB RAM and 16 GB SSD, and it recommends at least one platform node for every 3 workers. These figures describe a platform that runs without streaming a Splunk feed, so they do not size the stream by themselves. Check them against the deployment overview for the exact release you plan to run, because the release line you choose can change the requirements for workers and search storage.

The consumer's load follows from four drivers. The first is the number of indicators that match your stream filter, since that sets the size of the initial backfill. The second is the rate of change: creates, updates and deletions each produce work for the consumer and for Splunk, and deletions must reach the lookup or stale indicators will remain searchable. The third is Splunk's indexing and KV Store write capacity. The fourth is the connector host's CPU and memory, which the consumer uses to read, transform and forward each indicator. Filters that match broadly, or feeds that update the same indicators often, raise load even when the total count looks modest.

No Splunk-side sizing figures are supplied for this page, so the Splunk side needs its own check. Ask your Splunk administrators to confirm the KV Store write and storage headroom on the search head that hosts the lookup, the indexer capacity for any events they will index, and the search load that correlation searches will place on the lookup. Confirm these limits in Splunk's own documentation and in your environment, not from this page. Record the answers as acceptance thresholds, so the stream design has a clear limit before anyone changes the filter.

Load test with your own indicator volume before you enable the stream in production. Run a full backfill from a copy of the production indicator set, then simulate the daily change rate that your filter produces. Measure the backfill duration, the steady-state lag between an OpenCTI change and its appearance in Splunk, the worker backlog on the message queue, connector CPU and memory, and KV Store write latency. If lag grows or the backlog does not drain, add workers or platform nodes using the one-node-per-3-workers guidance, then retest. Agree on the rollback steps for a consumer that falls behind before the first production run.

Test the whole chain in a non-production OpenCTI instance before any correlation search can page someone. The stream connector writes indicators into a Splunk KV Store collection, and a broken write looks the same as a quiet threat landscape. Start by creating one known test indicator with a recognizable value and a single entity type you have already chosen to export. Use a clearly fictitious value, such as an address from a documentation range (illustrative), so nobody mistakes it for live intelligence. Then confirm, in the KV Store collection, that the record exists with the fields your lookup definition expects, such as the observable value, the type, the score and the labels. Check field names against your own connector configuration rather than against this page.

Next, test the lookup on its own. Run a search that calls the lookup definition with the test value and confirm it returns the expected fields. Run it again with a value that is not in the collection and confirm it returns nothing. Only then build the correlation search, and run it against sample events that contain the test value. Replayed events from a test index work well for this. Record what the search returns: the number of matches, the fields in each result, and whether the alert fires once or repeatedly. Repeated firing usually points to throttling or deduplication settings that need a decision before production, not after the first noisy week.

Expiry and deletion need their own tests because a record that stops being current can keep matching for as long as it remains in the collection. Create a test indicator with a short validity window and confirm which component removes or filters it: the connector, a scheduled Splunk search, or the lookup query itself. Then delete or revoke the test indicator in OpenCTI and confirm the removal reaches the collection. Finally, create indicators and observables of every entity type you excluded in the connector filter, and confirm none of them appear in the KV Store or return from the lookup. A filter that works for one type can silently fail for another, so test each excluded type individually.

Write down the expected result for every test, including the test indicator values, the event samples and the expected alert count, and keep them in version control next to the Splunk configuration. Rerun the full set after each OpenCTI upgrade and after any connector change, because platform releases and connector versions move independently. Non-LTS OpenCTI releases can ship from daily to weekly, and LTS lines are published every six months. Confirm with your team who owns the test set, who reviews failures and whether a failing test blocks a change from reaching production.