Wie ein 24/7-SOC in der Praxis funktioniert
Ein 24/7-SOC arbeitet in überlappenden Analystenschichten mit klaren Tiers, Playbooks und einer Eskalationsmatrix bis zur Geschäftsleitung. Alarme laufen aus EDR, Identity, Cloud und Netzwerk in ein zentrales SIEM oder XDR, werden auf L1 triagiert, auf L2/L3 ermittelt und ausserhalb des Kunden-Tenants nie «liegen gelassen». Zielwerte für kritische Fälle: MTTR bis 60 Minuten, MTTC zwischen 1 und 4 Stunden.
Abgrenzung zu Nachbarthemen
Diese Seite beschreibt den laufenden 24/7-Betrieb. Der Einstieg dazu (Anbindung, Regelkalibrierung, Go-Live) steht auf SOC-Onboarding Schweiz. Vertragliche Aufteilung zwischen intern und Provider auf Co-Managed SOC. Zielwerte im Detail auf MTTD und MTTR im SOC. Die Servicedefinition auf Was ist ein SOC. Das gesamte Servicebild mit Betrieb, Nachweisen und Governance liegt im Pillar SOC as a Service Schweiz.
Schichtmodell und Übergaben
Ein produktives 24/7-SOC läuft nicht in drei starren Acht-Stunden-Blöcken, sondern in überlappenden Schichten mit dokumentierten Übergaben. Jede Schicht startet mit einem Briefing der offenen Fälle und endet mit einem strukturierten Handover, damit kein Case zwischen zwei Analysten verloren geht.
| Element | Was passiert |
|---|---|
| Schichtüberlappung | 30 bis 60 Minuten Überlappung mit strukturiertem Case-Handover pro offenem Fall. |
| Follow-the-Sun | Anbieter mit mehreren Standorten reichen Fälle nach Zeitzone weiter, ohne Kontextverlust. |
| Off-Hours-Rufbereitschaft | Zusätzliche L2- und L3-Rufbereitschaft für Critical-Fälle nachts und am Wochenende. |
| Case-System | Jeder Alarm hat einen Case mit Owner, Status, Timeline und Response-Aktionen; keine Ad-hoc-Mails. |
L1-L2-L3-Tiers und ihre Aufgaben
- L1 Triage: nimmt Alarme entgegen, prüft Kontext und False-Positive-Signale, führt Standard-Playbooks aus und eskaliert nach klaren Kriterien.
- L2 Investigation: ermittelt Angriffsverlauf über Endpoint, Identity, Cloud und Netzwerk hinweg, entscheidet über Response-Aktionen im Kunden-Tenant.
- L3 Advanced Response und Threat Hunting: bearbeitet komplexe Fälle, entwickelt Detection-Content, führt Purple-Team-Übungen mit internen Teams.
- Compliance und Governance: pflegt Nachweise für revDSG, ISG, FINMA und Cyberversicherung, dokumentiert Response-Zeiten und Entscheidungen.
Eskalationsmatrix bis zur Geschäftsleitung
| Kritikalität | L1-Reaktion | Eskalation an | Kundenseitige Info |
|---|---|---|---|
| Low | Playbook-basierte Response, Case-Close | Keine (Reporting im Wochenbericht) | Portal / Wochenbericht |
| Medium | Ermittlung durch L2, Response mit Freigabe | L2 und IT-Leitung Kunde | Case-Mail plus Portal |
| High | Sofort-Eindämmung nach Playbook | L3 plus Security-Verantwortlicher Kunde | Anruf plus Chat plus Portal |
| Critical | Isolierung und Session-Sperre unmittelbar | L3, Kunden-Security, CIO/CISO, GL | Anruf innerhalb Minuten, danach schriftlich |
Zielwerte für Reaktion, keine vertraglichen SLAs
Für Critical-Fälle liegt der Betriebszielwert für MTTR bei bis zu 60 Minuten, MTTC zwischen 1 und 4 Stunden. Das sind Betriebszielwerte, keine vertraglichen SLAs. Details und Berechnungslogik auf MTTD und MTTR im SOC.
Reaktionszeiten hängen von Alarmqualität, Response-Freigaben und Kunden-Tenant-Zugriff ab. Fragen Sie daher, worauf sich eine Minutenangabe bezieht: auf die Bestätigung eines Alerts, den Beginn der Analyse oder die Eindämmung. Und ob sie vertraglich zugesichert oder nur typisch erreicht wird.
Was ein Kunde im Ernstfall sieht
- Anruf beim benannten Kundenkontakt innerhalb Minuten, dokumentiert im Case.
- Sofort-Eindämmung gemäss vorab freigegebenen Response-Aktionen (Host isolieren, User sperren).
- Timeline mit jedem Schritt: Wann wurde was durch wen ausgeführt, mit welcher Wirkung.
- Post-Incident-Review innerhalb weniger Arbeitstage, inkl. Rückfluss in Detection-Regeln.
Typische Fehlbilder von 24/7
- 24/7 gleich Alarm-Weiterleitung. Ein E-Mail-Bot ohne Analyst ist kein SOC.
- Externe Nachtschicht ohne Kontext. Wenn L1 den Kunden nicht kennt, verzögert es Response statt zu beschleunigen.
- Keine dokumentierte Eskalationsmatrix beim Kunden. Der Provider ruft an, aber niemand ist erreichbar oder befugt.
Häufige Fragen
Was heisst 24/7 konkret, wenn niemand anruft?
Im Ruhebetrieb triagiert das SOC laufend Alarme, führt Standard-Playbooks aus und pflegt Detection-Content. Kundenseitig sichtbar wird das erst im Wochenbericht und im Portal. Der Anruf ist die Ausnahme, nicht der Normalfall.
Ist ein 24/7-SOC ohne interne Rufbereitschaft möglich?
Ja, sofern die Response-Freigaben so weit vorgezogen sind, dass der Provider ohne Anruf handeln darf. Für regulierte Umgebungen ist eine kundenseitige Rufbereitschaft trotzdem sinnvoll, damit GL-Entscheidungen nicht auf den nächsten Arbeitstag warten.
Wie unterscheidet sich das von einer NOC-Bereitschaft?
Ein NOC beobachtet Verfügbarkeit und Performance, ein SOC beobachtet Sicherheitssignale. Ein NOC-Alarm reagiert auf Ausfall, ein SOC-Alarm auf Angriffsverhalten. Beide Modelle nutzen Schichtbetrieb, die Playbooks und Kompetenzen sind aber grundverschieden.
Läuft der Betrieb auch in Ferienzeiten und Feiertagen gleich?
Ja. Ein 24/7-SOC unterscheidet nicht zwischen Arbeitstag und Feiertag. Interne Kundenteams sind an Feiertagen oft dünner besetzt; genau dann trägt die vorab freigegebene Response-Vollmacht des Providers.
Wie messe ich als Kunde, ob das 24/7 tatsächlich funktioniert?
Tabletop-Übungen zu unbequemen Zeiten (Freitag 22 Uhr, Sonntagmorgen) und die dokumentierten MTTR- und MTTC-Kennzahlen im Quartals-Review. Details auf [MTTD und MTTR im SOC](/de/soc/soc-mttd-mttr).
Verwandte Begriffe
- SOC Ein Security Operations Center (SOC) ist das Team, das die IT einer Organisation laufend auf Angriffe überwacht und bei Vorfällen eingreift.
- SOCaaS SOC as a Service (SOCaaS) ist ein SOC, das ein externer Anbieter betreibt und als laufende Dienstleistung liefert.
- Runbook Ein Runbook ist eine detaillierte operative Prozedur, welche die technischen Schritte für eine spezifische Aufgabe beschreibt.
- Playbook Ein Playbook ist eine vordefinierte Prozedur, die beschreibt, wie ein SOC auf eine bestimmte Art von Sicherheitsvorfall reagiert.
- T1 / T2 / T3 T1, T2 und T3 sind die klassischen Stufen für Analysten in einem Security Operations Center.