SOC-Optionen: Wer bearbeitet den Alarm um drei Uhr nachts?
Ein SIEM erzeugt Alarme. Ob daraus Reaktion wird, entscheiden Menschen, Zuständigkeiten und Erreichbarkeit. Diese Seite vergleicht die drei Betriebsmodelle eigenes SOC, Managed SOC/MDR und Hybrid, beschreibt die Rollen, beantwortet die 24/7-Frage und zeigt, wie Eskalation und Kennzahlen in jedem Modell aussehen.
- 3 Modelle eigenes SOC, Managed SOC/MDR, Hybrid
- 5 Rollen die in jedem Modell besetzt sein müssen
- 24/7 die Frage, die das Modell entscheidet
- MTTD / MTTR Kennzahlen, die den Vergleich ermöglichen
Drei Betriebsmodelle im Vergleich
Alle drei können funktionieren. Welches passt, hängt von Personal, Regulierung, Größe der Anwendungslandschaft und der Frage ab, wie viel Kontrolle Sie behalten wollen und müssen.
| Kriterium | Eigenes SOC | Managed SOC / MDR | Hybrid |
|---|---|---|---|
| Personal | Eigenes Team im Schichtbetrieb, mindestens mehrere Analysten plus Detection Engineering und Leitung. Rekrutierung und Bindung sind der Engpass. | Anbieter stellt Analysten und Schichtbetrieb. Intern eine steuernde Rolle, die Vertrag, Kontext und Eskalationen verantwortet. | Kleines internes Team für Steuerung, Use Cases und Tagesbetrieb; Anbieter für Nacht, Wochenende und Spitzen. |
| Kontrolle und Wissen | Vollständig im Haus: Daten, Regeln, Priorisierung, Umgebungswissen. | Beim Anbieter; Umgebungswissen muss aktiv übergeben und aktuell gehalten werden. | Strategie, Use Cases und Kontext intern, Ausführung geteilt. |
| Zeit bis zur Wirksamkeit | Monate bis Jahre für Aufbau von Team, Prozessen und Erkennung. | Wochen ab Vertragsbeginn, abhängig von der Anbindung der Quellen. | Wochen für die externe Abdeckung, parallel Aufbau der internen Rolle. |
| Kosten | Hohe Fixkosten für Personal und Betrieb rund um die Uhr, unabhängig von der Alarmlast. | Planbare laufende Kosten, oft nach Anzahl der Endpunkte, Nutzer oder Datenvolumen. | Mittlere Fixkosten intern plus laufende Kosten für die externe Abdeckung. |
| Geeignet wenn | Hohe Regulierung, große eigene Anwendungslandschaft, ausreichend Personal, Sicherheit als Kernkompetenz. | Kein Schichtbetrieb möglich, schnelle Wirksamkeit gefordert, Fokus auf das Kerngeschäft. | Internes Wissen vorhanden, aber kein 24/7-Betrieb leistbar; Wunsch nach Kontrolle über Use Cases. |
| Größtes Risiko | Personalabgang, Überlastung, Erkennung veraltet, weil Detection Engineering zu kurz kommt. | Alarme ohne Kontext, unklare Reaktionsbefugnisse, Abhängigkeit vom Anbieter beim Ausstieg. | Alarme fallen zwischen intern und extern durch, wenn Schnittstellen und Eskalation nicht klar sind. |
Fünf Rollen, die in jedem Modell besetzt sein müssen
Ob intern, extern oder geteilt: Diese Funktionen müssen jemandem gehören. Fehlt eine, entsteht die Lücke, in der Vorfälle unbemerkt bleiben.
- Analyse
Alarmbewertung
Erste Sichtung jedes Alarms: Fehlalarm, harmlos oder Vorfall? Braucht Erreichbarkeit im vereinbarten Zeitfenster, Playbooks je Use Case und Zugriff auf Kontextdaten. Im Managed-Modell beim Anbieter, im Hybridmodell nach Zeitfenster geteilt.
- Reaktion
Eindämmung und Vorfallbearbeitung
Konten sperren, Endpunkte isolieren, Verbindungen kappen, Beweise sichern. Braucht Befugnisse, die vorab festgelegt sind, und einen Übergang zum Notfall- und Krisenmanagement bei größeren Vorfällen.
- Detection Engineering
Use Cases und Tuning
Neue Use Cases entwickeln, bestehende testen, Fehlalarme reduzieren, Abdeckung gegen MITRE ATT&CK pflegen. Diese Rolle sollte Ihnen gehören oder vertraglich so geregelt sein, dass der Katalog Ihr Eigentum bleibt.
- Plattform
Betrieb von SIEM und Quellen
Anbindung und Pflege der Log-Quellen, Parser, Speicherstufen, Verfügbarkeit der Plattform, Lizenz- und Volumenüberwachung. Oft unterschätzt und die häufigste Ursache für stille Erkennungslücken.
- Steuerung
Verantwortung und Berichte
Betriebsmodell steuern, Dienstleister führen, Kennzahlen prüfen, an die Geschäftsleitung berichten, Nachweise für NIS2 und ISO 27001 pflegen. Diese Rolle bleibt in jedem Modell intern und ist nicht delegierbar.
- Übergabe
Kontext und Umgebungswissen
Welche Systeme sind kritisch, welche Konten privilegiert, welche Wartungsfenster geplant, welche Ausnahmen bekannt? Ohne diesen Kontext bewertet ein Analyst, intern wie extern, jeden Alarm blind.
Rund um die Uhr: was das bedeutet und wer es leistet
Ein durchgehender Betrieb braucht deutlich mehr Personen, als die meisten annehmen. Diese Rechnung sollte jeder anstellen, bevor er ein eigenes SOC plant.
-
Was ein eigener Schichtbetrieb erfordert
Ein Arbeitsplatz rund um die Uhr, 365 Tage im Jahr, bedeutet mit Urlaub, Krankheit, Schulung und Arbeitszeitgesetz eine Besetzung von mehreren Vollzeitstellen für eine einzige Analystenposition. Dazu kommen Vertretung, Eskalationsstufe und Leitung. Für die meisten mittelständischen Unternehmen ist das nicht zu halten, weder finanziell noch bei der Rekrutierung.
-
Was ein Anbieter leisten muss
Vertraglich festgelegte Reaktionszeiten je Schweregrad, Erreichbarkeit der Eskalationsstufe auf beiden Seiten, Befugnisse für Eingriffe außerhalb der Bürozeiten und ein Meldeweg, der nachts funktioniert. Prüfen Sie, wo der Anbieter sitzt, in welcher Sprache eskaliert wird und ob Ihre Daten die Region verlassen.
-
Was Sie auch mit Dienstleister selbst leisten
Eine Rufbereitschaft auf Ihrer Seite, die nachts Entscheidungen treffen darf: Produktionssystem abschalten oder nicht, Meldung an das BSI vorbereiten oder nicht. Der beste Dienstleister kann nicht eskalieren, wenn niemand abnimmt.
-
Bürozeiten plus Automatisierung als Kompromiss
Für einige Unternehmen genügt ein Betrieb zu Bürozeiten mit automatisierter Reaktion auf kritische Alarme außerhalb, etwa automatische Isolation eines Endpunkts. Diese Entscheidung ist eine Risikoakzeptanz, die die Geschäftsleitung bewusst treffen und dokumentieren sollte.
Vom Alarm zur Entscheidung: Eskalationsstufen
Eskalation ist die Kette, die aus einem Alarm eine Handlung macht. In jedem Modell muss sie mit Namen, Erreichbarkeit und Befugnis hinterlegt sein, sonst endet der Alarm im Ticket.
-
Sichtung und Einordnung
Der Analyst prüft den Alarm nach Playbook: Fehlalarm schließen und dokumentieren, harmlos mit Begründung ablegen, Verdacht weitergeben. Zielgröße: jeder Alarm ist innerhalb der vereinbarten Zeit je Schweregrad angefasst.
-
Vertiefte Analyse und Eindämmung
Erfahrene Analysten verfolgen den Verdacht über Quellen hinweg, bewerten Ausmaß und leiten Eindämmung ein, soweit die Befugnis reicht. Bei externem Betrieb ist hier die erste Kontaktaufnahme mit Ihrer Rufbereitschaft.
-
Vorfallleitung und Geschäftsentscheidung
Ihr Vorfallverantwortlicher übernimmt: Entscheidung über Eingriffe in Produktivsysteme, Einbindung von IT-Leitung, Datenschutz und Recht, Prüfung der Meldepflicht nach § 32 BSIG mit ihren Fristen.
-
Krisenmanagement
Bei Auswirkungen auf das Geschäft übernimmt der Krisenstab. Der Übergang aus dem SOC in das Notfall- und Krisenmanagement muss geübt sein; die Schnittstelle ist in vielen Unternehmen die schwächste Stelle der Kette.
Für jede Stufe festlegen: wer, mit welcher Erreichbarkeit, mit welcher Befugnis, in welcher Zeit. Schriftlich, mit Vertretung, und mindestens einmal im Jahr in einer Übung durchgespielt. Das gilt für interne Teams genauso wie für die Schnittstelle zum Dienstleister.
MTTD und MTTR: Kennzahlen für jedes Modell
Die beiden Kennzahlen machen Betriebsmodelle vergleichbar und zeigen, ob ein Dienstleister liefert. Sie gehören in jeden Vertrag und in jeden Bericht an die Geschäftsleitung.
| Kennzahl | Was sie misst | Wovon sie abhängt | Wie sie erhoben wird |
|---|---|---|---|
| MTTD, Mean Time to Detect | Mittlere Zeit vom Beginn eines Angriffs oder einer Fehlfunktion bis zum Alarm. | Abdeckung der Log-Quellen, Qualität der Use Cases, Verzögerung der Datenanlieferung. | Rückwirkend aus der Analyse realer Vorfälle und laufend über simulierte Angriffsschritte mit Zeitmessung. |
| MTTR, Mean Time to Respond | Mittlere Zeit vom Alarm bis zur Eindämmung. | Erreichbarkeit, Befugnisse, Playbooks, Eskalationskette, Zusammenspiel intern und extern. | Aus dem Ticketsystem je Schweregrad; Zielwerte vertraglich mit dem Anbieter und intern mit der Geschäftsleitung vereinbaren. |
| Anteil bearbeiteter Alarme in der Zielzeit | Wie viele Alarme wurden innerhalb der vereinbarten Zeit je Schweregrad angefasst? | Alarmlast, Fehlalarmrate, Personalstärke. | Aus dem Ticketsystem; zeigt Überlastung früher als MTTR. |
| Abdeckung | Welche relevanten Taktiken und Systeme sind durch Use Cases abgedeckt? | Detection Engineering, Anbindung der Quellen. | Abdeckungsmatrix gegen MITRE ATT&CK, jährlich überprüft. |
Vertiefung zu SIEM und SOC
-
SIEM Tool-Auswahl
Sechs Kriterien, Preismodelle nach Ingest und Retention, Cloud oder On-Prem und die Einordnung von Sentinel, Splunk, Elastic, QRadar und Wazuh.
-
Log-Quellen priorisieren
Welche Quellen den höchsten Erkennungswert liefern, wie Retention geplant wird und warum das Volumen die Kosten treibt.
-
SIEM-Beratung im Überblick
Grundlagen, Betriebsmodelle, unser Vorgehen in vier Schritten, Kennzahlen und der Selbsttest für Ihr SIEM.
Zu den SOC-Optionen
Brauchen wir wirklich 24/7?
Angriffe passieren bevorzugt nachts, am Wochenende und an Feiertagen, weil dann niemand hinsieht. Die Frage ist deshalb nicht, ob Sie rund um die Uhr Erkennung brauchen, sondern wer sie leistet. Ein eigenes Team im Schichtbetrieb ist für die meisten mittelständischen Unternehmen nicht zu halten. Ein MDR-Dienst oder ein Hybridmodell mit externer Abdeckung außerhalb der Bürozeiten ist der übliche Weg.
Was ist der Unterschied zwischen Managed SOC und MDR?
Die Begriffe überschneiden sich. Ein Managed SOC betreibt in der Regel Ihr SIEM oder eine eigene Plattform und liefert Überwachung und Alarmbewertung. Managed Detection and Response betont zusätzlich die Reaktion: Der Anbieter greift nach vereinbarten Regeln selbst ein, etwa indem er Endpunkte isoliert oder Konten sperrt. Entscheidend ist nicht das Etikett, sondern was der Vertrag an Reaktionsbefugnissen und Reaktionszeiten festlegt.
Was bleibt bei uns, wenn wir einen MDR-Dienst beauftragen?
Mehr, als viele erwarten. Die Verantwortung für die Sicherheit bleibt bei Ihnen. Sie müssen Kontext liefern, Eskalationen entgegennehmen, Entscheidungen über Eingriffe treffen und im Vorfall die Geschäftsseite führen. Sie brauchen mindestens eine Person, die den Dienstleister steuert, den Use-Case-Katalog verantwortet und Kennzahlen prüft. Ohne diese Rolle läuft der Dienst ins Leere.
Wie wird MTTD gemessen, wenn wir den Angriff erst durch den Alarm kennen?
Über zwei Wege: bei realen Vorfällen rückwirkend aus der forensischen Analyse, die den Beginn des Angriffs datiert, und laufend über Tests, bei denen definierte Angriffsschritte simuliert und die Zeit bis zum Alarm gemessen wird. Der zweite Weg ist der wichtigere, weil er ohne echten Vorfall funktioniert und regelmäßig wiederholt werden kann.
Können wir mit einem Hybridmodell starten und später wechseln?
Ja, und das ist oft der sinnvollste Weg. Ein kleines internes Team übernimmt Steuerung, Use Cases und Kontext, ein Dienstleister die Abdeckung außerhalb der Bürozeiten. Wächst das Team, kann es Aufgaben zurückholen; wächst der Bedarf, kann der Dienstleister mehr übernehmen. Wichtig ist, dass Use-Case-Katalog, Dokumentation und Kennzahlen Ihnen gehören, damit ein Wechsel möglich bleibt.
Edouard Jacques
Welches Betriebsmodell trägt Ihr Unternehmen?
Im kostenlosen Erstgespräch klären wir Personal, Regulierung und Erkennungsziele und leiten daraus ab, ob eigenes SOC, Managed SOC/MDR oder Hybrid zu Ihnen passt. Ohne eigenes Interesse am Betrieb.
- Einordnung des Betriebsmodells nach Ihrer Ausgangslage
- Rollen und Eskalationskette mit Namen und Befugnissen
- Kennzahlen und Vertragspunkte für die Anbieterauswahl
Danke, wir rufen Sie an.
Sie hören innerhalb eines Werktags von uns, meist deutlich schneller. Wenn Sie lieber gleich einen festen Termin wählen möchten, geht das direkt im Kalender auf jamorie.eu.
Termin selbst wählen