<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: tuning-edr-detection-rules
description: >-
  Tune endpoint detection and response (EDR) rules to reduce false positives,
  improve detection fidelity, and optimize alert pipelines. Covers exclusion
  management, severity calibration, telemetry validation, and detection
  coverage gap analysis across CrowdStrike, Defender, and SentinelOne.
domain: cybersecurity
subdomain: blue-team
tags:
  - edr
  - detection-tuning
  - false-positive
  - crowdstrike
  - defender-for-endpoint
  - sentinelone
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1003.001", "T1059.001"]
---

# Tuning EDR Detection Rules

## Overview

EDR platforms generate high volumes of alerts. Effective tuning reduces
false positives while maintaining detection coverage for real threats.
This skill covers exclusion management, severity calibration, alert
triage workflows, and systematic coverage gap analysis.

## Prerequisites

| Requirement | Purpose |
|---|---|
| EDR console access | Rule management and exclusion configuration |
| SIEM integration | Alert aggregation and correlation |
| ATT&CK Navigator | Coverage visualization |
| Test environment | Rule validation without production impact |
| Atomic Red Team | Detection validation testing |

## Key Concepts

### Tuning Methodology

```
1. Measure     — Baseline alert volume by rule, severity, host
2. Classify    — True positive, false positive, benign true positive
3. Prioritize  — Focus on highest-volume FP rules first
4. Exclude     — Add targeted exclusions (never blanket disable)
5. Validate    — Run atomic tests to confirm detection still works
6. Monitor     — Track FP rate trends over time
```

### False Positive Classification

| Category | Action | Example |
|---|---|---|
| **True Positive (TP)** | Investigate | Mimikatz detected on workstation |
| **False Positive (FP)** | Add exclusion | AV scanner triggers LSASS access alert |
| **Benign True Positive (BTP)** | Suppress or reduce severity | Admin running PsExec for authorized task |
| **False Negative (FN)** | Create new rule | Attack not detected by any existing rule |

### Exclusion Best Practices

```
DO:
  ✓ Exclude by specific process path + hash combination
  ✓ Exclude by signed certificate (publisher)
  ✓ Scope exclusions to specific hosts/groups
  ✓ Document justification for every exclusion
  ✓ Review exclusions quarterly

DON'T:
  ✗ Exclude entire directories (C:\Windows\)
  ✗ Exclude by process name only (svchost.exe)
  ✗ Apply exclusions globally without scoping
  ✗ Disable entire detection categories
  ✗ Exclude without atomic test validation
```

### CrowdStrike Falcon Tuning

```
# IOA Exclusion (Custom IOA rules)
Platform: Windows
Rule Type: Process Creation
Exclusion: 
  Image Path = "C:\Program Files\Approved\tool.exe"
  Signer = "Approved Vendor Inc"
  Scope = "IT Admin Workstations" host group

# Machine Learning Exclusion
Settings > ML Exclusions > Add
  Pattern: C:\BuildServer\**\*.exe
  Scope: Build Servers host group only
```

### Microsoft Defender for Endpoint Tuning

```powershell
# View alert statistics
Get-MpThreatDetection | Group-Object -Property ThreatName |
    Sort-Object Count -Descending | Select-Object -First 20

# Add process exclusion
Add-MpPreference -ExclusionProcess "C:\Program Files\Approved\tool.exe"

# Add path exclusion (scoped via GPO to specific OU)
Add-MpPreference -ExclusionPath "C:\BuildAgent\work"
```

```kql
// KQL: Alert volume by rule name (last 7 days)
AlertInfo
| where Timestamp > ago(7d)
| summarize AlertCount = count(), 
    DistinctDevices = dcount(DeviceId) by Title, Severity
| sort by AlertCount desc

// KQL: False positive candidates (high volume, low severity)
AlertInfo
| where Timestamp > ago(7d)
| summarize AlertCount = count() by Title, Severity
| where AlertCount > 50 and Severity in ("Low", "Informational")
| sort by AlertCount desc

// KQL: Alert resolution rate
AlertInfo
| where Timestamp > ago(30d)
| join kind=inner AlertEvidence on AlertId
| summarize 
    Total = count(),
    Resolved = countif(InvestigationState == "Resolved"),
    FP = countif(Classification == "FalsePositive")
    by Title
| extend FP_Rate = round(FP * 100.0 / Total, 1)
| sort by FP_Rate desc
```

### SentinelOne Tuning

```
# Exclusion via API
POST /web/api/v2.1/exclusions
{
  "filter": {
    "osTypes": ["windows"],
    "groupIds": ["build-servers-group-id"]
  },
  "data": {
    "type": "path",
    "value": "C:\\BuildAgent\\**",
    "mode": "suppress",
    "description": "Build agent binaries - approved"
  }
}
```

### Detection Coverage Analysis

```
1. Export ATT&CK coverage from EDR → ATT&CK Navigator JSON
2. Overlay Sigma rule coverage (converted to EDR format)
3. Identify gaps: techniques with no detection
4. Prioritize gaps by:
   - Frequency in real-world incidents (threat intel)
   - Feasibility (do we have the telemetry?)
   - Impact (what's the blast radius if missed?)
5. Build detections for top 10 gaps
6. Validate with Atomic Red Team tests
```

### Atomic Red Team Validation

```bash
# Install Invoke-AtomicRedTeam
IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing)

# Test specific technique
Invoke-AtomicTest T1003.001 -TestNumbers 1

# Test and verify detection fired
Invoke-AtomicTest T1059.001 -TestNumbers 1
# Then check EDR console for alert within 5 minutes

# Cleanup after test
Invoke-AtomicTest T1003.001 -TestNumbers 1 -Cleanup
```

## Workflow

1. **Baseline** — Export 30-day alert metrics by rule name and severity
2. **Identify FP** — Sort by volume; classify top 20 highest-volume alerts
3. **Exclude** — Add scoped exclusions for confirmed FPs with documentation
4. **Validate** — Run Atomic Red Team for each modified rule
5. **Coverage** — Map current detections to ATT&CK; identify gaps
6. **Build** — Write new rules for priority gaps
7. **Review** — Monthly exclusion review; quarterly coverage assessment

## Detection

```yaml
title: Tuning Edr Detection Rules Detection
id: ffe8999b-b282-4fe0-9392-9b08653803ae
status: experimental
description: Detects suspicious activity related to tuning edr detection rules techniques in blue team context
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    CommandLine: "*tuning*edr*"
  condition: selection
level: medium
tags:
  - attack.t1003.001
  - attack.t1059.001
  - attack.defense_evasion
falsepositives:
  - Security team running authorized detection validation tools
```

## Verification

| Check | Method |
|---|---|
| FP rate decreasing | Alert volume trend over 30 days |
| No detection regression | Atomic Red Team tests pass after tuning |
| Exclusions documented | Each exclusion has justification and scope |
| Coverage gaps tracked | ATT&CK Navigator shows improvement |
| Alert fatigue reduced | SOC analyst feedback on actionable alert ratio |

## References

- [MITRE ATT&CK Navigator](https://mitre-attack.github.io/attack-navigator/)
- [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team)
- [Palantir Alerting and Detection Strategy](https://github.com/palantir/alerting-detection-strategy-framework)
