Ein Security Operations Center (SOC) ist die Stelle, an der eine Organisation ihre Verteidigung bündelt: Menschen, Prozesse und Werkzeuge, die Alarme bewerten, Angriffe erkennen und die Reaktion anstoßen, oft rund um die Uhr. In diesem Beitrag erfährst du, was ein SOC tut, wie es aufgebaut ist, was hinter dem Tier-Modell steckt, wie ein Arbeitstag dort aussieht und woran du ein gutes SOC erkennst. Egal, ob du eines aufbauen, beauftragen oder dort arbeiten willst.
Security Operations Center: eine Definition
Ein SOC ist die organisatorische Einheit, die den Sicherheitsbetrieb verantwortet. Es sammelt sicherheitsrelevante Daten aus der gesamten IT, überwacht sie, bewertet Auffälligkeiten und koordiniert die Reaktion. Der Name variiert: Cyber Defense Center, Cyber Defense and Response Center, Security Operations, Fusion Center. Gemeint ist dieselbe Funktion. Und das SOC ist nicht das ganze Blue Team, sondern dessen operativer Kern. Was das Blue Team darüber hinaus umfasst, steht im Grundlagenartikel Was macht ein Blue Team?.
Drei Betriebsmodelle sind verbreitet. Das eigene SOC mit eigenem Personal, das ausgelagerte SOC bei einem Managed Security Service Provider (MSSP) und das Hybridmodell, bei dem der MSSP das 24/7-Monitoring und die Erstbewertung übernimmt und ein internes Team die Reaktion im eigenen Haus. Für die meisten mittelständischen Unternehmen ist das Hybridmodell das realistische, und der Grund ist reine Arithmetik: 24 Stunden an 7 Tagen sind 168 Stunden pro Woche. Ein einziger durchgehend besetzter Arbeitsplatz braucht damit mindestens fünf Vollzeitstellen, bevor Urlaub, Krankheit und Schulungen überhaupt eingerechnet sind.
Was ein SOC tut
- Monitoring und Triage. Alarme aus SIEM, EDR, Netzwerksensoren, Mail-Gateway und Cloud-Plattformen laufen in einer Warteschlange auf. Jeder Alarm wird bewertet: echt oder Fehlalarm, und wie dringend?
- Analyse. Bei einem echten Treffer wird der Kontext zusammengetragen: Welcher Benutzer, welches System, was ist davor und danach passiert, ist es ein einzelner Rechner oder bewegt sich jemand durchs Netz?
- Eskalation und Reaktion. Nach Playbook: Host isolieren, Konto sperren, Ticket an das Incident-Response-Team oder CSIRT übergeben, Betroffene informieren. Was ab diesem Punkt passiert, beschreibt der Incident-Response-Prozess.
- Detection Engineering. Neue Erkennungsregeln schreiben, bestehende nachschärfen, Fehlalarme abstellen. Ohne diese Arbeit ertrinkt jedes SOC innerhalb weniger Monate in Alarmen.
- Threat Hunting. Proaktiv nach Spuren suchen, für die es noch keinen Alarm gibt.
- Reporting. Kennzahlen und Vorfallberichte für Management, Kunden oder Aufsicht.
Je nach Zuschnitt kommen Schwachstellenmanagement, Awareness oder der Betrieb der Sicherheitswerkzeuge dazu. Ein SOC, das nur Alarme abarbeitet und nie eigene Regeln schreibt, ist kein SOC, sondern eine Warteschlange mit Menschen davor.
Rollen und das Tier-Modell
Das klassische SOC ist in drei Stufen organisiert, die Tiers. Sie beschreiben, wer sich wie tief mit einem Alarm beschäftigt.
Tier 1: Triage
Die erste Linie. Tier-1-Analysten arbeiten die Alarmwarteschlange ab, entscheiden innerhalb von Minuten, ob ein Alarm ein Fehlalarm ist, dokumentieren und eskalieren alles, was nicht eindeutig harmlos ist. Hier liegt das größte Volumen, und hier beginnen die meisten SOC-Karrieren. Wie der Einstieg gelingt, steht im Beitrag SOC-Analyst werden. Ob ein SOC intern, extern oder hybrid betrieben wird, wägt der Beitrag MSSP oder eigenes SOC ab. Zwei Spezialisierungswege beschreiben Vom SOC-Analyst zum Detection Engineer und DFIR als Berufsweg.
Tier 2: Analyse und Reaktion
Tier 2 übernimmt eskalierte Fälle, korreliert Daten aus mehreren Quellen, baut eine Zeitlinie und leitet die ersten Gegenmaßnahmen ein. Hier entscheidet sich, ob aus einem Alarm ein Vorfall wird.
Tier 3: Hunting, Detection Engineering, Forensik
Die erfahrensten Leute. Sie übernehmen komplexe Vorfälle, jagen proaktiv, schreiben die Erkennungsregeln, die Tier 1 später abarbeitet, und sichern bei Bedarf forensisch. Drumherum arbeiten Rollen, die nicht in das Stufenmodell passen: SOC-Manager oder Teamlead, Threat-Intelligence-Analysten, Plattform-Engineers für SIEM und Datenanbindung, Incident-Response-Koordinatoren.
Das Tier-Modell hat einen bekannten Nachteil: Übergaben kosten Zeit, und Tier 1 wird zur Durchlaufstation, in der Analysten nach einem Jahr weiterziehen, weil sie nur Fehlalarme schließen. Viele SOCs arbeiten deshalb ohne feste Stufen: Ein Analyst übernimmt einen Alarm und begleitet ihn bis zum Ende, holt sich bei Bedarf Unterstützung. MITRE rät in seinem SOC-Handbuch ausdrücklich dazu, die Struktur an die Organisation anzupassen statt umgekehrt. Kleine Teams mit drei oder vier Leuten brauchen keine Tiers, sondern klare Absprachen.
Ein Arbeitstag im SOC
Der Tag beginnt mit der Schichtübergabe: offene Fälle, laufende Vorfälle, angekündigte Wartungsfenster und Pentests, damit niemand einen geplanten Scan für einen Angriff hält. Dann die Warteschlange. Ein Alarm meldet eine Anmeldung aus einem Land, in dem das Unternehmen niemanden beschäftigt. Der Analyst prüft: Wer ist der Benutzer, hat er sich vorher schon von dort angemeldet, läuft die Verbindung über ein VPN, gab es davor einen fehlgeschlagenen Login-Sturm? Nach fünf Minuten steht fest: Kollege im Urlaub, Anmeldung per Mobilgerät, MFA bestätigt. Fehlalarm, dokumentiert, geschlossen, und ein Hinweis an das Detection Engineering, dass die Regel VPN-Anmeldungen ausnehmen sollte.
Der nächste Alarm ist keiner: Ein Dienstkonto startet auf einem Fileserver eine PowerShell mit kodiertem Befehl. Innerhalb von Minuten geht es um Kontext, Zeitlinie und Eindämmung, und aus einem Ticket wird ein Vorfall. So sieht das Verhältnis im Alltag aus: viele Fehlalarme, wenige echte Treffer, und die Kunst liegt darin, den einen nicht zu übersehen, weil die anderen 40 harmlos waren. In kleineren SOCs kommt nachts und am Wochenende die Bereitschaft dazu, bei MSSPs der ständige Wechsel zwischen Kundenumgebungen, die jede ihre eigene Definition von „normal“ haben.
Kennzahlen, die etwas aussagen
Die Zahl der geschlossenen Tickets sagt nichts über die Qualität eines SOC aus, sie belohnt schnelles Wegklicken. Aussagekräftiger sind:
- Time to Detect und Time to Respond: Wie lange vergeht vom ersten Ereignis bis zum Alarm, und vom Alarm bis zur Eindämmung?
- Fehlalarmquote pro Regel: Welche Regeln erzeugen Arbeit ohne Nutzen und gehören nachgeschärft?
- Alarme pro Analyst und Schicht: Ab einer bestimmten Zahl wird nicht mehr analysiert, sondern nur noch geschlossen.
- Abdeckung nach MITRE ATT&CK: Welche Angriffstechniken würde das SOC erkennen, welche nicht? Das prüfst du nicht auf dem Papier, sondern mit Purple-Team-Übungen.
Woran du ein gutes SOC erkennst: die elf Strategien von MITRE
MITRE hat mit 11 Strategies of a World-Class Cybersecurity Operations Center ein frei verfügbares Handbuch veröffentlicht, das sich seit Jahren als Referenz für Aufbau und Betrieb hält. Die elf Strategien in Kurzform:
- Wissen, was geschützt wird und warum.
- Dem SOC die Befugnis geben, seine Arbeit zu tun.
- Die SOC-Struktur an die Organisation anpassen.
- Gute Leute einstellen und weiterentwickeln.
- Incident Response priorisieren.
- Angreifer mit Threat Intelligence sichtbar machen.
- Die richtigen Daten auswählen und sammeln.
- Werkzeuge einsetzen, die den Arbeitsablauf der Analysten unterstützen.
- Klar kommunizieren, oft zusammenarbeiten, großzügig teilen.
- Leistung messen, um sie zu verbessern.
- Den Funktionsumfang schrittweise erweitern.
Wenn du ein SOC beauftragst oder bewertest, frag nach Nummer eins, zwei, sieben und zehn. Ein SOC, das nicht weiß, welche Systeme für das Geschäft kritisch sind, das nachts keinen Server isolieren darf, dem die Logs der Domain Controller fehlen oder das seine Erkennungsleistung nicht misst, kann noch so viele Bildschirme haben.
Woran SOCs scheitern
- Alarmflut. Zu viele Regeln, zu wenig Tuning. Die Analysten stumpfen ab, und der echte Treffer geht in der Menge unter.
- Fehlende Logquellen. Das beste SIEM sieht nichts, wenn Active Directory, Endpunkte oder die Cloud-Plattform nicht angebunden sind.
- Werkzeug statt Prozess. Ein gekauftes SIEM ist kein SOC. Ohne Playbooks, Zuständigkeiten und Eskalationswege bleibt es ein teurer Logspeicher.
- Kein Mandat. Wenn das SOC für jede Gegenmaßnahme erst eine Freigabe braucht, verliert es die Stunden, in denen ein Vorfall noch klein ist.
- Fluktuation. Tier-1-Arbeit ohne Entwicklungsperspektive führt dazu, dass das Wissen über die eigene Umgebung alle zwölf Monate neu aufgebaut werden muss.
Fazit
Ein Security Operations Center ist kein Raum voller Monitore, sondern eine Funktion: Daten sammeln, Alarme bewerten, reagieren, und aus jedem Fall die Erkennung verbessern. Ob mit oder ohne Tiers, intern oder beim Dienstleister, entscheidend sind die Fragen, die MITRE an den Anfang stellt: Was schützen wir, darf das SOC handeln, sehen wir die richtigen Daten, und messen wir, ob wir besser werden? Wer diese vier Fragen ehrlich beantworten kann, hat den Kern eines guten SOC. Alles andere ist Ausbau.