What it does. Build effective detection rules using Splunk Search Processing Language Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).

Upstream	mukul975/Anthropic-Cybersecurity-Skills
Skill file	skills/building-detection-rule-with-splunk-spl/SKILL.md
License	Apache-2.0 (skill folder LICENSE)
Author	mukul975
Fetched	2026-09-10

Install

• npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill building-detection-rule-with-splunk-spl, or copy the skill folder into ~/.claude/skills/building-detection-rule-with-splunk-spl/.
• Raw file: curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/building-detection-rule-with-splunk-spl/SKILL.md

SKILL.md (verbatim)

name: building-detection-rule-with-splunk-spl
description: Build effective detection rules using Splunk Search Processing Language
  (SPL) correlation searches to identify security threats in SOC environments.
domain: cybersecurity
subdomain: soc-operations
tags:
- splunk
- spl
- detection-engineering
- correlation-search
- siem
- soc
- threat-detection
- enterprise-security
version: '1.0'
author: mahipal
license: Apache-2.0
d3fend_techniques:
- Executable Denylisting
- Execution Isolation
- File Metadata Consistency Validation
- Content Format Conversion
- File Content Analysis
nist_csf:
- DE.CM-01
- DE.AE-02
- RS.MA-01
- DE.AE-06
mitre_attack:
- T1059.001
- T1003.001
- T1021.002
- T1110.003
- T1053.005
- T1048

Building Detection Rules with Splunk SPL

Overview

Splunk Search Processing Language (SPL) is the primary query language used in Splunk Enterprise Security for building correlation searches that detect suspicious events and patterns. A well-crafted detection rule aggregates, correlates, and enriches security events to generate actionable notable events for SOC analysts. Enterprise SIEMs on average cover only 21% of MITRE ATT&CK techniques, making skilled SPL rule writing essential for closing detection gaps.

When to Use

• When deploying or configuring building detection rule with splunk spl capabilities in your environment
• When establishing security controls aligned to compliance requirements
• When building or improving security architecture for this domain
• When conducting security assessments that require this implementation

Prerequisites

• Splunk Enterprise Security (ES) deployed and configured
• Access to Splunk Search & Reporting app with appropriate roles
• Understanding of Common Information Model (CIM) data models
• Familiarity with MITRE ATT&CK framework techniques
• Knowledge of the organization's log sources and data flows

Core SPL Detection Rule Patterns

1. Threshold-Based Detection

Detects events exceeding a defined count within a time window.

index=wineventlog sourcetype=WinEventLog:Security EventCode=4625
| stats count as failed_logins dc(TargetUserName) as unique_users by src_ip
| where failed_logins > 10 AND unique_users > 3
| eval severity="high"
| eval description="Brute force attack detected from ".src_ip." with ".failed_logins." failed logins across ".unique_users." accounts"

2. Sequence-Based Detection (Failed Login Followed by Success)

Correlates a sequence of events indicating a successful brute force attack.

index=wineventlog sourcetype=WinEventLog:Security (EventCode=4625 OR EventCode=4624)
| eval login_status=case(EventCode=4625, "failure", EventCode=4624, "success")
| stats count(eval(login_status="failure")) as failures count(eval(login_status="success")) as successes latest(_time) as last_event by src_ip, TargetUserName
| where failures > 5 AND successes > 0
| eval description="Account ".TargetUserName." compromised via brute force from ".src_ip
| eval urgency="critical"

3. Anomaly Detection with Baseline Comparison

Compares current activity against a baseline period to detect spikes.

index=proxy sourcetype=squid
| bin _time span=1h
| stats count as current_count by src_ip, _time
| join src_ip type=left [
    search index=proxy sourcetype=squid earliest=-7d@d latest=-1d@d
    | stats avg(count) as avg_count stdev(count) as stdev_count by src_ip
]
| eval threshold=avg_count + (3 * stdev_count)
| where current_count > threshold
| eval deviation=round((current_count - avg_count) / stdev_count, 2)
| eval description="Anomalous web traffic from ".src_ip." - ".deviation." standard deviations above baseline"

4. Lateral Movement Detection

Identifies potential lateral movement using Windows logon events.

index=wineventlog sourcetype=WinEventLog:Security EventCode=4624 Logon_Type=3
| where NOT match(TargetUserName, ".*\$$")
| stats dc(dest) as unique_hosts values(dest) as hosts by src_ip, TargetUserName
| where unique_hosts > 5
| eval severity=case(unique_hosts > 20, "critical", unique_hosts > 10, "high", true(), "medium")
| eval description=TargetUserName." accessed ".unique_hosts." unique hosts from ".src_ip." via network logon"

5. Data Exfiltration Detection

Monitors for large outbound data transfers.

index=firewall sourcetype=pan:traffic action=allowed direction=outbound
| stats sum(bytes_out) as total_bytes_out dc(dest_ip) as unique_destinations by src_ip, user
| eval total_mb=round(total_bytes_out/1048576, 2)
| where total_mb > 500 OR unique_destinations > 50
| lookup asset_lookup ip as src_ip OUTPUT asset_category, asset_owner
| eval severity=case(total_mb > 2000, "critical", total_mb > 1000, "high", true(), "medium")
| eval description=user." transferred ".total_mb."MB to ".unique_destinations." unique destinations"

6. PowerShell Suspicious Execution Detection

Detects encoded or obfuscated PowerShell commands.

index=wineventlog sourcetype=WinEventLog:Security EventCode=4104
| where match(ScriptBlockText, "(?i)(encodedcommand|invoke-expression|iex|downloadstring|frombase64string|net\.webclient|invoke-webrequest|bitstransfer|invoke-mimikatz|invoke-shellcode)")
| eval decoded_length=len(ScriptBlockText)
| stats count values(ScriptBlockText) as commands by Computer, UserName
| where count > 0
| eval severity="high"
| eval mitre_technique="T1059.001"
| eval description="Suspicious PowerShell execution on ".Computer." by ".UserName

Building Correlation Searches in Splunk ES

Step-by-Step Process

1. Define the Use Case: Map to MITRE ATT&CK technique and define what behavior to detect
2. Identify Data Sources: Determine which indexes and sourcetypes contain relevant events
3. Write the Base Search: Build SPL that extracts relevant events
4. Add Aggregation: Use stats, eventstats, or streamstats to summarize
5. Apply Thresholds: Set conditions with where clause that distinguish normal from anomalous
6. Enrich Context: Add lookups for asset information, identity data, and threat intelligence
7. Configure Notable Event: Set severity, urgency, and description fields
8. Schedule and Test: Run against historical data and validate detection accuracy

Correlation Search Configuration Template

| tstats summariesonly=true count from datamodel=Authentication
    where Authentication.action=failure
    by Authentication.src, Authentication.user, _time span=5m
| rename "Authentication.*" as *
| stats count as total_failures dc(user) as unique_users values(user) as targeted_users by src
| where total_failures > 20 AND unique_users > 5
| lookup dnslookup clientip as src OUTPUT clienthost as src_dns
| lookup asset_lookup ip as src OUTPUT priority as asset_priority, category as asset_category
| eval urgency=case(asset_priority=="critical", "critical", asset_priority=="high", "high", true(), "medium")
| eval rule_name="Brute Force Against Multiple Accounts"
| eval rule_description="Multiple authentication failures from ".src." targeting ".unique_users." unique accounts"
| eval mitre_attack="T1110.001 - Password Guessing"

Enrichment Best Practices

| lookup identity_lookup identity as user OUTPUT department, manager, risk_score as user_risk
| lookup asset_lookup ip as src_ip OUTPUT asset_name, asset_category, asset_priority, asset_owner
| lookup threatintel_lookup ip as src_ip OUTPUT threat_type, threat_confidence, threat_source
| eval context=case(
    isnotnull(threat_type), "Known threat: ".threat_type,
    user_risk > 80, "High-risk user: risk score ".user_risk,
    asset_priority=="critical", "Critical asset: ".asset_name,
    true(), "Standard context"
)

Performance Optimization

Use Data Models with tstats

| tstats summariesonly=true count from datamodel=Network_Traffic
    where All_Traffic.action=allowed
    by All_Traffic.src_ip, All_Traffic.dest_ip, All_Traffic.dest_port, _time span=1h
| rename "All_Traffic.*" as *

Limit Time Ranges and Use Indexed Fields

index=wineventlog source="WinEventLog:Security" EventCode=4688
    earliest=-15m latest=now()
| where NOT match(New_Process_Name, "(?i)(svchost|csrss|lsass|services)")

Use Summary Indexing for Historical Baselines

| tstats count from datamodel=Authentication where Authentication.action=failure by Authentication.src, _time span=1h
| collect index=summary source="auth_failure_baseline" marker="report_name=auth_failure_hourly"

Testing and Validation

Test Against Known Attack Patterns

| makeresults count=1
| eval src_ip="10.0.0.50", failed_logins=25, unique_users=8, severity="high"
| eval description="Test brute force detection"
| append [
    search index=wineventlog sourcetype=WinEventLog:Security EventCode=4625
    earliest=-24h latest=now()
    | stats count as failed_logins dc(TargetUserName) as unique_users by src_ip
    | where failed_logins > 10 AND unique_users > 3
    | eval severity="high"
]

Calculate Detection Metrics

index=notable
| search rule_name="Brute Force*"
| stats count as total_alerts count(eval(status_label="Closed - True Positive")) as true_positives count(eval(status_label="Closed - False Positive")) as false_positives by rule_name
| eval precision=round(true_positives / (true_positives + false_positives) * 100, 2)
| eval fpr=round(false_positives / total_alerts * 100, 2)

MITRE ATT&CK Mapping

Technique ID	Technique Name	SPL Detection Approach
T1110.001	Password Guessing	Threshold on EventCode 4625 by src_ip
T1059.001	PowerShell	Pattern match on EventCode 4104 ScriptBlockText
T1021.002	SMB/Windows Admin Shares	Logon Type 3 with dc(dest) threshold
T1048	Exfiltration Over C2	bytes_out aggregation over time window
T1053.005	Scheduled Task	EventCode 4698 with suspicious command patterns
T1003.001	LSASS Memory	Process access to lsass.exe via Sysmon EventCode 10

References

• Splunk ES Correlation Searches Best Practices
• Writing Practical Splunk Detection Rules
• Configure Correlation Searches - Splunk Documentation
• SOC Prime - Correlation Events in Splunk

Other files in this skill

• LICENSE
• assets/template.md
• references/api-reference.md
• references/standards.md
• references/workflows.md
• scripts/agent.py
• scripts/process.py

assets/template.md (verbatim)

Splunk SPL Detection Rule Template

Rule Metadata

Field	Value
Rule Name
Rule ID
Description
Author
Date Created
Last Modified
Severity
MITRE ATT&CK
Data Sources
Status	Draft / Testing / Production / Retired

SPL Query

| tstats summariesonly=true count
    from datamodel=<DataModel>
    where <conditions>
    by <fields>, _time span=<interval>
| rename "<DataModel>.*" as *
| stats <aggregation> by <grouping_fields>
| where <threshold_condition>
| lookup asset_lookup ip as src OUTPUT asset_name, asset_priority
| lookup identity_lookup identity as user OUTPUT department, manager
| eval severity=case(<critical_condition>, "critical", <high_condition>, "high", true(), "medium")
| eval description="<dynamic description string>"
| eval mitre_technique="<T-number>"

Detection Logic

What This Rule Detects

<!-- Describe the adversary behavior being detected -->

Data Sources Required

<!-- List all required data sources and their sourcetypes -->

Source	Sourcetype	Index	Required Fields

Threshold Justification

<!-- Explain why the threshold values were chosen -->

Enrichment Details

<!-- List lookups and threat intel sources used -->

Testing Plan

True Positive Test

<!-- Describe how to simulate the attack to validate detection -->

Step 1:
Step 2:
Step 3:
Expected Result:

False Positive Analysis

<!-- Document known benign scenarios that trigger this rule -->

Scenario	Source	Mitigation

Tuning History

Date	Change	Reason	Impact

Correlation Search Configuration

Schedule: */15 * * * *
Time Window: earliest=-20m latest=now
Suppress: 1h by src_ip
Notable Event Security Domain: threat
Adaptive Response: <actions>

Analyst Guidance

Triage Steps

Escalation Criteria

Related Rules

references/api-reference.md (verbatim)

API Reference: Splunk SPL Detection Rules

Splunk REST API - Saved Searches

POST /servicesNS/{owner}/{app}/saved/searches
Authorization: Bearer TOKEN

Field	Description
name	Saved search name
search	SPL query string
is_scheduled	1 for scheduled
cron_schedule	Cron expression (e.g., */5 * * * *)
dispatch.earliest_time	Start of search window
alert.severity	1-5 (info to critical)
alert_type	number of events
alert_threshold	Trigger threshold

Key SPL Commands

Command	Description
stats count by field	Aggregate events
where count > N	Filter results
table field1, field2	Select fields
eval	Compute new fields
lookup	Enrich from lookup table
tstats	Accelerated data model search
join	Join two datasets

Windows Event IDs for Detection

EventCode	Source	Description
4624	Security	Successful logon
4625	Security	Failed logon
4648	Security	Explicit credential logon
4698	Security	Scheduled task created
4104	PowerShell	Script block logging
1	Sysmon	Process creation
3	Sysmon	Network connection
10	Sysmon	Process access

Alert Severity Levels

Level	Value	Description
Info	1	Informational
Low	2	Low risk
Medium	3	Medium risk
High	4	High risk
Critical	5	Critical risk

references/standards.md (verbatim)

Standards and References - Splunk SPL Detection Rules

Industry Standards

MITRE ATT&CK Framework

• Primary mapping standard for detection rule categorization
• Version 18.1 (December 2025) is the latest release
• Use ATT&CK Navigator for visual coverage mapping

Splunk Common Information Model (CIM)

• Standard field naming convention for normalized data
• Data models: Authentication, Network_Traffic, Endpoint, Web, Email
• Enables cross-sourcetype correlation searches

NIST SP 800-92 - Guide to Computer Security Log Management

• Log management planning and policy guidance
• Defines log collection, analysis, and retention best practices

NIST SP 800-61 Rev 2 - Computer Security Incident Handling Guide

• Incident detection and analysis procedures
• Defines severity classification for generated alerts

Splunk Enterprise Security Resources

Correlation Search Framework

• Supports scheduled searches with adaptive response actions
• Risk-based alerting (RBA) aggregates risk events by entity
• Notable events are the primary output for SOC analyst review

Data Model Acceleration

• tstats provides fast summary-based searching
• Accelerated data models required for production correlation searches
• CIM compliance ensures cross-source detection capability

Key Splunk SPL Commands for Detection

Command	Purpose
stats	Aggregate events by fields
tstats	Fast search over accelerated data models
eventstats	Add aggregated stats inline to events
streamstats	Running statistics over ordered events
transaction	Group related events into transactions
lookup	Enrich events with external data
where	Filter results with boolean expressions
eval	Create calculated fields

Detection Engineering Maturity Model

Level 1 - Basic Threshold Rules

• Simple count-based thresholds
• Single data source correlation

Level 2 - Multi-Source Correlation

• Cross-source event correlation
• Asset and identity enrichment

Level 3 - Behavioral Analytics

• Baseline deviation detection
• User and entity behavior profiling

Level 4 - Risk-Based Alerting

• Cumulative risk scoring per entity
• Context-aware severity assignment

Level 5 - Automated Response

• Adaptive response action integration
• SOAR playbook triggering from notable events

references/workflows.md (verbatim)

Workflows - Building Detection Rules with Splunk SPL

Detection Rule Development Workflow

1. Identify Threat Scenario
   |
   v
2. Map to MITRE ATT&CK Technique
   |
   v
3. Identify Required Data Sources
   |
   v
4. Validate Data Availability in Splunk
   |
   v
5. Write Base SPL Query
   |
   v
6. Add Aggregation and Filtering
   |
   v
7. Add Enrichment (Lookups, Threat Intel)
   |
   v
8. Test Against Historical Data
   |
   v
9. Calculate False Positive Rate
   |
   v
10. Deploy as Correlation Search
    |
    v
11. Monitor Detection Metrics
    |
    v
12. Tune and Iterate

Rule Testing Workflow

Phase 1: Development

• Write SPL query in Search & Reporting
• Test with earliest=-7d latest=now()
• Verify expected events are captured

Phase 2: Validation

• Run Atomic Red Team tests to generate known-bad events
• Confirm detection triggers on simulated attacks
• Check no duplicate or redundant notable events generated

Phase 3: Tuning

• Identify false positives from 7-day burn-in period
• Add exclusions for known benign activity
• Adjust thresholds based on environment baseline

Phase 4: Production

• Schedule as correlation search in ES
• Configure adaptive response actions
• Set notable event severity and urgency mapping

Correlation Search Scheduling Guide

Rule Severity	Schedule Interval	Time Window
Critical	Every 5 minutes	10 minutes
High	Every 15 minutes	20 minutes
Medium	Every 30 minutes	35 minutes
Low	Every 60 minutes	65 minutes
Informational	Every 4 hours	4.5 hours

Note: Time window should slightly exceed schedule interval to prevent event gaps.

Alert Output Workflow

Correlation Search Fires
    |
    v
Notable Event Created in ES
    |
    v
SOC Analyst Reviews in Incident Review Dashboard
    |
    v
Analyst Triages: True Positive / False Positive / Needs Investigation
    |
    v
True Positive --> Create Investigation --> Escalate if needed
False Positive --> Document exclusion --> Update correlation search

Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.