Skip to main content

​
What Cymph uses it for

Cymph connects to Splunk Enterprise Security to read your correlation searches and collect the MITRE ATT&CK techniques annotated on each one, so a preset’s scope can be derived from what you actually detect. See Manage presets for the detection-based scope option. All operations are read-only — Cymph never creates, modifies, or disables a search, and never runs one.

​
Requirements

The Splunk management API listens on port 8089 by default and is separate from Splunk Web (port 8000). Pointing the integration at Splunk Web will fail the connection test.

​
Token setup

Cymph authenticates with a bearer token, not a username and password. In Splunk Web, go to Settings → Tokens and create a token for the account Cymph should use. Token authentication must be enabled on the instance first (Settings → Tokens → Enable Token Authentication).
Create a dedicated Splunk account for Cymph rather than reusing an administrator’s. It keeps the access read-only and makes the integration’s activity easy to identify in your Splunk audit logs.

​
Permissions

The token inherits the roles of the Splunk user it was issued for. Splunk authorisation has two independent layers, and read access needs both — granting capabilities alone is the most common reason a token authenticates but returns nothing:
  1. Role capabilities — rest_properties_get, which permits reading configuration objects over the REST API.
  2. Object ACLs — the role must appear in the read ACL of the correlation searches themselves. In Splunk Enterprise Security these are managed on the ES Permissions page; a custom role shows up there within about a minute of being created.
The simplest option that satisfies both is Enterprise Security’s built-in read-only analyst role, ess_user, which already carries ES app access and read ACLs on correlation searches.
Start with a dedicated user holding ess_user. If the connection test passes but no techniques come back, the gap is almost always layer 2 — the role is not in the read ACL for the correlation searches.
Cymph needs no write capability of any kind: not edit_correlationsearches, not schedule_search, and no ability to dispatch searches. It reads saved-search configuration only and never runs a search.
Splunk deployments vary considerably in how ES roles are customised. Treat ess_user as the recommended starting point rather than a guarantee, and validate against your own instance — your ES administrator may have altered the shipped roles’ ACLs.

​
What Cymph reads

Cymph asks Splunk to do the filtering, so only the data it needs crosses the wire:
  • search=action.correlationsearch.enabled=1 — only enabled correlation searches are returned. Disabled ones are ignored and do not contribute to scope.
  • f=action.correlationsearch.annotations — the response is restricted to the annotations field alone. Cymph does not read search queries, results, or any event data.
Results are read in pages of 100 until every matching search has been seen. Only searches carrying mitre_attack annotations contribute techniques; searches without them are read and ignored.

​
Testing the connection

Test Connection calls the server-info endpoint and reports what it found:
Every request Cymph makes to Splunk times out after 5 seconds. If Cymph reaches your instance through a source-IP allowlist, confirm the egress addresses are permitted — see Networking.

​
Limitations

Splunk ES is a detection source only — playbooks cannot be deployed to it, and it does not import assets. If you want to deploy playbooks to Splunk, that is the separate Splunk SOAR integration.