Neuigkeiten

Kurz erklärt

SIEM und MDR werden häufig in einem Atemzug genannt, lösen aber unterschiedliche Teile derselben Aufgabe. SIEM steht für Security Information and Event Management. Es ist eine technische Plattform, die sicherheitsrelevante Daten aus verschiedenen Systemen zusammenführt und als auswertbare Informationen bereitstellt. So beschreibt es auch das NIST in seiner SIEM-Definition. Ein SIEM kann beispielsweise Anmeldungen, Änderungen an Benutzerkonten, Warnungen von Endgeräten, Cloud-Ereignisse und Netzwerkdaten zentral sammeln, normalisieren und miteinander in Beziehung setzen.

MDR bedeutet Managed Detection and Response. Dahinter steht kein einzelnes Produkt, sondern ein betriebener Sicherheitsdienst. Menschen und Technik arbeiten zusammen, um Warnungen zu überwachen, zu priorisieren, zu untersuchen und – im vereinbarten Umfang – darauf zu reagieren. Microsoft beschreibt MDR entsprechend als Kombination aus Technologie und menschlicher Expertise für Threat Hunting, Monitoring und Reaktion. Welche Systeme ein MDR-Dienst nutzt und welche Maßnahmen er tatsächlich ausführen darf, hängt jedoch vom Anbieter und vom Vertrag ab.

Eine einfache Analogie hilft bei der Einordnung: Das SIEM ist die Instrumententafel mit den zusammengeführten Messwerten. MDR ist die qualifizierte Besatzung, die diese Werte beobachtet, Auffälligkeiten bewertet und nach einem vereinbarten Verfahren handelt. Eine gute Instrumententafel ersetzt keine besetzte Leitstelle. Umgekehrt kann auch ein externes Team nur so gut arbeiten, wie Datenqualität, Zugänge und Reaktionswege es zulassen.

SIEM und MDR im direkten Vergleich

Die entscheidende Erkenntnis lautet deshalb: SIEM und MDR sind weder Synonyme noch zwingende Konkurrenten. Ein MDR-Dienst kann ein vorhandenes SIEM betreiben, eine eigene Plattform mitbringen oder sich stärker auf Endpunkt-, Identitäts- und Cloud-Telemetrie stützen. Für Unternehmen ist nicht nur wichtig, welche Funktionen vorhanden sind, sondern wer daraus zu welcher Zeit eine belastbare Entscheidung macht.

Bedeutung für Unternehmen

Die Frage „SIEM oder MDR?“ führt schnell zu Produktvergleichen. Für Geschäftsführung und IT-Leitung ist eine andere Reihenfolge hilfreicher: Welche Risiken müssen erkannt werden, welche Systeme sind geschäftskritisch, wer bewertet Warnungen und wer darf im Ernstfall handeln? Erst danach lässt sich entscheiden, welches technische und organisatorische Modell passt.

Ein eigenes SIEM kann sinnvoll sein, wenn ein Unternehmen seine Datenhoheit und Erkennungslogik eng selbst steuern möchte und dafür dauerhaft Fachkräfte bereitstellt. Zum Betrieb gehören nicht nur Lizenzen und Datenvolumen. Datenquellen müssen angebunden, Parser und Regeln gepflegt, Fehlalarme reduziert, neue Angriffsmuster berücksichtigt und Bereitschaften organisiert werden. Der bestehende Endline-Beitrag zum wirksamen Log Management beschreibt die notwendige Grundlage: Nicht möglichst viele Logs schaffen Sicherheit, sondern die gezielte Auswahl verwertbarer Ereignisse.

MDR ist besonders relevant, wenn kontinuierliche Überwachung und qualifizierte Analyse benötigt werden, intern aber Zeit, Spezialwissen oder Bereitschaft fehlen. Der NIST-Leitfaden für kleinere Unternehmen empfiehlt ausdrücklich, externe Unterstützung für die Überwachung verdächtiger Aktivitäten und die Reaktion auf Vorfälle zu erwägen, wenn eigene Ressourcen nicht ausreichen. Das entbindet die Unternehmensleitung allerdings nicht von Verantwortung: Kritikalitäten, Freigaben, Ansprechpartner und Geschäftsentscheidungen bleiben intern zu klären.

In der Praxis entstehen drei tragfähige Modelle:

1. SIEM in Eigenregie: passend für Organisationen mit eigenem Security-Team, klarer Rufbereitschaft und genügend Kapazität für Datenpflege, Analyse und Reaktion.
2. MDR mit bereitgestellter Plattform: passend, wenn die Organisation ein betriebenes Ergebnis statt eines eigenen SIEM-Projekts benötigt. Dabei muss geprüft werden, welche Quellen und Reaktionsleistungen enthalten sind.
3. Vorhandenes SIEM plus MDR: passend, wenn zentrale Telemetrie oder Compliance-Anforderungen bereits etabliert sind, aber externe Analysten den laufenden Betrieb, die Triage oder Incident Response ergänzen sollen.

Gerade im Mittelstand ist das dritte Modell oft sinnvoller als ein künstliches Entweder-oder. Ein vorhandenes SIEM behält seinen Wert als zentrale Datenbasis; MDR ergänzt die operative Leistung. Umgekehrt kann ein schlanker MDR-Einstieg geeigneter sein als ein großes SIEM, wenn zunächst nur wenige kritische Systeme und Identitäten zuverlässig überwacht werden sollen. Auch Endpoint Security muss aktiv betrieben werden: Ein installierter Sensor allein stellt noch keine Untersuchung oder Eindämmung sicher.

Technische Einordnung

Technisch lässt sich die gemeinsame Aufgabe als Kette betrachten: Daten entstehen, werden transportiert und aufbereitet, anschließend durch Regeln oder Analysen bewertet, von Menschen untersucht und schließlich in Maßnahmen übersetzt. An jedem Übergang können Lücken entstehen.

1. Telemetrie und Datenqualität

Typische Quellen sind Identitätsanbieter, Verzeichnisdienste, Endgeräte, Server, Firewalls, VPN, E-Mail-Sicherheit, Cloud-Plattformen und geschäftskritische Anwendungen. Vor der Anbindung muss geklärt werden, welche Ereignisse relevant sind, wie Zeitstempel synchronisiert werden, wie lange Daten verfügbar bleiben und ob personenbezogene oder besonders schützenswerte Inhalte enthalten sind. Das BSI beschreibt Detektion als Zusammenspiel organisatorischer, personeller und technischer Maßnahmen. Eine zentrale Plattform ist damit nur ein Baustein.

2. Korrelation und Erkennungslogik

Ein SIEM vereinheitlicht Datenformate und verbindet Ereignisse über Systeme hinweg. Eine einzelne fehlgeschlagene Anmeldung ist meist unkritisch. Mehrere fehlgeschlagene Anmeldungen, ein erfolgreicher Zugriff aus einer ungewöhnlichen Region und eine unmittelbar folgende Änderung privilegierter Rollen können zusammen eine relevante Warnung ergeben. Solche Regeln brauchen Kontext: Welche Konten sind privilegiert? Welche Standorte sind üblich? Welche Systeme sind besonders kritisch? Ohne gepflegte Stammdaten und Rückmeldungen aus Untersuchungen bleibt die Erkennung entweder blind oder laut.

3. Triage und Untersuchung

Hier beginnt die menschliche Leistung, die ein MDR-Vertrag typischerweise abbildet. Analysten prüfen, ob eine Warnung plausibel ist, welche Identität und Geräte betroffen sind, wie sich Aktivitäten zeitlich entwickeln und ob weitere Spuren vorliegen. Gute Triage reduziert Fehlalarme nicht einfach durch Wegklicken, sondern dokumentiert, warum ein Ereignis harmlos oder relevant ist. Diese Rückmeldung sollte wiederum Regeln, Ausnahmen und Priorisierung verbessern.

4. Eindämmung und Reaktion

Mögliche Maßnahmen reichen vom Eröffnen eines Tickets über das Sperren eines Kontos bis zur Isolation eines Endgeräts. Technik allein beantwortet nicht, was ohne Rückfrage geschehen darf. Ein Produktionssystem automatisch zu isolieren kann einen Angriff begrenzen, aber auch einen Geschäftsprozess unterbrechen. Deshalb braucht jeder Anwendungsfall eine abgestimmte Freigabelogik: sofort handeln, erst telefonisch bestätigen oder nur eine Empfehlung aussprechen. Das aktuelle NIST-Modell für Incident Response verankert Erkennung, Reaktion und Wiederherstellung im laufenden Cyberrisikomanagement – nicht als isolierte Aufgabe eines einzelnen Werkzeugs.

5. Lernen und Nachweis

Nach einem bestätigten Vorfall sollten Erkennungsregeln, Datenquellen, Playbooks und Zuständigkeiten angepasst werden. Sinnvolle Kennzahlen sind etwa die Abdeckung kritischer Systeme, die Zeit bis zur qualifizierten Bewertung und die Zeit bis zu einer vereinbarten Eindämmungsmaßnahme. Eine reine Zahl eingegangener Warnungen sagt wenig über Schutzwirkung aus. Berichte müssen technische Erkenntnisse so übersetzen, dass IT-Leitung und Geschäftsführung Entscheidungen zu Risiken, Prioritäten und Investitionen treffen können.

Konkrete nächste Schritte

1. Ziel und Schutzumfang festlegen

Benennen Sie zunächst drei bis fünf konkrete Szenarien, die zuverlässig erkannt werden sollen: zum Beispiel kompromittierte Administrationskonten, verdächtige Cloud-Anmeldungen, Ransomware-Aktivität oder Datenabfluss. Ordnen Sie jedem Szenario kritische Systeme, Datenquellen und geschäftliche Auswirkungen zu. So entsteht ein prüfbarer Bedarf statt einer allgemeinen Tool-Wunschliste.

2. Betriebsfähigkeit ehrlich bewerten

Prüfen Sie, wer Warnungen heute entgegennimmt, wie Abwesenheiten geregelt sind und welche Erfahrung für Untersuchung und Eindämmung vorhanden ist. Wenn diese Verantwortung intern bleibt, müssen Zeitbudget, Qualifikation und Bereitschaft realistisch eingeplant werden. Wenn sie ausgelagert wird, braucht der Dienstleister ausreichenden Kontext und erreichbare interne Entscheider.

3. Angebote anhand des Ergebnisses vergleichen

Fragen Sie nicht nur nach Produktnamen. Lassen Sie sich schriftlich zeigen, welche Quellen im Preis enthalten sind, welche Servicezeiten und Reaktionsziele gelten, welche Maßnahmen ohne Freigabe erlaubt sind, wo Daten verarbeitet werden und wie ein Anbieterwechsel funktioniert. Die NCSC-Auswahlhilfe für Managed Services empfiehlt unter anderem, Verantwortlichkeiten, Incident-Kommunikation, privilegierte Zugänge, Berichte und Exit-Regelungen vor Vertragsabschluss zu klären. Ein pauschales „24/7“ ist erst dann belastbar, wenn Leistung und Eskalation im Vertrag konkret beschrieben sind.

4. Mit einem begrenzten Pilot starten

Beginnen Sie mit den wichtigsten Identitäten, Endgeräten und Cloud-Diensten. Definieren Sie vorab Erfolgskriterien: Kommen die erwarteten Ereignisse an? Sind Warnungen verständlich? Funktioniert die Kontaktkette? Darf und kann eine vereinbarte Maßnahme tatsächlich ausgeführt werden? Ein Pilot sollte nicht nur Dashboards zeigen, sondern mindestens einen realistischen Alarm von der Erkennung bis zur dokumentierten Entscheidung durchspielen.

5. Incident-Prozess gemeinsam üben

SIEM und MDR entfalten ihren Wert erst, wenn technische Warnungen in einen bekannten Ablauf münden. Rollen, Stellvertretungen, Kontaktwege und Entscheidungsgrenzen gehören deshalb in den praktischen Incident-Prozess. Üben Sie regelmäßig, wie Analysten, IT-Betrieb, Datenschutz, Kommunikation und Geschäftsführung zusammenarbeiten.

Sie möchten klären, ob Ihr Unternehmen SIEM, MDR oder eine Kombination benötigt? Monitoring mit Endline besprechen schafft einen konkreten Ausgangspunkt: relevante Datenquellen, Verantwortlichkeiten und Eskalationswege statt eines vorschnellen Produktvergleichs.

Quellen

• Security Information and Event Management (SIEM) Tool — National Institute of Standards and Technology, abgerufen am 12. Juli 2026.
• Was ist MDR? Managed Detection and Response — Microsoft Security, abgerufen am 12. Juli 2026.
• DER.1 Detektion von sicherheitsrelevanten Ereignissen — Bundesamt für Sicherheit in der Informationstechnik, Edition 2023.
• Cybersecurity Framework 2.0: Small Business Quick-Start Guide — National Institute of Standards and Technology, Februar 2024.
• Incident Response Recommendations and Considerations for Cybersecurity Risk Management — National Institute of Standards and Technology, 3. April 2025.
• Choosing a managed service provider — UK National Cyber Security Centre, 24. November 2025.