Splunk detection engineering and SPL rule development.
Writing SPL that finds attacker behaviour is a different skill from writing SPL that finds data. We build detection content for Splunk Enterprise Security and core Splunk, validated against real telemetry and documented well enough to hand to a tier-one analyst.
What we deliver
- Correlation searches for Enterprise Security, with adaptive response actions and risk scoring where you use Risk-Based Alerting.
- Saved searches and scheduled alerts for core Splunk deployments without ES.
- Data model acceleration and CIM normalisation, because a detection that cannot use
tstatswill not run fast enough to be useful at volume. - Triage runbooks per detection: what fired, what to check, what a true positive looks like, and when to escalate.
The problems we usually find first
Rules that have never fired a true positive
Almost every Splunk deployment we look at has correlation searches enabled that have produced nothing but noise since the day they were switched on. Disabling those is often the single largest improvement available, and it costs nothing.
CIM compliance gaps
Detections written against non-normalised fields break when a log source changes format. Getting your sourcetypes CIM-compliant is unglamorous work that makes every subsequent detection cheaper to write and more durable.
Searches that cannot keep up
A correlation search scheduled every five minutes that takes seven minutes to run will silently fall behind and skip. We check for skipped-search ratios early, because a detection that does not complete is worse than no detection: it looks like coverage.
How we work
Sigma is our source of truth. Rules are written in Sigma, compiled to SPL, and version-controlled, which means the detection logic survives a platform migration and can be reviewed by people who do not read SPL fluently. Every rule is tested with Atomic Red Team or an equivalent before it ships, and tuned against at least thirty days of your historical data before it goes live.
Current experience
We run detection engineering for a Splunk client under NDA. We cannot name them or describe their environment, and we would rather state that than imply a broader portfolio. On a call we can go into as much technical detail as the agreement allows.
Start with a rule audit.
Give us read access to your correlation searches and thirty days of alert history. We come back with which rules are producing value, which are producing noise, and where your ATT&CK coverage actually sits.