EDR im Unternehmen: Deployment, Tuning und Incident Response

EDR hat traditionelle Antivirussoftware abgelöst - und ist heute die wichtigste technische Sicherheitsmaßnahme auf Endpoint-Ebene. Aber ein falsch konfiguriertes EDR ist fast so schlimm wie keines: zu viele Alerts führen zu Alert Fatigue, und Security-Teams ignorieren dann auch echte Bedrohungen. Dieser Guide erklärt nicht nur was EDR ist, sondern wie man es richtig deployt, tuned und in Security Operations integriert.

EDR-Architektur

Der EDR-Agent läuft auf jedem Endpunkt (Windows, macOS, Linux) mit Kernel-Level-Integration: er überwacht Syscalls, API-Hooks und Prozessaktivitäten in Echtzeit. Die gesammelte Telemetrie umfasst Prozessbäume (wer hat welchen Prozess gestartet?), Netzwerkverbindungen, Dateioperationen (Erstellen, Lesen, Löschen, Verändern), Registry-Änderungen auf Windows-Systemen (typische Persistenzmechanismen), Memory-Anomalien wie Process Injection und Reflective Loading sowie User-Anmeldeereignisse.

Das EDR-Backend ist bei modernen Lösungen als Cloud-SaaS ausgeführt (CrowdStrike, SentinelOne) oder kann On-Premise betrieben werden (Carbon Black). Es nimmt Terabytes an Telemetrie pro Tag auf, führt Behavioral Analytics und Machine Learning gegen diese Daten aus und integriert Threat Intelligence für bekannte Indicators of Compromise (IOCs) und TTPs.

Die Detection-Mechanismen ergänzen sich: Signaturbasierte Erkennung über Datei-Hashes deckt bekannte Malware schnell ab. Verhaltensbasierte Analyse wertet Prozessbäume aus - ein Ablauf wie winword.exe → powershell.exe → cmd.exe → certutil.exe ist für legitime Office-Nutzung ungewöhnlich und typisch für Malware-Ausführung. Machine Learning erkennt Anomalien gegenüber der Baseline eines Systems ohne vorherige Labelierung. Memory-Analyse erkennt Process Injection, Process Hollowing und Shellcode in legitimem Prozess-Speicher - Techniken, die dateilose Malware nutzt, um klassische Signaturerkennung zu umgehen.

Marktführer im Vergleich

CrowdStrike Falcon ist der Marktführer im Enterprise-Segment. Der Agent ist leichtgewichtig (ca. 10 MB RAM-Footprint) und läuft als SaaS ohne lokale Infrastruktur. Das zentrale Konzept ist der Threat Graph, der alle Aktivitäten aller Endpunkte in einem universellen Graph korreliert. Das Modul-Portfolio reicht von Falcon Prevent (AV-Replacement) über Falcon Insight (EDR) bis zu Falcon Identity (Active Directory Integration) und Falcon Intelligence (Premium Threat Intelligence). Die eigene Abfragesprache FQL (Falcon Query Language) ermöglicht komplexe Telemetrie-Abfragen direkt in der Konsole.

Microsoft Defender for Endpoint (MDE) ist für Windows-Kunden oft ohne Zusatzkosten im M365-Bundle enthalten. Die tiefste Windows-Integration ermöglicht Attack Surface Reduction (ASR) Rules, die spezifische Angriffstechniken auf OS-Ebene blockieren - etwa das Erstellen von Child-Prozessen aus Office-Anwendungen oder den Zugriff auf den LSASS-Prozess für Credential-Dumping. Die KQL-basierte Abfragesprache in Microsoft Sentinel ermöglicht Threat Hunting über alle MDE-Tabellen.

SentinelOne zeichnet sich durch autonomes Response ohne SOC-Eingriff aus. Die Storyline-Technologie korreliert einzelne Events zu einer zusammenhängenden Angriffsgeschichte statt isolierter Alerts. Das autonome Response kann verdächtige Prozesse beenden, Dateien in Quarantäne verschieben, durch Ransomware verschlüsselte Dateien per Windows VSS Shadow Copies zurücksetzen und Endpunkte vom Netzwerk trennen.

Carbon Black (VMware) bietet vollständiges Process Recording mit lückenloser Angriffs-Timeline. Der On-Premise-Betrieb ist für Branchen mit strikten Datenschutzanforderungen (Gesundheitswesen, KRITIS) der entscheidende Vorteil, erfordert aber eigene Infrastruktur und ist weniger cloud-nativ als die Konkurrenz.

Alert-Tuning und Alert Fatigue vermeiden

Alert Fatigue ist das größte operationelle EDR-Problem: zu viele False Positives führen dazu, dass SOC-Analysten Alerts ignorieren - und echte Angriffe untergehen. Ein Richtwert sind unter 50 actionable Alerts pro Analyst pro Tag.

Der Tuning-Prozess beginnt mit einem Monitoring-Mode (Woche 1-2), in dem das EDR in "Observe"-Modus läuft ohne etwas zu blockieren. Ziel ist es, die Baseline zu verstehen und keine produktiven Prozesse zu unterbrechen, bevor das System stabil konfiguriert ist. Danach folgt die Alert-Klassifizierung: jeder Alert wird als True Positive, False Positive oder Benign eingestuft. Die häufigsten False-Positive-Quellen sind IT-Management-Tools (PSExec, Ansible, SCCM), Entwickler-Tools (Compiler, Debugger, Git-Hooks), Monitoring-Agents (Splunk Forwarder, Puppet) und Backup-Software (Veeam, Commvault).

Für MDE-Exclusions per PowerShell:

# MDE: Prozess-Exclusion für Backup-Software
Add-MpPreference -ExclusionProcess "C:\Program Files\Veeam\*"
Add-MpPreference -ExclusionPath "C:\ProgramData\Backup\temp"

# ASR-Rules aktivieren (Beispiel: Block Office child processes)
Set-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a `
  -AttackSurfaceReductionRules_Actions Enabled
# Weitere wichtige ASR-GUIDs:
# 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84  Block process creations from PSExec
# 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3  Block credential stealing from LSASS
# be9ba2d9-53ea-4cdc-84e5-9b1eeee46550  Block executable content from email

Exclusions sollten so spezifisch wie möglich sein (Prozess + Pfad, nicht nur Pfad), nie ganze Laufwerke oder Systemverzeichnisse umfassen, dokumentiert sein (warum, wer hat genehmigt) und quartalsweise auf Aktualität geprüft werden.

Die Alert-Priorisierung nach Schweregrad bestimmt die Reaktionszeit: sofort zu behandeln sind LSASS Memory Access/Credential Dumping, Lateral Movement per PsExec/WMI von unbekannter Quelle, Ransomware-typisches Massenencryption-Verhalten, C2-Callbacks zu bekannten IOC-IPs und Privilege Escalation via Token Impersonation. Innerhalb von 4 Stunden sollten PowerShell Encoded Commands, verdächtige Scheduled Tasks, unerwartete lokale Admin-Gruppen-Ergänzungen und Office-Makro-Anomalien behandelt werden. Port-Scanning intern, bekannte PUAs und veraltete Signaturen auf Altsystemen können im täglichen Batch bearbeitet werden.

EDR für Threat Hunting

Proaktives Threat Hunting ist hypothesengetrieben: der Analyst formuliert eine Angriffshypothese und sucht gezielt in der Telemetrie nach Hinweisen. Die folgenden KQL-Abfragen für Microsoft Defender for Endpoint / Microsoft Sentinel decken die häufigsten initialen Angriffstechniken ab:

// Hypothese 1: Kerberoasting-Versuch
DeviceProcessEvents
| where ProcessCommandLine contains_any ("kerberoast", "GetUserSPNs", "asreproast")
  or (FileName in ("Rubeus.exe", "PowerView.ps1"))
| project DeviceName, AccountName, ProcessCommandLine, Timestamp

// Hypothese 2: LSASS Credential Dump
DeviceProcessEvents
| where ProcessCommandLine contains "lsass"
   or (FileName == "procdump.exe")
   or (InitiatingProcessFileName == "powershell.exe"
       and ProcessCommandLine contains "sekurlsa")
| project DeviceName, AccountName, FileName, ProcessCommandLine, Timestamp

// Hypothese 3: Persistence via Run-Keys
DeviceRegistryEvents
| where RegistryKey has @"Run\"
  and not RegistryKey startswith @"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce"
| project DeviceName, AccountName, RegistryKey, RegistryValueData, Timestamp

// Hypothese 4: Lateral Movement via SMB
DeviceNetworkEvents
| where RemotePort == 445
  and InitiatingProcessFileName !in ("System", "svchost.exe")
| summarize count() by DeviceName, RemoteIP, InitiatingProcessFileName
| where count_ > 5

// Hypothese 5: Unusual Parent-Child Process (Living-off-the-Land)
DeviceProcessEvents
| where InitiatingProcessFileName in ("winword.exe", "excel.exe", "powerpnt.exe")
  and FileName in ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe")
| project DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine, Timestamp

Das MITRE ATT&CK Framework liefert die Systematik: Hypothese 2 mappt auf T1003 (OS Credential Dumping), Hypothese 3 auf T1547 (Boot/Logon Autostart Execution), Hypothese 4 auf T1021 (Remote Services) und Hypothese 5 auf T1059 (Command and Scripting Interpreter).

EDR-Integration in Security Operations

CrowdStrike-Telemetrie lässt sich per Splunk Add-on in Splunk indexieren und mit SPL abfragen. MDE leitet über den Data Connector "Microsoft 365 Defender" automatisch alle Tabellen nach Microsoft Sentinel weiter: DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents und DeviceAlertEvents. Das Out-of-the-box Workbook "Endpoint Threat Protection" bietet ein fertiges Dashboard für MDE-Daten.

SOAR-Playbooks automatisieren die Incident Response: bei eingehendem EDR-Alert prüft das SOAR die Kritikalität des Endpunkts per CMDB-Lookup, reichert mit IP-Reputation und User-Kontext aus Active Directory an und reagiert automatisch nach Severity. Bei LOW wird ein Ticket erstellt, bei MEDIUM wird der Endpunkt isoliert und ein Ticket erstellt, bei HIGH werden zusätzlich der User-Account in AD deaktiviert und die Eskalation ausgelöst.

// Defender API: Endpunkt isolieren
POST https://api.securitycenter.microsoft.com/api/machines/{machineId}/isolate
{
  "Comment": "Incident #1234 - Credential Dumping detected",
  "IsolationType": "Full"
}

// SentinelOne API: Netzwerkverbindung trennen
POST /web/api/v2.1/agents/actions/disconnect
{
  "filter": {"ids": ["agent_id_here"]},
  "data": {}
}

EDR vs. XDR vs. MDR: EDR erfasst nur Endpoint-Telemetrie und erfordert ein eigenes SOC-Team. XDR erweitert die Sichtbarkeit auf Netzwerk, E-Mail und Cloud-Dienste und korreliert diese Quellen übergreifend - Angebote wie CrowdStrike Falcon XDR, MDE mit Sentinel oder SentinelOne XDR reduzieren Alert-Silos erheblich. MDR (Managed Detection and Response) überträgt Betrieb und Monitoring an einen externen Dienstleister mit 24/7-SOC-Abdeckung. Für Unternehmen ohne eigenes Security-Team ist MDR oft die wirtschaftlichere Alternative zum Aufbau eines internen SOC.

Sizing und Kosten

Die Lizenzkosten sind nur ein Teil der Gesamtkosten. CrowdStrike Falcon liegt je nach Modul bei 5-20 USD pro Endpoint und Monat, Falcon Complete (mit MDR) bei über 25 USD. Microsoft Defender for Endpoint Plan 2 ist für M365-E5-Kunden im Bundle enthalten (ca. 4,20 EUR/User/Monat als Einzelprodukt). SentinelOne rangiert zwischen 5 USD (Singularity Core) und 15 USD (Singularity Complete mit Storyline+).

Bei 500 Endpoints sind Deployment-Aufwand (ca. 40 Stunden initial), laufendes Alert-Tuning (4-8 Stunden/Monat) und vor allem SOC-Personal (ein Analyst kostet 70-80k EUR/Jahr) die dominierenden Kostenfaktoren. MDR ist für Umgebungen unter 2.000 Endpoints häufig günstiger als ein interner SOC - insbesondere weil externe MDR-Anbieter die Tuning-Expertise und Threat-Intelligence-Infrastruktur als Shared Service bereitstellen.