Ein SOC ist die zentrale Einheit aus Menschen, Prozessen und Technik, die Sicherheitsereignisse rund um die Uhr überwacht, Angriffe erkennt, bewertet und die Reaktion koordiniert.
Ein Security Operations Center (SOC) bündelt die operative Verteidigung eines Unternehmens an einem Ort: Analystinnen und Analysten beobachten Sicherheitsereignisse aus Netzwerk, Endgeräten, Identitäten und Cloud, bewerten Alarme und leiten bei einem bestätigten Vorfall die Reaktion ein. Technische Grundlage sind meist ein SIEM zur Korrelation von Logdaten, EDR auf den Endpunkten und eine Ticket- oder Case-Plattform für die Fallbearbeitung.
Ein SOC kann intern betrieben, vollständig an einen Dienstleister ausgelagert (Managed SOC, MDR) oder hybrid organisiert sein. Entscheidend ist nicht das Betriebsmodell, sondern ob das SOC die Angriffe, die für das Unternehmen realistisch sind, tatsächlich sieht und ob daraus innerhalb nützlicher Frist eine Reaktion folgt.
So funktioniert ein SOC
Die Arbeit folgt einem wiederkehrenden Zyklus, der in den meisten SOCs in Stufen (Tiers) organisiert ist:
- Sammeln: Logquellen, Telemetrie und Threat-Intelligence-Feeds laufen zentral zusammen (Logging und Monitoring).
- Erkennen: Erkennungsregeln und Analytik erzeugen Alarme; das Detection Engineering pflegt und verbessert diese Regeln.
- Triagieren: Tier-1-Analysten prüfen, ob ein Alarm ein echter Vorfall ist, und eskalieren an Tier 2/3.
- Reagieren: Eindämmung, Bereinigung und Wiederherstellung nach dem Incident-Response-Prozess, oft mit Playbooks und teilautomatisiert (SOAR).
- Lernen: Jeder Vorfall und jeder Fehlalarm fließt zurück in Regeln, Playbooks und Schulung.
Bedeutung für Unternehmen
Die Zeit, die Verteidigern bleibt, ist knapp: Laut CrowdStrike Global Threat Report 2026 liegt die durchschnittliche Breakout Time bei 29 Minuten, der schnellste beobachtete Fall bei 27 Sekunden. Ein SOC, das Alarme erst am nächsten Werktag sichtet, kommt systematisch zu spät. Gleichzeitig zeigt Mandiant M-Trends 2026, dass nur 52 Prozent der Vorfälle intern erkannt werden; die andere Hälfte meldet ein Dritter, oft der Angreifer selbst mit einer Lösegeldforderung.
Was wir in Einsätzen sehen: Die Technik ist häufig vorhanden, aber die Kette bricht an den Übergängen. Alarme landen in Postfächern, die niemand liest, das SOC des Dienstleisters darf keine Gegenmaßnahmen einleiten, oder die Eskalation zur IT-Leitung scheitert am Wochenende. Das CISA-Advisory AA23-059A beschreibt genau diesen Fall bei einer als reif geltenden Organisation: EDR-Alarme wurden erzeugt, aber niemand reagierte. Ein Red Teaming prüft daher nicht die Alarmerzeugung allein, sondern die gesamte Kette bis zur wirksamen Reaktion.
Praxis: Was ein SOC leisten muss und wie wir es testen
- Kennzahlen mit Zeitbezug: Messen Sie MTTD und MTTR pro Alarmklasse, nicht nur die Anzahl bearbeiteter Tickets.
- Befugnisse klären: Das SOC braucht das Mandat, Hosts zu isolieren und Konten zu sperren, ohne auf eine Freigabe warten zu müssen. Legen Sie fest, wer außerhalb der Geschäftszeiten entscheidet.
- Sichtbarkeit prüfen: Welche Systeme liefern keine Telemetrie? Legacy-Server, OT-Netze und Cloud-Konten sind typische blinde Flecken.
- Realistisch üben: Ein Assumed-Breach-Einsatz zeigt, welche Schritte eines Angreifers das SOC sieht und wo es ihn verliert. Im anschließenden Purple-Teaming-Workshop schließen Red und Blue Team die Lücken gemeinsam.
- Umgehung einplanen: Wir arbeiten in Einsätzen bevorzugt mit legitimen Bordmitteln und gültigen Konten, weil solche Aktivität in vielen SOCs nicht als Alarm, sondern als Rauschen erscheint. Erkennungsregeln müssen daher Verhalten bewerten, nicht nur bekannte Schadsoftware.