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

EDR-Systemarchitektur:

EDR Agent (Endpoint):
  → Läuft auf jedem Endpunkt (Windows/macOS/Linux)
  → Kernel-Level Integration: Syscalls, API-Hooks, Prozessüberwachung
  → Telemetrie-Sammlung:
    - Prozess-Bäume (Process Trees): Wer hat wen gestartet?
    - Netzwerkverbindungen: ausgehende/eingehende Verbindungen
    - Datei-Operationen: Erstellt, Gelesen, Gelöscht, Verändert
    - Registry-Änderungen (Windows): Persistenz-Mechanismen
    - Memory: Injection-Erkennung, hollowing, reflective loading
    - User-Anmeldungen: Welcher User auf welchem System?

EDR Backend:
  → Cloud-SaaS (CrowdStrike, SentinelOne) oder On-Premise (Carbon Black)
  → Telemetrie-Aufnahme: terabytes/tag von allen Endpunkten
  → Detection Engine: Behavioral Analytics + ML
  → Threat Intelligence Integration: bekannte IOCs, TTPs
  → SIEM/SOAR-Integration via API

Detection-Mechanismen:
  Signaturbasiert:
    → Hash-basiert: bekannte Malware-Dateien
    → Schnell, kein False Positive, aber nur bekannte Malware
    → Grundlage für alle EDRs

  Verhaltensbasiert (Behavioral):
    → Prozess-Baum-Analyse: Office → powershell → cmd → certutil
    → Ist dieser Ablauf für legitime Software normal?
    → Erkennt: Fileless Malware, Living-off-the-Land (LotL)

  Machine Learning:
    → Anomalie-Erkennung: dieses System verhält sich ungewöhnlich
    → Unsupervised: kein Training mit Labels nötig
    → Online Learning: lernt neue Varianten in Echtzeit

  Memory-Analyse:
    → Process Injection erkennen (DLL Injection, Process Hollowing)
    → Reflective DLL Loading: DLL lädt sich selbst aus Memory
    → Shellcode-Erkennung in legitimem Prozess-Speicher

Marktführer im Vergleich

CrowdStrike Falcon:

  Deployment: SaaS (keine lokale Infrastruktur)
  Agent: Leichtgewichtig (~10 MB RAM) - wichtig für Performance
  Stärken: Marktführer im Enterprise-Segment, beste Threat Intelligence
  Besonders: Threat Graph - universeller Graph aller Aktivitäten

  Falcon Module:
    Falcon Prevent:    Schutz (AV-Replacement)
    Falcon Insight:    EDR (Detection + Response)
    Falcon Discover:   Asset Discovery + Hygiene
    Falcon Identity:   AD-Integration, Identity Threat Detection
    Falcon Intelligence: Premium Threat Intelligence
    Falcon Forensics:  Endpoint Forensics

  Falcon Query Language (FQL):
  # Alle Verbindungen zu bekannten C2-IPs in letzten 24h:
  event_simpleName=NetworkConnectIP4
  | filter (RemoteIP="185.220.101.0/24" OR RemoteIP="23.27.163.0/24")
  | since(24h)
  | table(ComputerName, RemoteIP, RemotePort, ImageFileName)

  # Verdächtige PowerShell-Kommandos:
  event_simpleName=ProcessRollup2
  | filter FileName="powershell.exe"
  AND CommandLine=~"*-EncodedCommand*|*-enc *|*IEX*|*Invoke-Expression*"
  | table(ComputerName, UserName, CommandLine, timestamp)

---

Microsoft Defender for Endpoint (MDE):

  Deployment: Native M365-Integration (kein Zusatzprodukt für Windows-Kunden!)
  Agent: In Windows 10/11 integriert (WindowsDefender Service)
  Stärken: Tiefste Windows-Integration, günstig für M365-Kunden, ASR-Rules

  Defender Attack Surface Reduction (ASR):
  # Block via PowerShell (oder Intune):
  Set-MpPreference -AttackSurfaceReductionRules_Ids <GUID> `
    -AttackSurfaceReductionRules_Actions Enabled

  # Wichtige ASR-Rules:
  75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84  # Block process creations from PSExec
  d4f940ab-401b-4efc-aadc-ad5f3c50688a  # Block Office from creating child processes
  9e6c4e1f-7d60-472f-ba1a-a39ef669e4b3  # Block credential stealing from LSASS
  be9ba2d9-53ea-4cdc-84e5-9b1eeee46550  # Block executable content from email

  KQL-Abfragen in Microsoft Sentinel (Defender-Integration):
  # Verdächtige Prozess-Hierachie:
  DeviceProcessEvents
  | where InitiatingProcessFileName == "winword.exe"
    and FileName in ("cmd.exe", "powershell.exe", "wscript.exe")
  | project DeviceName, AccountName, InitiatingProcessCommandLine, ProcessCommandLine
  | order by Timestamp desc

  # LSASS Memory Access:
  DeviceProcessEvents
  | where ProcessCommandLine contains "lsass"
    or (FileName == "procdump.exe" and ProcessCommandLine contains "lsass")
  | project DeviceName, AccountName, ProcessCommandLine, Timestamp

---

SentinelOne:

  Deployment: SaaS + On-Premise Option
  Stärken: Autonomes Response (ohne SOC-Eingriff), Storyline (Attack-Kontext)
  Besonders: ActiveEDR - KI-gestützte autonomous Threat Response

  Storyline-Technologie:
  → Alle Events werden zu "Stories" korreliert (Angriffs-Narrativ)
  → Nicht einzelne Alerts - sondern: "Dies ist die Geschichte des Angriffs"
  → Visualisierung: Prozessbaum + Netzwerk + Dateien in einem Graph

  Autonomous Response:
  → Kill: verdächtigen Prozess beenden
  → Quarantine: Datei in Quarantäne verschieben
  → Rollback: Ransomware-Schaden rückgängig machen (Windows VSS!)
  → Network Isolate: Endpunkt vom Netzwerk trennen

  SentinelOne Deep Visibility (Threat Hunting):
  # STAR (SentinelOne Threat Intelligence Rules):
  SELECT * FROM processes
  WHERE process_name = "powershell.exe"
    AND cmd_line CONTAINS "-EncodedCommand"
    AND parent_process_name NOT IN ("svchost.exe", "msiexec.exe")

---

Carbon Black (VMware):

  Deployment: On-Premise (Carbon Black Enterprise EDR) oder SaaS
  Stärken: Tiefes Recording, On-Premise für regulierte Branchen
  Besonders: Vollständige Process-Recording - minutenlange Angriffs-Timeline

  Carbon Black Bewertung:
  On-Premise-Vorteil: Daten bleiben intern (Gesundheitswesen, KRITIS)
  Nachteil: Infrastruktur-Aufwand, weniger Cloud-native als Konkurrenz

Alert-Tuning und Alert Fatigue vermeiden

Alert Fatigue ist das größte EDR-Problem:
  → Zu viele False Positives → SOC ignoriert Alerts
  → Echter Angriff geht unter!
  → Ziel: < 50 Alerts/Tag pro SOC-Analyst (Richtwert)

Tuning-Prozess:

Phase 1 - Monitoring Mode (Woche 1-2):
  → EDR in "Observe/Monitor" starten (kein Block)
  → Baseline-Alert-Volumen messen
  → Ziel: 0 Blocks in der ersten Woche (Akzeptanz bei Usern!)

Phase 2 - Alert-Klassifizierung:
  → Jeder Alert: TP (True Positive) / FP (False Positive) / Benign?
  → Top 10 Alert-Typen identifizieren
  → Häufigste False-Positive-Quellen:
    - IT-Tools: PSExec, Ansible, SCCM, Remote-Management
    - Entwickler-Tools: Compiler, Debugger, Git-Hooks
    - Monitoring-Agents: Splunk-Forwarder, Puppet
    - Backup-Software: Veeam, Commvault

Phase 3 - Ausnahmeregeln (Exclusions):

  # CrowdStrike Exclusion (API/Console):
  Indicator Exclusion:
    Process: "C:\Program Files\Ansible\python.exe"
    Type: Process Exclusion
    Reason: Legitimes Ansible-Management-Tool
    Scope: Alle Server (Server OU)

  # MDE Exclusion via PowerShell:
  Add-MpPreference -ExclusionProcess "C:\Program Files\Veeam\*"
  Add-MpPreference -ExclusionPath "C:\ProgramData\Backup\temp"

  ⚠️ Exclusion-Prinzipien:
  → So spezifisch wie möglich (Pfad + Prozess, nicht nur Pfad)
  → Nie: ganze Laufwerke oder Systemverzeichnisse ausschließen
  → Dokumentation: warum wurde Ausnahme hinzugefügt? Reviewer?
  → Quarterly Review: veraltete Exclusions entfernen!

Phase 4 - Alert-Schwellwerte:

  HIGH Prio (immer sofort reagieren):
    → LSASS Memory Access / Credential Dump
    → Lateral Movement (PsExec/WMI von unbekannter Quelle)
    → Ransomware-Verhalten (Mass Encryption)
    → C2-Callback zu bekannter IOC-IP
    → Privilege Escalation: Token Impersonation

  MEDIUM Prio (innerhalb 4h):
    → PowerShell Encoded Command
    → Suspicious Scheduled Task
    → User fügt sich lokaler Admin-Gruppe hinzu
    → Suspicious Office Macro

  LOW Prio (täglich im Batch):
    → Port Scanning intern (Pentest oder IT-Tool?)
    → Bekannte PUA (Potentially Unwanted Apps)
    → Veraltete Signaturen auf alten Systemen

EDR für Threat Hunting

Threat Hunting mit EDR-Telemetrie:

Proaktives Hunting - Hypothesen-getrieben:

Hypothese 1: Kerberoasting-Versuch
  # MDE KQL:
  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"
    and RegistryValueName !in (known_autoruns)  // eigene Allowlist!
  | 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  // mehrfache SMB-Verbindungen von ungewöhnlichem Prozess

Hypothese 5: Unusual Parent-Child Process (LotL)
  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

MITRE ATT&CK Mapping im Hunting:
  T1003 (OS Credential Dumping) → Hypothese 2
  T1053 (Scheduled Task/Job) → Scheduled Task Hunt
  T1021 (Remote Services) → Hypothese 4
  T1059 (Command and Scripting) → Hypothese 5
  T1547 (Boot/Logon Autostart) → Hypothese 3

EDR-Integration in Security Operations

SIEM-Integration:

CrowdStrike → Splunk:
  # Splunk Add-on für CrowdStrike:
  index=crowdstrike sourcetype=crowdstrike:events:json
  | eval severity=case(
      Severity>=80, "CRITICAL",
      Severity>=60, "HIGH",
      Severity>=40, "MEDIUM",
      true(), "LOW")
  | stats count by ComputerName, DetectDescription, severity

MDE → Microsoft Sentinel:
  # Data Connector: "Microsoft 365 Defender"
  # Automatisches Forwarding aller MDE-Tabellen nach Sentinel:
  DeviceEvents, DeviceProcessEvents, DeviceNetworkEvents,
  DeviceFileEvents, DeviceRegistryEvents, DeviceAlertEvents

  # Sentinel Workbook: "Endpoint Threat Protection"
  # → Out-of-the-box Dashboard für MDE-Daten

SOAR-Integration:

  Incident → SOAR-Playbook:
  1. Alert aus EDR eingeht
  2. SOAR prüft: ist Endpunkt kritisch? (CMDB-Lookup)
  3. Enrichment: IP-Reputation, User-Context (AD)
  4. Auto-Response (je nach Severity):
     LOW: Ticket erstellen + Analyst informieren
     MEDIUM: Endpunkt isolieren (EDR API) + Ticket
     HIGH: Isolieren + User deaktivieren (AD API) + Eskalation!

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

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

EDR vs. XDR vs. MDR:

  EDR: Endpoint-only-Telemetrie, self-managed
  → Gut für: Unternehmen mit eigenem SOC

  XDR: Endpoint + Netzwerk + E-Mail + Cloud (korreliert)
  → CrowdStrike Falcon XDR, MDE + Sentinel, SentinelOne XDR
  → Besser: breitere Sichtbarkeit, weniger Alert-Silos

  MDR (Managed Detection and Response):
  → Externer SOC-Dienstleister betreibt EDR/XDR
  → 24/7 Überwachung ohne eigenes SOC-Team
  → Anbieter: CrowdStrike Falcon Complete, SentinelOne Vigilance, AWARE7 SOC
  → Empfehlung für KMU ohne eigenes Security-Team!

Sizing und Kosten

EDR-Kosten-Überblick (Enterprise-Preis):

CrowdStrike Falcon:
  Falcon Go:          ~$5/Endpoint/Monat (SMB)
  Falcon Pro:         ~$8-10/Endpoint/Monat
  Falcon Enterprise:  ~$15-20/Endpoint/Monat (inkl. Threat Intel)
  Falcon Complete:    ~$25+/Endpoint/Monat (MDR inklusive)

Microsoft Defender for Endpoint:
  Plan 1:   €2.10/User/Monat (in M365 Business Premium enthalten!)
  Plan 2:   €4.20/User/Monat (in M365 E5 enthalten!)
  → Für M365-Kunden oft kaum Zusatzkosten!

SentinelOne:
  Singularity Core:     ~$5/Endpoint/Monat
  Singularity Control:  ~$8/Endpoint/Monat
  Singularity Complete: ~$12-15/Endpoint/Monat (mit Storyline+)

Sizing-Richtwerte:
  100 Endpoints:  CrowdStrike Pro ~€1.000/Monat
  500 Endpoints:  CrowdStrike Pro ~€4.500/Monat
  1000 Endpoints: Enterprise-Staffelung, ~€8-12k/Monat

TCO-Kalkulation (kein Agent ≠ kein Aufwand):
  Lizenzen:          ~60% der Gesamtkosten
  Deployment:        Initial ~40h für 500 Endpoints
  Tuning (laufend):  ~4-8h/Monat für Alert-Tuning
  SOC-Personal:      größter Kostenfaktor! (1 Analyst ~70-80k EUR/Jahr)
  → MDR ist oft günstiger als interner SOC für <2000 Endpoints