The search bar is easy. The problem is knowing what to type into it without creating a performance disaster or a detection that misses the actual threat.
That tension gets worse when you're building security use cases. A sloppy SPL query for a dashboard is annoying. A sloppy SPL query in a detection rule means you're either hammering your indexers on every search interval or generating alerts that don't fire when they should. Both outcomes are bad. The first costs you compute; the second costs you your credibility with the SOC.
This session at .conf18 covered the SPL patterns that actually hold up in production security environments. The focus was on common mistakes and the query structures that avoid them — not abstract best practices, but the specific decisions that separate searches that scale from searches that don't.
The biggest lever is tstats. Most practitioners know it exists; fewer use it consistently. The reason tstats matters is that it operates against data model acceleration summaries rather than raw index data. If your security data is accelerated — and in most Splunk security deployments, it should be — tstats can run orders of magnitude faster than an equivalent search against the raw events. The tradeoff is that you're constrained to fields that exist in the data model, but for standard security use cases built on the Common Information Model, that's rarely a limitation in practice.
The pattern looks like this:
| tstats count from datamodel=Network_Traffic where nodename=All_Traffic
by All_Traffic.src All_Traffic.dest All_Traffic.dest_port _time span=1h
Compare that to the equivalent search against raw events, which has to decompress and parse every event in the time range. On any deployment with significant traffic volume, the performance difference is not subtle.
Data model acceleration also changes how you think about detection logic. When acceleration summaries are kept current, searches that used to require long lookback windows to establish baselines become practical to run at alert frequency. That matters for use cases like connection frequency analysis or rare process execution, where you need enough historical context to define "normal" before you can define "anomaly."
The other pattern worth building from is proper field qualification in tstats. Unqualified field references can produce unexpected results depending on how your data model is configured. Prefixing fields with the node name — All_Traffic.src rather than just src — is not just convention; it prevents the search from returning results that look correct but aren't.
For threat hunting workflows, the combination of tstats for volume and eventstats or streamstats for per-entity baselines covers most of what you need. The general structure: aggregate with tstats, compute baselines with eventstats, flag deviations with eval or where. That pattern works for beaconing detection, port scanning, lateral movement — anywhere you're looking for behavioral anomalies relative to a baseline.
The compliance and incident response use cases are simpler, but they have their own failure mode: overly broad time ranges that make searches unusable in scheduled alert contexts. A search that's fine when run manually against a 24-hour window will time out at five minutes when run as an alert every 15 minutes. Building detection logic against accelerated data models and keeping the time windows tight by design — not as an afterthought — is what keeps those use cases operationally viable.
Watch Video
Download Slides
Presented at Splunk .conf18 by Anthony G. Tellez and Splunk Professional Services