Splunk Es

---
name: splunk-es
description: "Splunk Enterprise Security (ES), the premium SIEM app on top of Splunk: correlation searches, notable events, risk-based alerting (RBA), MITRE ATT&CK framework mapping, adaptive response actions, asset/identity correlation, threat intelligence framework, and ES content management. WHEN: \"Splunk ES\", \"Enterprise Security\", \"notable events\", \"risk-based alerting\", \"RBA\", \"correlation search\", \"adaptive response\", \"glass tables\", \"investigation workbench\", \"ES content update\". Do NOT use for core SPL/indexing/forwarder administration — that's the `splunk` skill (this plugin). Do NOT use for general log/metrics observability or ITSI — that's the `splunk` skill in the `monitoring` plugin."
license: MIT
---

# Splunk Enterprise Security (ES)

This skill covers Splunk Enterprise Security (ES), the premium SIEM application that runs on top of Splunk Enterprise or Splunk Cloud. It has deep knowledge of:

- Correlation searches and detection rule development
- Notable events lifecycle (creation, triage, investigation, closure)
- Risk-based alerting (RBA) methodology and implementation
- MITRE ATT&CK framework mapping and coverage measurement
- Adaptive response actions and automated response
- Asset and identity framework (correlation with business context)
- Threat intelligence framework (IOC management, TI feeds)
- ES content updates and Splunkbase security content
- Glass tables (executive visualization)
- Investigation workbench and timeline analysis
- CIM data model dependency and acceleration requirements

## How to Approach Tasks

1. **Classify** the request:
   - **Detection engineering** -- Correlation search development, tuning, RBA implementation
   - **Operations** -- Notable event triage, investigation workflows, SOC procedures
   - **Architecture** -- ES deployment, data model acceleration, performance tuning
   - **Content management** -- ES content updates, MITRE ATT&CK mapping, custom content
   - **Threat intelligence** -- TI framework configuration, feed integration, IOC management
   - **Core Splunk** -- Read the `splunk` skill for SPL, indexing, or infrastructure questions

2. **Determine ES version** -- ES versions are independent of Splunk platform versions. Features vary.

3. **Check CIM compliance** -- Most ES functionality depends on properly CIM-mapped data. If data isn't CIM-compliant, that's the first issue to solve.

4. **Recommend** actionable guidance with SPL examples and ES configuration steps.

## Core Expertise

### Correlation Searches

Correlation searches are the detection engine of ES. They run on a schedule, search for threat patterns, and create notable events.

**Anatomy of a correlation search:**
```spl
# Search logic (SPL)
| tstats summariesonly=true count from datamodel=Authentication
    where Authentication.action=failure
    by Authentication.src, Authentication.user, _time span=5m
| rename Authentication.* as *
| where count > 10
| lookup asset_lookup ip as src OUTPUT priority as asset_priority
| eval urgency=case(asset_priority=="critical","critical", asset_priority=="high","high", true(),"medium")
```

**Configuration components:**
- **Search** -- SPL query that identifies the threat pattern
- **Schedule** -- Cron expression for execution frequency (e.g., every 5 minutes)
- **Alert actions** -- What happens when the search returns results:
  - Create notable event
  - Contribute to risk score (RBA)
  - Send to adaptive response (API call, script, integration)
  - Log event
- **Throttling** -- Suppress duplicate alerts per field(s) and time window
- **Severity** -- Maps to `urgency` field combined with asset/identity priority

### Notable Events

Notable events are the primary alert artifacts in ES:

| Field | Purpose |
|---|---|
| `rule_name` | Name of the correlation search that generated the event |
| `urgency` | Combined severity: rule severity x asset/identity priority |
| `status` | Lifecycle: New -> In Progress -> Pending -> Resolved -> Closed |
| `owner` | Assigned analyst |
| `security_domain` | Access, Endpoint, Network, Threat, Identity, Audit |
| `rule_description` | Human-readable description of what was detected |
| `drilldown_search` | Link to the underlying raw events for investigation |

**Notable event workflow:**
```
Correlation search fires
    |
    v
Notable event created (status: New, urgency: calculated)
    |
    v
Analyst reviews (Incident Review dashboard)
    |
    ├── True positive --> Investigate, contain, remediate, close
    ├── False positive --> Document, add exception, tune correlation search
    └── Needs enrichment --> Run adaptive response actions, gather context
```

### Risk-Based Alerting (RBA)

RBA shifts from individual alerts to entity-based risk accumulation:

**Traditional approach:** Each correlation search generates a notable event. 50 rules x 10 matches = 500 alerts/day for analysts to triage.

**RBA approach:** Each correlation search contributes a risk score to an entity (user or host). A single "risk threshold exceeded" rule generates a notable event only when cumulative risk is significant.

**Implementation:**

1. **Risk factors** -- Each correlation search outputs risk events instead of (or in addition to) notable events:
```spl
# Correlation search outputs a risk event
| eval risk_object=user, risk_object_type="user", risk_score=25
| eval risk_message="Multiple failed logins from ".src
| collect index=risk marker="search_name=\"Brute Force Detection\""
```

2. **Risk aggregation** -- The Risk Analysis data model accumulates scores:
```spl
| tstats summariesonly=true sum(All_Risk.calculated_risk_score) as total_risk,
    dc(All_Risk.source) as source_count,
    values(All_Risk.source) as contributing_rules
    from datamodel=Risk.All_Risk
    where All_Risk.risk_object_type="user"
    by All_Risk.risk_object
| where total_risk > 100 AND source_count >= 3
```

3. **Risk notable** -- When cumulative risk exceeds the threshold, ONE notable event is created with full context of all contributing risk factors.

**RBA benefits:**
- 90%+ reduction in alert volume
- Captures low-and-slow attacks (no single event is alarming, but the accumulation is)
- Analysts see the complete risk story, not isolated events
- Naturally prioritizes high-risk entities

**RBA risk score guidelines:**

| Event Severity | Suggested Risk Score | Example |
|---|---|---|
| Informational | 5-10 | Successful login from new location |
| Low | 10-25 | Failed login attempt |
| Medium | 25-50 | PowerShell encoded command execution |
| High | 50-75 | Credential dumping tool detected |
| Critical | 75-100 | Known malware hash executed on critical asset |

### MITRE ATT&CK Integration

ES maps correlation searches to ATT&CK techniques:

- **ATT&CK Navigator** -- Visualize detection coverage as a heatmap
- **Technique annotations** -- Each correlation search tagged with ATT&CK technique IDs
- **Coverage gaps** -- Identify undetected techniques for detection engineering prioritization

```spl
# Audit ATT&CK coverage
| rest /services/saved/searches
| search disabled=0 action.correlationsearch.enabled=1
| rex field=action.correlationsearch.annotations "mitre_attack\":\"(?<techniques>[^\"]+)"
| mvexpand techniques
| stats count as detection_count, values(title) as detections by techniques
| sort techniques
```

### Asset and Identity Framework

ES correlates alerts with business context:

**Assets:** IP addresses, hostnames, MAC addresses mapped to:
- Business unit, location, owner
- Priority (critical, high, medium, low, informational)
- Category (server, workstation, network device, IoT)

**Identities:** Usernames, email addresses mapped to:
- Full name, manager, department
- Priority (executive, admin, standard)
- Risk score history

**Impact on urgency calculation:**
```
Urgency = f(rule severity, asset/identity priority)

Rule Severity: Critical + Asset Priority: Critical = Urgency: Critical
Rule Severity: High    + Asset Priority: Low      = Urgency: Medium
Rule Severity: Low     + Asset Priority: Critical = Urgency: Medium
```

Populate asset and identity lookups from CMDB, AD, HR systems for maximum value.

### Threat Intelligence Framework

ES ingests and operationalizes threat intelligence:

- **TI feeds** -- STIX/TAXII, CSV, API-based feeds (Recorded Future, AlienVault OTX, MISP)
- **IOC types** -- IP addresses, domains, URLs, file hashes (MD5, SHA256), email addresses
- **Threat matching** -- Automated lookup of IOCs against indexed data
- **Threat activity detected** -- Notable events generated when IOC matches are found
- **Intel management** -- Weight, confidence, expiration for each IOC

```spl
# Check threat intel matches
| tstats summariesonly=true count from datamodel=Threat_Intelligence
    where Threat_Intelligence.threat_match_field="*"
    by Threat_Intelligence.threat_match_value, Threat_Intelligence.threat_collection_key
| sort -count
```

### Adaptive Response Actions

Adaptive response actions execute automated responses when correlation searches fire:

| Action Type | Example | Integration |
|---|---|---|
| **Notable event** | Create a triageable alert | Built-in |
| **Risk modifier** | Add risk score to entity | Built-in |
| **Send to UBA** | Forward to User Behavior Analytics | Splunk UBA |
| **Run script** | Execute a custom Python script | Custom |
| **Send to Phantom/SOAR** | Trigger SOAR playbook | Splunk SOAR |
| **Add to threat intel** | Block IOC across the environment | TI framework |
| **Stream to Kafka** | Forward alert to external system | Kafka add-on |

## ES Deployment Best Practices

1. **CIM first** -- ES is useless without CIM-compliant data. Map data models before enabling correlation searches.
2. **Accelerate data models** -- `tstats` performance depends on acceleration. Accelerate Authentication, Network_Traffic, Endpoint at minimum.
3. **Start with RBA** -- Don't enable all 100+ correlation searches at once. Start with RBA risk contributors and tune.
4. **Asset/identity enrichment** -- Populate asset and identity lookups before go-live. Without business context, urgency calculation is meaningless.
5. **Tune before operationalizing** -- Run correlation searches for 1-2 weeks in "log only" mode before creating notable events.
6. **ES content updates** -- Apply ES content updates regularly. They include new detections, bug fixes, and ATT&CK mapping updates.

## Common Pitfalls

1. **Alert fatigue** -- Enabling all default correlation searches creates hundreds of untuned notable events. Curate ruthlessly.
2. **Data model acceleration lag** -- Acceleration runs on a schedule. New data may not appear in `tstats` results for 5-15 minutes. Not suitable for real-time detection of fast-moving threats.
3. **Urgency without asset data** -- Without asset/identity lookups, all notable events default to the rule's severity. Critical assets generate the same urgency as test systems.
4. **RBA score inflation** -- Without careful score assignment, entities quickly exceed thresholds. Calibrate scores so the threshold represents genuine concern.
5. **CIM mapping gaps** -- A field alias that maps the wrong vendor field to a CIM field produces incorrect detection results. Validate CIM compliance with `| datamodel Authentication search | head 10`.
6. **ES performance** -- ES is resource-intensive. Dedicated search head(s) for ES. Don't share search heads with general user searches.

## Reference Files

For core Splunk knowledge:
- `../splunk/references/architecture.md` -- Splunk platform internals
- `../splunk/references/diagnostics.md` -- Troubleshooting
- `../splunk/references/best-practices.md` -- SPL optimization, CIM compliance, RBA patterns