MDR vs. SIEM: Unterschiede & Einstiegshilfe für Unternehmen

Begriffsdefinition: Was ist MDR? Was ist SIEM?

Was ist ein SIEM?

Ein SIEM ist so etwas wie eine zentrale Sammel- und Auswertestelle für Sicherheitsdaten im Unternehmen. Es hilft dabei, aus vielen Einzelinformationen Hinweise auf echte Sicherheitsprobleme zu geben:

1. Es sammelt Protokolle und Ereignisse aus verschiedenen Quellen, bspw. von Benutzerkonten/Logins (Identity), Endgeräten, dem Netzwerk, Cloud-Diensten oder Anwendungen.
2. Es bringt diese Daten in eine einheitliche Form und ergänzt Kontext, z. B. „Welches Gerät ist das?“, „Welcher Nutzer gehört dazu?“, „Ist das ein kritisches System?“
3. Es erkennt Auffälligkeiten, indem es Informationen miteinander verknüpft, Regeln anwendet und teils auch Muster analysiert (z. B. ungewöhnliches Nutzerverhalten).
4. Es erstellt Alarme und Fälle, die dann von Menschen oder einem SOC/MDR-Team weiter geprüft und bearbeitet werden.

Wichtig: Ein SIEM liefert vor allem Hinweise (Signale) und Tickets/Fälle. Es löst das Problem nicht automatisch.
Wie gut es funktioniert, hängt stark davon ab,

• wie gut die Daten sind (vollständig, korrekt, relevant),
• welche konkreten Erkennungsregeln/Use Cases eingerichtet sind, und
• ob es klare Prozesse gibt, wer Alarme prüft, entscheidet und reagiert.

Was ist MDR?

MDR (Managed Detection and Response) ist eine Betriebsleistung (Service), die Security Operations für definierte Datenquellen/Technologien übernimmt. Typische Bestandteile:

• 24/7 Monitoring: Ein Team schaut 24/7 auf Sicherheitsmeldungen, prüft was wirklich kritisch ist, bestätigt echte Vorfälle und filtert Fehlalarme raus.
• Aktiv nach versteckten Angriffen suchen: Statt nur auf Alarme zu warten, wird gezielt nach verdächtigen Spuren gesucht.
• Vorfälle untersuchen und bearbeiten: Wenn etwas auffällig ist, wird analysiert, was betroffen ist, wie groß der Schaden sein könnte und wie der Angriff vermutlich begonnen hat.
• Reagieren und eindämmen (je nach Vertrag): Maßnahmen einleiten, um den Angriff zu stoppen oder zu begrenzen, z. B. ein Gerät vom Netz trennen, verdächtige Verbindungen sperren, Passwörter/Accounts absichern und die nächsten Schritte im Ticket-System koordinieren.
• Berichten und optimieren: Regelmäßige Reports mit verständlichen Kennzahlen (z. B. wie schnell etwas erkannt/gestoppt wurde) und kontinuierliche Verbesserungen: bessere Alarmregeln, klare Vorgehenspläne und eine Liste von Sicherheitsmaßnahmen, die im Unternehmen umgesetzt werden sollten.
• Wichtig: MDR kann mit verschiedenen „Datenquellen“ arbeiten, zum Beispiel Signalen von Endpoint-Schutzlösungen (EDR/XDR), aus einem SIEM, aus Cloud-Protokollen oder aus Login-/Identitätsdaten. Deshalb ist MDR nicht einfach „eine Software“, sondern ein klar definierter Service: Es ist festgelegt, was überwacht wird (Scope) und wie schnell bzw. in welcher Qualität reagiert wird (SLA).

Kernunterschiede: Plattform (SIEM) vs. Betrieb (MDR)

Hinweis: Viele Unternehmen unterschätzen, dass der Erfolg weniger am „Tool“ hängt, sondern am laufenden Betrieb: Alarme verbessern, Regeln pflegen, Vorfälle untersuchen, Bereitschaft/Erreichbarkeit organisieren, Vorgehenspläne testen und alles sauber dokumentieren. Das gilt auch dann, wenn bereits ein SIEM vorhanden ist.

MDR, SIEM oder eine Kombination aus beidem? Entscheidung nach Zielbild

Wann MDR typischerweise priorisiert wird (häufig KMU/IT-Leitung/Operations)

MDR ist oft die pragmatische Wahl, wenn:

• 24/7 Reaktionsfähigkeit gefordert ist, aber intern nicht darstellbar,
• die Organisation vor allem risikorelevante Incidents sehen und behandeln will,
• Security-Rollen klar sind, aber Tiefe/Verfügbarkeit fehlt (SOC-Betrieb).

Typische Ausgangslage: „Wir wollen weniger False Positives, schnellere Einordnung und einen klar geregelten nächsten Schritt pro Incident.“

Wann SIEM typischerweise priorisiert wird (häufig stärker reguliert/Enterprise/Plattformstrategie)

SIEM wird oft priorisiert, wenn:

• viele Domänen zentral korreliert werden müssen (Identity + Cloud + Netzwerk + App),
• Retention/Forensik und Reporting tragende Anforderungen sind,
• eine Organisation Use-Case-Ownership und Betriebsprozesse intern tragen kann (oder bewusst Co-Managed betreibt).

Wann eine Kombination aus MDR und SIEM sinnvoll ist

Die Kombination aus MDR und SIEM ist sinnvoll, wenn:

• SIEM als zentrale Daten- und Korrelationsebene dient,
• MDR als Operations-Layer die Alerts/Cases in Incidents überführt und Response steuert,
• Verantwortlichkeiten sauber getrennt sind: Daten-/Use-Case-Owner vs. Incident-Owner.

Schritt-für-Schritt-Einstieg

1. Klarheit schaffen: Was genau soll geschützt werden?

Bevor man Tools ankoppelt oder Alarme baut, sollte klar sein:

• Welche Systeme sind besonders kritisch?
  Zum Beispiel: Benutzerkonten & Logins, E-Mail, ERP/Finanzen, Produktions-IT, Admin-Zugänge.
• Welche Angriffe sind für uns realistisch?
  Typischer Ablauf: Phishing-Mail → Zugangsdaten werden geklaut → Angreifer bewegt sich weiter im Netzwerk → Daten werden gestohlen oder Systeme verschlüsselt.
• Was können wir im Ernstfall organisatorisch überhaupt tun?
  Wer darf ein Gerät vom Netz nehmen? Wer informiert Management? Wer muss rechtlich eingebunden werden? Gibt es externe Hilfe?

Ergebnis: Ein kurzes Dokument mit Systemliste, Verantwortlichen, Eskalationswegen (wer wird wann informiert) und Entscheidungsregeln.

2. Datenquellen priorisieren

Mehr Daten heißt nicht automatisch bessere Sicherheit. Sinnvoll ist, zuerst die Quellen anzubinden, die echte Entscheidungen ermöglichen, beispielsweise:

• Login- und Identitätsdaten (z. B. ungewöhnliche Anmeldungen, plötzlich neue Admin-Rechte)
• Daten von Endgeräten (z. B. Verhalten auf Laptops/Servern: verdächtige Programme, ungewöhnliche Befehle; ggf. Gerät isolieren)
• E-Mail-Sicherheit (z. B. Phishing, gefälschte Absender)
• Cloud-Protokolle (z. B. Admin-Änderungen, neue Zugänge, geänderte Berechtigungen)
• Netzwerk-/DNS-Hinweise (z. B. Kontakt zu bekannten schädlichen Servern, auffällige Datenabflüsse)

Das Ziel: Erst das anbinden, womit man im Vorfall wirklich entscheiden kann: „Ist das ein echter Angriff? Was ist betroffen? Was müssen wir tun?“

3. Use Cases definieren

Ein „Use Case“ ist ein konkreter Alarm-/Erkennungsfall mit klarer Reaktion. Starten sollten Sie mit Fällen, die

• häufig vorkommen,
• großen Schaden verursachen können,
• klar behandelbar sind.

Typische Beispiele:

• Konto kompromittiert: Anzeichen, dass ein Account übernommen wurde (z. B. ungewöhnliche Logins, Hinweise auf MFA-Umgehung)
• Verdächtige Rechteänderungen: Plötzlich bekommt jemand Admin-Rechte oder Zugänge werden auffällig erweitert
• Verdächtige Befehle auf Endgeräten: typische „Angreifer-Werkzeuge“/Befehle, die selten legitim sind
• Remote-Zugriffstools/laterale Bewegung: Angreifer versucht, von einem System zum nächsten zu springen
• Auffällige Datenbewegung: ungewöhnlich viele Daten in Cloud-Speicher, Downloads, Exporte, externer Abfluss

Woran erkennt man einen guten Use Case?
Er ist so aufgebaut: Auslöser → Kontext → Entscheidung (wie kritisch?)→ Umsetzungsplan

4. Prozesse & Rollen festlegen

Viele Programme scheitern nicht am Tool, sondern daran, dass im Ernstfall niemand weiß, wer entscheiden darf. Sie sollten daher mindestens klären:

• Wer trifft die Entscheidung im Incident? (Incident Owner: Priorität, Maßnahmen, Freigaben)
• Wie laufen Eskalation und Freigaben ab? (z. B. „Darf ein Gerät sofort isoliert werden?“)
• Welche Kommunikationswege gelten verbindlich? (Ticket, Hotline, Chat – und wann welches davon)
• Welche Vorgehenspläne gibt es? (z. B. Phishing, Kontoübernahme, Malware, Datenabfluss)

Typische Fehler und wie man sie vermeidet

Scope ist unklar

Sie überwachen alle Daten gleichermaßen: ein paar Server, ein paar Logins, ein paar Tools. Es kommen Alarme rein, aber niemand weiß:

• Welche Systeme sind wirklich kritisch?
• Welche Alarme sind bei uns wirklich gefährlich?
• Welche Reaktion ist überhaupt erlaubt/gewünscht?

Beispiel:
Ein Alarm sagt „Admin-Login ungewöhnlich“. Ist das schlimm? Möglicherweise. Wenn jedoch unklar ist, welche Admin-Konten kritisch sind und wer zuständig ist, bleibt der Alarm folgenlos.

Was hilft?

1. Erst festlegen: Top-Systeme (Tier 1), z. B. Identity/AD, E-Mail, ERP, Admin-Zugänge.
2. Dann: Top-10 Alarmfälle, die Sie wirklich betreffen können.
3. Und: Reaktionsregeln (z. B. „Bei bestätigter Kontoübernahme Passwort zurücksetzen + Session beenden + MFA neu setzen“).

Zu viele Daten, zu wenig Qualität

Sie kippen alles ins System: jede Kleinigkeit von jedem Gerät und jeder App. Das führt zu:

• zu hohen Kosten (viel Datenmenge),
• zu vielen unnötigen Alarmen,
• und am Ende schaut niemand mehr richtig hin, weil das System zu häufig alarmiert.

Beispiel:
Sie sammeln Millionen Logzeilen aus einem Webserver, allerdings haben Sie keine sauberen Login-/Identity-Daten angebunden. Ergebnis: wenig echte Sicherheitsentscheidungen.

Was hilft?

• Nicht „alles“, sondern zuerst die wichtigsten Quellen: Identity (Logins), Endpoint (EDR), E-Mail, Cloud-Admin-Logs.
• Daten „anreichern“, damit man sie versteht, z. B. „Dieses Gerät gehört zur Buchhaltung“, „dieser User ist Admin“, „dieser Server ist Tier 1“.
• Rauschen reduzieren: unwichtige Logs rausfiltern, doppelte Events vermeiden, klare Regeln, welche Daten wirklich gebraucht werden.

Use Cases ohne Vorgehensplan

Alarme sind da, allerdings weiß keiner:

• Ist das wirklich gefährlich oder nur ein Fehlalarm?
• Was müssen wir jetzt tun?
• Wer entscheidet das?

Beispiel:
Alarm: „Verdächtige PowerShell-Aktivität“.
Ohne konkreten Plan weiß niemand, ob isolieren, prüfen oder ignorieren.

Was hilft?
Für jeden wichtigen Alarmfall braucht es 4 Punkte:

1. Auslöser: Was genau löst den Alarm aus?
2. Kontext: Was macht ihn bei uns gefährlich? (z. B. Admin-User, Tier-1-System)
3. Entscheidung: Wann ist es kritisch?
4. Maßnahmenplan: Was passiert dann Schritt für Schritt?

Das Ergebnis: Jeder Alarm führt zu einer klaren Entscheidung.

Keine Zuständigkeiten

Das System läuft, langfristig wird es jedoch schlechter, da:

• Regeln nicht gepflegt werden,
• neue Systeme nicht sauber angebunden werden,
• im Ernstfall niemand schnell entscheidet.

Beispiel:
Ein neuer Cloud-Dienst wird eingeführt, allerdings sorgt niemand dafür, dass Logs angebunden werden. Oder: Es gibt wiederholt Fehlalarme, doch niemand fühlt sich verantwortlich, die Regel zu verbessern.

Was hilft konkret?
Einfache Rollenaufteilung für KMU und Enterprise-Unternehmen:

• Daten-Verantwortliche(r): sorgt dafür, dass die richtigen Datenquellen angebunden sind und sauber laufen.
• Alarm-/Use-Case-Verantwortliche(r): kümmert sich darum, dass Alarme sinnvoll sind (weniger Fehlalarme, bessere Qualität).
• Incident-Verantwortliche(r): entscheidet im Vorfall (Priorität, Maßnahmen, Eskalation).
• Service-Partner (z. B. MDR): macht Überwachung, Analyse, unterstützt bei Investigation und ggf. Response.

Das Ergebnis: Der Betrieb bleibt stabil.

Merksatz für Einsteiger

Die häufigsten Probleme sind:

1. Wir wissen nicht, was wichtig ist (Scope).
2. Wir sammeln zu viel Unnötiges (Datenrauschen).
3. Wir haben keinen festen Plan (Vorgehen).
4. Keiner ist wirklich zuständig (Ownership).