Integration
When Splunk Detects a Pattern Nobody Has Time to Investigate
Written by
Praveen Yadav
Published
August 2026
Reading time
8 min read
Your correlation searches are working. That is the problem. Detection capacity has outrun investigation capacity, and the queue is where the risk now lives.
Somebody wrote a good correlation search. It runs on schedule, it produces notable events, and the risk scoring in Enterprise Security ranks them sensibly. The detection engineering is not the weak part of this story. It is the strongest part, and it is why the problem exists.
Open the notable queue on a Monday. Count what is still in New state from last Tuesday. In most estates that number is not small, and the reason is arithmetic rather than negligence: a correlation search can produce notables continuously, and a human can triage perhaps a few dozen properly in a shift. Add saved searches, summary indexed rollups and a handful of ITSI multi KPI alerts, and detection capacity has comfortably outrun investigation capacity.
Then throttling gets tightened, or the risk threshold gets raised, or a search gets disabled during an incident and never re enabled. None of those decisions is written down as risk acceptance. They are operational adjustments made by tired people, and they are how detection coverage quietly degrades while the dashboard keeps saying it is green.
The queue is not a backlog, it is an exposure
A ticket backlog and an untriaged notable queue look similar in a report and behave completely differently. A ticket sitting for a week is late. A notable sitting for a week is a question about whether something is happening in your estate right now that you have already detected and not yet read.
Detection without triage is not security posture. It is a record, written in advance, of what you will be asked about in the post incident review.
The number worth pulling before anything else is the age distribution of notables by risk score, not the count. A queue of two hundred low risk notables is an annoyance. Eleven high risk notables older than seventy two hours is a different conversation, and it is the one an auditor will find without difficulty.
What triage actually consists of
Watch an analyst work a notable properly and almost none of it is judgement. It is retrieval, and it is the same retrieval every time.
- Establish the entity. Which user, host, account or service is this actually about, and resolve the identifiers across the sources that name it differently.
- Establish the baseline. Is this behaviour unusual for this entity, or unusual only against a global threshold that was set for the estate three years ago.
- Pull the adjacent evidence. Authentication, endpoint, network, change records and, in an operations context, the deployment that landed forty minutes earlier and explains the whole thing.
- Check for precedent. Has this signature been triaged before, and what was the disposition. Most estates have this in closed notables and cannot search it usefully.
- Decide and record. Benign, needs containment, or escalate, with the reasoning attached.
Steps one to four are mechanical and parallelisable. Step five is the one that requires a person, and it is a small fraction of the elapsed time. The queue exists because the mechanical part is done serially by humans who are also the only people qualified to do the judgement part.
What Sentinel does with a notable
When a notable is created, Sentinel picks it up through the Splunk API and runs steps one to four in parallel rather than in sequence. It queries Splunk itself in SPL for the adjacent evidence, and it queries outside Splunk for what your Splunk deployment is unlikely to carry: the live state of the systems the entity touches, the change and deployment record where it is not forwarded, and ITSM history. Where you run ITSI, its service topology is read as an input rather than reconstructed.
Two outputs matter. The first is a disposition with its reasoning attached, written back against the notable so the analyst reads a case rather than a starting point. The second is a correlation across notables, which is the one people underestimate: a large fraction of any queue is several detections of one underlying event, and collapsing forty notables into one investigated incident changes the shape of the queue more than any single triage improvement.
That is the same correlation behaviour described in how to correlate alerts across tools, applied to detections rather than to infrastructure alarms.
Where it is allowed to act
This is the part where a security audience is right to be sceptical, because the failure mode of an automated response is not an outage. It is locking out a legitimate user during a trading window, or isolating a host that turns out to be the thing keeping a service alive.
So the gate is not confidence in the detection. It is the blast radius of the response.
- Enrich and correlateReads only. Adds evidence, resolves entities, links related notables, opens or updates a case. Reversible by definition. Runs unattended.
- Gather live evidenceQueries the endpoint, pulls the session record, captures the current state before it changes. Bounded, non destructive, verifiable. Runs under an Action Ticket.
- Disable, block or isolateCreates a second incident when wrong, and the wrong ones are not always visible immediately. Held for a named approver, with the procedure, the radius and the rollback already written.
The right hand column is not a limitation we are apologising for. It is the reason the left hand columns are allowed to run at all. An estate that will not let a machine enrich a notable is an estate that has been offered the third column with the first column marketing, and has sensibly declined the lot.
What comes back to Splunk
Everything, and in a form Splunk can already search. The disposition and its evidence against the notable, the correlation identifier that links the collapsed set, the actions taken with their pre-check and post-check results, and the approver where one was required. Your existing dashboards keep working. Your existing reporting keeps working. If Sentinel is removed, the record of what happened remains in the system your auditors already query, which is a deliberate design constraint rather than a convenience.
Opstral reads Splunk through its own API and writes back to it, alongside the same treatment for Datadog monitors and Prometheus Alertmanager. See the integration coverage or the security architecture.
Frequently asked questions
Does this replace Splunk?
No, and the economics would not work if it did. Splunk is where the data lives and where the detection logic lives, and both represent years of tuning that has real value. Sentinel queries Splunk through SPL rather than duplicating the index, and writes its findings back against the notable. What it adds is the step between detection and response: the triage that decides whether a response is warranted at all.
How is this different from SOAR?
Splunk SOAR is Splunk own product for exactly the response step, and it is good at it: it executes a playbook you wrote, on a trigger you defined, deterministically. That determinism is the virtue and the limit. A playbook does not decide what to look at next based on what it just found, so the triage that decides whether a playbook should fire at all still lands on an analyst. Sentinel does that triage and then executes under a blast radius gate. In practice the two coexist, and where SOAR is already deployed we trigger it rather than duplicate it.
What about false positives in the correlation searches themselves?
They surface faster and with evidence, which is the useful part. When a correlation search produces notables that investigate to nothing repeatedly, that pattern is reported with the specific reason each one was benign. That is the input to retuning the search, and it is the first time most teams get feedback on detection quality that is ranked by wasted analyst time rather than by raw volume.
Can it act on a security notable without a human?
Only where the action is reversible, bounded and machine verifiable. Enriching a notable, opening a case, gathering evidence and correlating across sources all run unattended. Disabling an account, blocking a source or isolating a host are held for a named approver with the procedure and rollback prepared, because those are irreversible in the way that matters, which is that a wrong one creates a second incident.