Defender-Übersicht

Einordnung: von Einzellösungen zu XDR

Die Defender-Produktfamilie ist über die Jahre gewachsen. Operativ hilft ein XDR-Blick:

• Defender for Endpoint: Endpunkt-Telemetrie, EDR, Attack Surface Reduction.
• Defender for Office 365: Phishing/Malware-Schutz für Mail/Collab.
• Defender for Identity: Signale aus Identitäts- und AD-/Entra-nahen Quellen.
• Defender for Cloud Apps: CASB-Funktionen, App-Governance, Session Controls.
• Defender XDR Portal: Incidents/Alerts korrelieren über Quellen hinweg.

Was du vor “Features” klären solltest

1) Rollenmodell und Zugriff

Wer darf was?

• Security Operations (Triage/Response)
• Plattform-/Client-Teams (Remediation auf Geräten)
• Identity/Entra-Team (Policies und Break-Glass)

Ohne sauberes Rollenmodell enden Defender-Einführungen oft als “zu viele Admins” oder “niemand kann fixen”.

Ein pragmatischer Zuschnitt, der sich oft bewährt:

• SecOps: Triage/Response im XDR Portal
• Endpoint-Team: Remediation/Hardening (z. B. ASR-Regeln, Onboarding-Qualität)
• Identity-Team: Conditional Access/Break-Glass/privilegierter Zugriff

2) Incident-Workflow

• Welche Alerts erzeugen Tickets?
• Welche Severity bedeutet On-Call?
• Welche Runbooks existieren (Isolation, Offboarding, CA-Block, Passwortreset)?

3) Tuning und Signalqualität

Defender liefert viel Telemetrie. Qualität entsteht durch:

• Baseline Hardening (damit nicht jeder Host “laut” ist)
• Alert Tuning (Suppressions, Regeln)
• klare Verantwortlichkeit für False Positives

Praktisch hilfreich ist ein “Alert-Contract”:

• Welche Severities sind pager-worthy?
• Welche Alerts brauchen zwingend einen Runbook-Link?
• Wer darf Detection Rules ändern (und wie wird das auditiert)?

Integration

• SIEM/SOAR: häufig Microsoft Sentinel, aber auch andere möglich.
• M365/Azure: viele Signale hängen an Entra, CA und Geräte-Compliance.

Einführungsreihenfolge, die sich bewährt

1. Telemetrie stabilisieren (Endpunkte, Mail, Identity-Signale) – erst “sehen”, dann “automatisieren”
2. Rollenmodell und Incident-Workflow festziehen
3. Danach Tuning und Automatisierung (SOAR)

So vermeidest du, dass du “alles” aktivierst, bevor jemand zuverlässig reagieren kann.

Typische Stolperfallen

• “Wir aktivieren alles”: führt zu Alert-Fatigue.
• Keine Ownership für Response: Alerts werden gesehen, aber nicht bearbeitet.
• Lizenzen/Features werden verwechselt: plane, welche Workloads und Plattformen tatsächlich abgedeckt werden.