Integration / Splunk

Connect Splunk to CYBRET.

Two-way. CYBRET enriches Splunk with verdicts on the events Splunk is already watching, and CYBRET reads the detection content you've already invested in so we don't duplicate it. The integration is built primarily for Runtime Detection.

What CYBRET sees on Splunk

Detection content, not raw event firehose.

We don't want to re-ingest your data. The Splunk integration reads the configuration of detection logic, plus a narrow event stream we use for Runtime Detection correlation. We do not move the contents of your indexes into CYBRET.

  • Saved searches and detections: the search SPL, scheduling, and alert action configuration.
  • Correlation rules: Enterprise Security and ITSI correlation rules where ES / ITSI is in use; the rule, its data model, and the suppression logic.
  • Alert action history: a sample of recent fires per detection, used to grade detection coverage.
  • Indexes and sourcetypes: the inventory only, not the event contents. We use this to know which data CYBRET should not duplicate.
  • Audit log: the _audit index, scoped to admin and search-modifying actions; used to attribute changes.
  • Targeted runtime events: a narrow stream from one or more indexes the customer points us at, scoped to events that match CYBRET-defined queries (e.g. specific cloud audit subsets).
Three real attack-path examples

Where Splunk and CYBRET meet.

The Splunk integration mostly serves Runtime Detection. The attack-path examples here are about how Splunk itself can become part of an attack path, plus where its detection content closes (or fails to close) gaps the rest of the stack creates.

1. Splunk admin token used in CI

Splunk admin token in a GitHub Actions secret → pipeline runs on PRs from forks → admin can edit detections, suppress alerts, or forge events.

The token has admin role and no IP restriction. CYBRET joins the Splunk admin inventory (with role) to the GitHub workflow file where it's referenced. The fix is rotation, scope reduction (a custom role with only the rights the pipeline needs), and an IP allowlist.

2. Saved search runs as nobody but writes to a writable index

Detection runs as nobody → uses | outputlookup or | dump against an index a non-privileged user can write to → a low-privilege user can tamper with detection state.

The detection is supposed to be tamper-resistant; the implementation reaches into a writable target. CYBRET reads the SPL of every scheduled search and flags writes to indexes that are not ACL-locked. Closing the path is either rewriting the search to read-only or moving the side-effect target to an admin-only index.

3. HEC token over-shared, log injection breaks detection

HEC token shared across services → one of them is internet-facing with no input validation → attacker injects events with crafted fields → downstream detection on those fields produces false negatives.

The HEC token allows index assignment, so an attacker can write to the index a high-fidelity detection reads from. CYBRET enumerates HEC tokens and the services that hold them, joins to internet exposure of the holders, and surfaces the path. The fix is per- service HEC tokens with restricted index lists.

How the integration works

HEC token plus a read-only REST credential.

We use the standard Splunk integration surface. A read-only HEC token to push verdicts back into Splunk; a read-only REST API credential (usually a custom role) to read configuration; an optional alert action plugin to surface CYBRET findings on Splunk dashboards.

  1. Open the CYBRET console and go to Integrations → Splunk.
  2. Click Connect Splunk. Enter your Splunk Cloud URL or the on-prem search-head address.
  3. Create a custom role cybret_readonly with read on _audit, _internal (for saved-search metadata), plus the indexes you want to share for runtime correlation.
  4. Generate an authentication token bound to a service user with that role; paste it into the CYBRET vault.
  5. Create a HEC token scoped to a CYBRET-only index for verdicts; paste it into the CYBRET console.
  6. Optional: install the CYBRET alert-action plugin from the supplied .spl file. This adds a "Send to CYBRET for verdict" action to your detections.

Disconnect by deleting the role and revoking the tokens. CYBRET stops ingesting at the next poll.

Permissions and data scope

Read-only on configuration. Narrow event stream only.

The integration uses a read-only REST credential and a HEC token scoped to a CYBRET-only index. We do not read the contents of your indexes by default. For runtime correlation, the customer points us at one or more indexes (typically cloud audit, identity, and application logs); the read is scoped to events matching CYBRET's published queries. Nothing in the default configuration grants write to detections, suppressions, or admin objects.

The optional alert-action plugin is a read-only Splunk app that forwards triggered events to the CYBRET runtime endpoint over TLS. Customers running Splunk on-prem in an air-gapped configuration install the plugin and connect to a self-managed CYBRET in the same network; no inbound connection from CYBRET is required.

How Splunk maps to the three CYBRET products

Where Splunk data shows up in the platform.

Runtime Detection is the product that benefits most. Splunk is where most of our customers already aggregate identity, cloud audit, and application logs. CYBRET treats Splunk as one source among several; verdicts go back via HEC so SOC analysts see them in their existing dashboard.

Exposure Intelligence uses Splunk indirectly. We don't want to re-ingest your event data, but knowing which detections you already have lets CYBRET avoid raising Exposure findings the SOC has already correlated and resolved elsewhere.

Validation uses Splunk as a delivery target. When a CYBRET-validated finding closes, the verdict is sent back through HEC so the originating Splunk detection is tagged with proof. Detection engineers get a feedback loop on which of their content corresponds to real exploitable paths.

FAQ

Questions security engineers actually ask.

How does authentication work?

A read-only Splunk REST authentication token bound to a custom role, plus a HEC token scoped to a CYBRET-only index. Both live in your per-tenant CYBRET vault. We support certificate-pinned outbound from Splunk via the alert-action plugin.

Where does the data live?

Inside the CYBRET deployment in your VPC. We do not bulk-ingest Splunk indexes. Runtime correlation pulls a narrow event stream that you define; nothing leaves Splunk except those scoped events.

Splunk Cloud or on-prem?

Both supported. Splunk Cloud uses the standard REST and HEC endpoints; on-prem deployments use the same with whatever ingress configuration you have. Air-gapped on-prem uses a self-managed CYBRET in the same network.

Do you replace our SIEM?

No. Splunk is your aggregation and correlation tier; CYBRET is your reasoning and verdict tier on top. The integration is designed so SOC analysts continue working in Splunk while CYBRET adds enrichment and proof.

Federated search and Splunk Edge Processor?

Federated Search is supported; CYBRET reads from the indexer that owns the data. Edge Processor pipelines that pre-shape events are read into the CYBRET runtime model for correlation accuracy.

Will it impact our search head load?

CYBRET configuration reads run at low frequency (default hourly) on a dedicated search head where one is available. Runtime correlation reads are scoped queries against streaming endpoints, not bulk index scans.

Next step

Connect Splunk →

Keep your SIEM, add the verdict layer. Verdicts land back in Splunk via HEC; detection engineers get a feedback loop on real exploitable paths.

Connect SplunkSee Runtime Detection