<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: analyzing-siem-correlation-rules
description: >-
  Analyze, optimize, and tune SIEM correlation rules for detection fidelity.
  Covers rule logic validation, false positive analysis, performance profiling,
  threshold tuning, and ATT&CK coverage mapping across Splunk ES, Elastic
  Security, and Microsoft Sentinel analytics rules.
domain: cybersecurity
subdomain: soc-operations
tags:
  - siem
  - correlation
  - splunk
  - elastic
  - sentinel
  - detection-tuning
  - false-positive
  - performance
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1070"]
---

# Analyzing SIEM Correlation Rules

## Overview

Correlation rule analysis ensures detection rules fire accurately, perform
efficiently, and minimize analyst fatigue from false positives. This skill
covers systematic rule review, FP pattern identification, threshold tuning,
performance optimization, and ATT&CK coverage gap analysis.

## Prerequisites

| Requirement | Purpose |
|---|---|
| SIEM admin access | Rule configuration and search logs |
| Alert disposition data | FP rate calculation |
| MITRE ATT&CK Navigator | Coverage mapping |
| Search performance logs | Query optimization |

## Key Concepts

### Rule Health Assessment

```
RULE HEALTH METRICS:
├── Fire Rate: alerts/day — too high = noisy, too low = may be broken
├── FP Rate: false_positives / total_fires — target < 30%
├── MTTD: time between event and alert — measure detection lag
├── Search Duration: execution time — must complete within schedule
├── Coverage: ATT&CK techniques addressed
└── Staleness: days since last review/update
```

### Splunk ES Rule Analysis

```spl
-- Alert volume per correlation rule (last 30 days)
index=notable
| where _time > relative_time(now(), "-30d")
| stats count as total_fires,
    sum(eval(if(status_label="False Positive", 1, 0))) as fp_count,
    sum(eval(if(status_label="True Positive", 1, 0))) as tp_count
    by search_name
| eval fp_rate = round(fp_count/total_fires*100, 1)
| eval daily_avg = round(total_fires/30, 1)
| sort -fp_rate
| table search_name, total_fires, daily_avg, tp_count, fp_count, fp_rate

-- Search performance audit
index=_audit action=search info=completed
| where search_type="scheduled"
| stats avg(total_run_time) as avg_runtime,
    max(total_run_time) as max_runtime,
    count as executions by savedsearch_name
| where avg_runtime > 300
| sort -avg_runtime

-- Rule gap analysis: techniques without detections
| inputlookup mitre_attack_lookup
| join type=left technique_id
    [search index=notable | stats dc(search_name) as rule_count by technique_id]
| where isnull(rule_count) OR rule_count=0
| table technique_id, technique_name, tactic
```

### Elastic Rule Analysis

```
// Alert volume by rule
kibana.alert.rule.name:* AND kibana.alert.status:"active"
| stats count by kibana.alert.rule.name
| sort -count

// Detection rule execution failures
event.provider:"detection_engine" AND event.action:"execution-error"
| stats count by rule.name, error.message
```

### Sentinel KQL Rule Analysis

```kql
// Analytics rule health
SecurityAlert
| where TimeGenerated > ago(30d)
| summarize
    TotalFires = count(),
    FPCount = countif(AlertStatus == "FalsePositive"),
    TPCount = countif(AlertStatus == "TruePositive")
    by AlertName
| extend FPRate = round(todouble(FPCount) / TotalFires * 100, 1)
| sort by FPRate desc

// Rule execution performance
SentinelHealth
| where OperationName == "Scheduled analytics rule run"
| summarize avg(DurationMs) by RuleName
| sort by avg_DurationMs desc
```

### Tuning Strategies

```
FP REDUCTION TECHNIQUES:
├── Allowlist known-good patterns
│   Example: Exclude IT admin IPs from brute force rule
├── Raise thresholds with data justification
│   Example: Increase from 5 to 15 failures based on baseline
├── Add contextual conditions
│   Example: Only alert if user is NOT in admin group
├── Time-window adjustments
│   Example: Ignore backup service accounts during maintenance
├── Entity-based suppression
│   Example: Suppress repeated alerts for same entity within 4h
└── Negative lookups
    Example: Exclude known vulnerability scanners by IP
```

## Workflow

1. **Inventory** — Catalog all active correlation rules with metadata
2. **Measure** — Calculate fire rate, FP rate, and performance per rule
3. **Prioritize** — Focus on highest-volume and highest-FP rules first
4. **Analyze** — Review FP patterns, identify tuning opportunities
5. **Tune** — Apply allowlists, thresholds, and conditions
6. **Validate** — Confirm tuning reduces FP without missing TP
7. **Map** — Update ATT&CK coverage based on active rules
8. **Report** — Produce rule health dashboard for SOC leadership

## Detection

```yaml
title: Siem Correlation Rules Detection
id: 2f36d0c7-3e1f-414d-aa1e-00555586ed87
status: experimental
description: Detects suspicious activity related to analyzing siem correlation rules techniques in soc operations context
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine: "*analyzing*siem*"
  condition: selection
level: medium
tags:
  - attack.t1070
  - attack.defense_evasion
falsepositives:
  - SOAR platform executing automated response playbooks
```

## Verification

| Check | Method |
|---|---|
| FP rate below 30% per rule | Disposition data analysis |
| Search completes within schedule | Performance audit query |
| ATT&CK coverage mapped | Navigator export review |
| Tuning documented | Rule changelog maintained |
| No broken rules | Zero execution errors in audit log |
