In Ausschreibungen und Anbietergesprächen tauchen SIEM, SOC, MDR und XDR meist nebeneinander auf, als wären es vier konkurrierende Produkte, aus denen man eines auswählt. Das ist der Grund, warum diese Auswahlprozesse so oft schiefgehen.
Die drei zentralen Begriffe sind nicht einmal dieselbe Art von Sache:
- SIEM ist eine Technologie: ein System, das Sie betreiben oder betreiben lassen.
- SOC ist eine Funktion: Menschen und Prozesse, die etwas mit dem tun, was die Technologie ausspuckt.
- MDR ist ein Liefermodell: die Art, wie Sie beides einkaufen, statt es selbst aufzubauen.
Wer die drei als Alternativen gegeneinanderstellt, vergleicht einen Motor mit einer Werkstatt und einem Leasingvertrag. Alle drei haben mit Autofahren zu tun. Man wählt nicht eines davon aus.
SIEM: die Maschine
Ein Security Information and Event Management-System sammelt Logdaten aus Endpoints, Identity-Systemen, Netzwerk, Cloud-Plattformen und Applikationen, normalisiert sie und korreliert sie zu Alarmen.
Was ein SIEM leistet:
- Zentralisierung: eine Stelle, an der die Spur eines Angriffs über Systemgrenzen hinweg zusammenläuft
- Korrelation: die Verknüpfung von Einzelereignissen zu einer Kette, die kein einzelnes System sieht
- Aufbewahrung: die Datenbasis für Untersuchung und für Nachweispflichten
- Alarmierung: der Übergabepunkt an einen Menschen
Was ein SIEM nicht leistet: entscheiden. Ein SIEM erzeugt Alarme. Ob ein Alarm ein Vorfall ist, ob er eskaliert wird und was danach passiert, ist keine Frage, die eine Regel beantwortet.
Deshalb der Satz, den wir in Projekten so oft sagen, dass er es auf unsere Managed SIEM / SOC-Seite geschafft hat: Ein SIEM ohne Analysten ist ein sehr teurer Alarm, den niemand beantwortet.
SOC: die Menschen
Ein Security Operations Center ist keine Software und kein Raum mit Bildschirmen. Es ist eine Funktion: das Team und die Prozesse, die eingehende Alarme triagieren, untersuchen, eskalieren und beantworten.
Typischerweise umfasst das:
- Triage: ist das ein echter Befund oder ein False Positive?
- Untersuchung: was ist tatsächlich passiert, wie weit ist es gekommen, was ist betroffen?
- Eskalation: wer im Unternehmen muss es wann erfahren?
- Response: eindämmen, isolieren, Remediation begleiten
- Threat Hunting: proaktive Suche nach dem, wofür noch keine Regel existiert
Warum ein eigenes SOC selten am Personalbudget scheitert, sondern an der Arithmetik
Eine Woche hat 168 Stunden. Bei einer 40-Stunden-Woche braucht es rechnerisch 4,2 Personen, um einen einzigen Platz durchgehend zu besetzen. Mit Urlaub, Krankheit, Fortbildung und Fluktuation landet man realistisch bei fünf bis sechs Vollzeitkräften: für genau eine besetzte Position rund um die Uhr.
Und eine Position bedeutet: eine Person allein in der Nachtschicht, ohne Vier-Augen-Prinzip und ohne Eskalationspartner. Wer echte 24/7-Abdeckung mit belastbarer Qualität will, rechnet mit einem Vielfachen davon.
Dazu kommt der Teil, den man nicht einstellen kann: Erfahrung. Ein Analyst wird nicht durch Zertifikate gut, sondern dadurch, dass er hunderte Alarme gesehen hat und weiß, welche davon aussehen wie ein Vorfall und keiner sind.
Genau an dieser Stelle entsteht der Markt für ausgelagerte Modelle.
MDR: das Liefermodell
Managed Detection and Response bedeutet: Ein Dienstleister stellt Technologie, Team und Prozesse und liefert Erkennung und Reaktion als Service. Der Kunde kauft ein Ergebnis statt einer Plattform.
Das ist ein sinnvolles Modell, aber der Begriff ist unreguliert, und die Spannweite dessen, was unter „MDR“ verkauft wird, ist enorm. Zwei Fragen trennen die Angebote:
1. Auf welcher Telemetrie basiert die Erkennung? Viele MDR-Angebote sind im Kern EDR-zentriert: Sie sehen ausgezeichnet, was auf Endpoints passiert, und wenig bis nichts von Identity-Missbrauch, Cloud-Konfigurationsänderungen oder Applikationsebene. Für einen Angriff, der über kompromittierte Zugangsdaten und Microsoft 365 läuft, ohne je Schadcode auf einem Endpoint abzulegen, ist das eine relevante Lücke.
2. Was genau heißt „Response“ im Vertrag? Das ist die Frage, hinter der sich die größten Unterschiede verstecken.
Die eine Vertragsfrage, die wirklich zählt
„Response“ wird auf mindestens drei völlig verschiedenen Stufen verkauft:
| Stufe | Was der Dienstleister tut | Was bei Ihnen bleibt |
|---|---|---|
| Benachrichtigung | Verifizierten Alarm mit Kontext übergeben | Untersuchung, Entscheidung, Handlung |
| Eingegrenzte Aktion | Auf vereinbarten Systemen handeln: Host isolieren, Session beenden, Konto sperren | Entscheidung über alles außerhalb des vereinbarten Rahmens |
| Begleitete Response | Eindämmung durchführen und Remediation bis zum Abschluss begleiten | Freigaben, Business-Entscheidungen, Wiederanlauf |
Alle drei Stufen sind legitim. Nur wird die erste gelegentlich mit dem Vokabular der dritten verkauft.
Die praktische Prüffrage im Anbietergespräch lautet deshalb nicht „Bieten Sie Response an?“, sondern: „Um 03:14 Uhr wird ein Domain-Admin-Konto von einer unbekannten IP benutzt. Was genau tun Sie, ohne vorher jemanden von uns zu erreichen?” Die Antwort auf diese Frage ist die Leistungsbeschreibung.
Und XDR?
Extended Detection and Response ist eine Produktkategorie, keine Servicekategorie: eine Plattform, die Telemetrie aus Endpoint, Identity, Cloud und Netzwerk in einem Herstellerstack zusammenführt und dort korreliert.
XDR steht damit nicht im Gegensatz zum SIEM, sondern überlappt es teilweise: mit einem Unterschied im Charakter: XDR ist tief integriert innerhalb eines Ökosystems, ein SIEM ist breit integrierbar über Ökosysteme hinweg. In heterogenen Umgebungen mit Legacy-Systemen, Branchensoftware und mehreren Cloud-Anbietern stößt der reine XDR-Ansatz regelmäßig an seine Grenzen.
Ob die Plattform dabei in der Cloud oder im eigenen Rechenzentrum läuft, ist eine Betriebsentscheidung und keine Sicherheitsentscheidung: dazu Cloud SIEM vs. On-Premises.
Drei Verwechslungen, die teuer werden
„Wir haben ein SIEM, also haben wir Detection.“ Sie haben die Voraussetzung für Detection. Ob Sie Detection haben, entscheidet sich daran, ob jemand die Regeln pflegt und die Alarme bearbeitet.
„MDR ersetzt unser SIEM.“ Manchmal ja. Aber wenn der Dienstleister ausschließlich auf seinem eigenen Stack arbeitet, verlieren Sie die Fähigkeit, eigene Quellen zu korrelieren und häufig auch den direkten Zugriff auf die Rohdaten, die Sie für eigene Untersuchungen und für Nachweispflichten brauchen. Klären Sie vor Vertragsschluss, wem die Daten gehören und wie Sie im Streitfall an sie herankommen.
„EDR ist im Grunde ein kleines SIEM.“ Nein. EDR sieht Endpoints hervorragend und alles andere gar nicht. Angriffe über Identitäten und SaaS-Dienste hinterlassen auf dem Endpoint oft überhaupt keine Spur.
Welches Modell passt
- Eigenes SIEM, eigenes SOC: sinnvoll ab einer Größe, in der ein Team von mindestens zehn Analysten realistisch finanzierbar und haltbar ist, und dort, wo Detection selbst ein Wettbewerbsfaktor ist.
- Eigenes SIEM, ausgelagerte Bearbeitung: wenn Plattform und Datenhoheit intern bleiben sollen, die 24/7-Besetzung aber nicht darstellbar ist. Der häufigste Fall im gehobenen Mittelstand.
- Vollständig ausgelagert (MDR): wenn es keine bestehende Plattform gibt und Time-to-Value zählt. Achten Sie auf Telemetriebreite und Datenzugriff.
Unsere Leistungsstufen bilden genau diese Linie ab: Stufe 01 baut die Plattform in Ihrer Umgebung auf und übergibt sie. Stufe 02 betreibt sie und liefert verifizierte Alarme an Ihr Team. Stufe 03 übernimmt Triage, Untersuchung und begleitete Response rund um die Uhr. Die Grenze verläuft dort, wo die Kapazität Ihres Teams endet, nicht dort, wo ein Produktkatalog sie zieht.
Fazit
SIEM, SOC und MDR sind keine Alternativen, sondern drei Ebenen derselben Aufgabe: sehen, verstehen, handeln. Die Technologie liefert die Sicht. Die Funktion liefert das Verständnis. Das Liefermodell entscheidet nur darüber, wer die Rechnung stellt und wessen Name im Schichtplan steht.
Die einzige Frage, die alle drei Ebenen gleichzeitig prüft, bleibt: Wer handelt um 03:14 Uhr und wie weit darf er gehen, ohne zu fragen?