SPLK-3001 Creating Correlation Searches

Creating Correlation Searches Detailed Explanation

1. What Are Correlation Searches?

Correlation searches are scheduled SPL (Search Processing Language) queries that analyze data across one or more sources to detect suspicious patterns or behaviors. When these patterns are found, the search can generate a Notable Event or take other automated response actions.

Unlike standard searches in Splunk, correlation searches are designed for real-time detection, alerting, and integration with security workflows.

2. Core Components of Correlation Search Creation

a. Search Logic (SPL Development)

Writing effective correlation searches requires a strong command of SPL. Searches should be:

• Efficient: Use tstats or accelerated data models when possible.

• Specific: Avoid overly broad criteria that create noise.

• Modular: Include tokens and macros for reusability.

Common SPL commands used in correlation searches:

• eval: Create new calculated fields (e.g., eval risk_score = severity * 2)

• stats: Aggregate or summarize data (e.g., stats count by user)

• transaction: Group related events into a single logical event

• lookup: Enrich data using external files or identity mappings

• join: Combine data from different sources (used sparingly for performance)

Example Search Logic:

| datamodel Authentication Authentication search
| search action="failure"
| stats count by user, src
| where count > 5

This search detects users with more than five failed logins and flags them as suspicious.

b. Correlation Search Editor

Splunk ES provides a dedicated Correlation Search Editor to help configure and manage all aspects of your search.

Key settings in the editor include:

• Severity: Impacts the risk score and visibility (e.g., Informational, High)

• Urgency: Affects how alerts are prioritized in Incident Review (e.g., Low, Critical)

• Category: Helps group searches by function (e.g., Access, Malware, Policy Violation)

You also define the Notable Event’s:

• Title and Description: You can use tokens like $user$, $src$ to dynamically insert values.

• Adaptive Response Actions:

  • Send an email to the SOC team

  • Create a ticket in a service desk system

  • Adjust a user’s or asset’s risk score

  • Trigger a script or webhook

These settings are vital for integrating detection with response workflows.

c. Integration with Other Data

Strong correlation searches don't operate in isolation — they work with other ES components.

• Lookup Files:

  • Used to compare observed values (like IP addresses) with known bad indicators or watchlists.

• Threat Intelligence:

  • Search logic can reference indicators from Splunk’s Threat Intelligence Framework.

• Identity Context:

  • Include role, department, or criticality of affected users to enhance detection relevance.

• Tags and Event Types:

  • Ensure events align with CIM standards for consistency and dashboard population.

These integrations improve both the accuracy and value of alerts.

3. Best Practices for Correlation Search Creation

a. Always Test in the Search App

Before publishing any correlation search:

• Run the SPL in the Search & Reporting App.

• Validate:

  • Does the search return meaningful results?

  • Is the time range appropriate?

  • Are all required fields extracted correctly?

Testing avoids pushing noisy or broken logic into production.

b. Use the Content Management Dashboard

• Located under Configure > Content Management in Splunk ES.

• Shows a complete list of all correlation searches, risk rules, and key settings.

• Helps track:

  • Search performance

  • Run schedule

  • Last triggered time

  • Associated response actions

This dashboard is essential for governance and audit of your detection logic.

4. Summary of Creating Correlation Searches

Component	Description
SPL Search Logic	Use eval, stats, lookup, transaction, and datamodel queries
Correlation Search Editor	Set severity, urgency, response actions, and dynamic event details
Integration Elements	Link with threat intel, lookups, and identity info for context
Testing Process	Always test searches in the Search app before deployment
Content Management	Use dashboards to review and monitor all correlation search assets

Creating Correlation Searches (Additional Content)

1. Event Type Registration and CIM Alignment

When designing a correlation search, it’s not just about detecting suspicious activity — it’s also about ensuring compatibility with CIM and ES dashboards.

a. Why Event Types and Tags Matter

• Correlation searches often rely on event types (defined in eventtypes.conf) and tags (defined in tags.conf) to categorize events.

• These mappings allow the Splunk Common Information Model (CIM) to understand and classify raw data.

• Without them, events may not populate dashboards like the Security Posture Dashboard or Glass Tables, and correlation rules may miss critical matches.

b. Best Practice

Always define an eventtype for key event classes (e.g., failed_logins)
And apply appropriate tags (e.g., tag=authentication)
Then register the eventtype in the CIM data model, either via the UI or eventtypes.conf

2. Behind the Scenes: adaptive_response_actions.conf

Splunk ES provides the ability to trigger Adaptive Response Actions (ARAs) from within correlation searches, such as sending an email, creating a ticket, or calling an external script.

While these actions are configured in the ES UI, they are powered by backend files.

adaptive_response_actions.conf

This configuration file defines:

• The available action types

• Associated scripts or REST calls

• Required permissions and display names

• Which parameters are needed (e.g., destination IP, user name)

Example Use Case:

If you're developing a custom adaptive action (e.g., isolate a host via firewall API), you must:

• Register the action in adaptive_response_actions.conf

• Deploy supporting logic in the TA directory (usually under bin/)

• Ensure metadata permissions (default.meta) allow global access

This configuration ensures the action appears in:

Configure > Adaptive Response Actions

…and is callable from any correlation search.

3. Clarifying: Schedule vs. Time Range vs. Throttle

These three components control when a correlation search runs, what time span it examines, and how often it’s allowed to alert.

Component	Description
Schedule (cron)	Defines when the search runs (e.g., every 5 minutes)
Earliest/Latest	Defines the time window of data the search looks at (e.g., -5m to now)
Throttle	Prevents repeated alerts for the same entity within a given timeframe

Example Scenario:

• Schedule: Every 5 minutes

• Time Window: earliest=-5m latest=now

• Throttle Field: user

• Throttle Period: 30m

This means the search runs every 5 minutes, checking the last 5 minutes of data, but will suppress duplicate Notable Events for the same user if triggered within a 30-minute window.

This configuration avoids:

• Overlap issues (e.g., searching 60 minutes every 5 minutes → overload)

• Repeated alerts (noisy false positives)

• Under-alerting (if throttle is too aggressive)

Summary of Enhancements

Area	Added Insight
Event Type Registration	Shows how to align correlation logic with CIM to populate ES content
Adaptive Response Actions	Explains backend file-based management (adaptive_response_actions.conf)
Schedule vs. Time Range Logic	Clarifies how correlation search timing and throttling mechanisms interact