Managed SOC für einen Netzbetreiber: durchgehender Sicherheitsbetrieb ohne eigenes Security-Team
Ein regionaler Energieversorger mit rund 350 Mitarbeitenden betreibt elf kritische IT-Systeme und zwei Leitstellen. Das IT-Team umfasst sechs Personen. Einen Betrieb außerhalb der Geschäftszeiten gibt es nicht. Der Sicherheitsbetrieb wird als Managed Service auf Google SecOps ausgelagert. Dazu kommt eine dokumentierte Meldekette mit benannten Rollen und Vertretungen. Der Projektplan sieht vier Monate bis zur geübten Meldefähigkeit vor, ohne zusätzliche Stelle.
- Stadtwerke, Netzbetreiber und regionale Versorger mit eigenem IT-Betrieb, aber ohne Schichtmodell
- Häuser, in denen Informationssicherheit eine Aufgabe unter vielen ist
- Organisationen, die den Aufbau eines eigenen Security Operations Center geprüft und aus Personalgründen verworfen haben
Warum scheitert Sicherheitsbetrieb bei Versorgern selten an der Technik?
Die Meldepflichten eines Netzbetreibers ergeben sich aus dem BSI-Gesetz in der Fassung des NIS2-Umsetzungsgesetzes, das seit 6. Dezember 2025 gilt. Nach § 32 BSIG ist ein erheblicher Sicherheitsvorfall spätestens 24 Stunden nach Kenntnis erstmals zu melden, spätestens nach 72 Stunden folgt eine Meldung mit erster Bewertung. Für Betreiber kritischer Anlagen kommen Pflichten aus dem KRITIS-Dachgesetz hinzu. Beide Rahmen sind im Haus bekannt.
Die Erkennung sicherheitsrelevanter Ereignisse endet im Ausgangszustand trotzdem mit dem Feierabend. Meldefristen tun das nicht. Sie laufen ab Kenntnis, unabhängig von Wochentag und Uhrzeit.
Ein sechsköpfiges IT-Team kann keinen durchgehenden Betrieb stellen.
Die Rechnung für ein eigenes Security Operations Center scheitert an der Personaldecke, nicht an der Einsicht.
Der zweite Engpass liegt im Nachweis.
Erkennung allein genügt nicht. Belegbar sein muss, wer wann was entschieden hat. Diese Dokumentation entsteht im Tagesgeschäft nicht nebenbei.
Projektprofil
Wie ist der Sicherheitsbetrieb aufgebaut?
Der Betrieb wird ausgelagert, nicht aufgebaut. Die Erkennung läuft auf Google SecOps und ist an die kritischen IT-Systeme angebunden. Wiz liefert die Sicht auf Fehlkonfigurationen und tatsächlich ausnutzbare Angriffspfade statt auf tausende Einzelbefunde. Mandiant Threat Intelligence ordnet ein, welche Angriffsmuster aktuell gegen Versorger gerichtet sind.
Den regulatorischen Rahmen setzt der Betreiber. Der Sicherheitsbetrieb wird so eingerichtet, dass die benötigten Nachweise im laufenden Betrieb entstehen und nicht nachträglich zusammengesucht werden müssen.
Rahmen abstecken
Erfassung der einzubindenden Systeme, der geltenden Fristen, der zu führenden Nachweise und der zuständigen Aufsicht. Zwei Wochen.
Anbinden und scharfstellen
Anbindung der elf kritischen Systeme an Google SecOps, Wiz agentenlos über die Cloud-Umgebung. Sechs Wochen.
Meldekette definieren
Festlegung, wer eine Meldung außerhalb der Geschäftszeiten erhält, wer über sie entscheidet, wer sie abgibt und wie die Vertretung geregelt ist. Dazu Vorlagen für die im Haus geltenden Fristen.
Ernstfall üben
Eine Tabletop-Übung aus Angreiferperspektive vor dem produktiven Betrieb.
Betrieb übernehmen
Durchgehendes Monitoring, monatlicher Bericht für Geschäftsführung und Aufsicht, vierteljährliche Nachschärfung der Erkennungsregeln.
Welche Technologie steckt dahinter?
Google SecOps
Erkennung und Auswertung über alle angebundenen Systeme
Wiz
Sicht auf Fehlkonfigurationen und ausnutzbare Angriffspfade
Mandiant Threat Intelligence
Aktuelle Angriffsmuster gegen Versorger
Managed Security Operations durch GMinds
Der durchgehende Betrieb, der nicht selbst gestellt werden muss
Betrieb und Datenhaltung erfolgen in deutschen beziehungsweise europäischen Regionen. Zugriff haben ausschließlich namentlich benannte Personen auf Dienstleisterseite; jeder Zugriff wird protokolliert, die Protokolle liegen beim Betreiber. Sicherheitsdaten werden nicht für das Training von Modellen verwendet. Bei Beendigung der Zusammenarbeit gehen Erkennungsregeln und Historie an den Betreiber über.
Woran lässt sich der Fortschritt nach vier Monaten messen?
Ausgangslage
- Keine zentrale Erkennung über eine heterogene IT
- IT-Team von sechs Personen, kein Betrieb außerhalb der Geschäftszeiten
- Meldefristen laufen ab Kenntnis, die Erkennung endet mit dem Feierabend
- Nachweise, wer wann was entschieden hat, entstehen nicht im Tagesgeschäft
Messgrößen nach vier Monaten
- Hinter jeder Meldefrist steht ein Prozess mit benannten Rollen und festen Uhrzeiten.
- Die Zahl sicherheitsrelevanter Ereignisse pro Monat ist bekannt, ebenso der Anteil, der eine menschliche Entscheidung erfordert hat. Im Ausgangszustand ist beides unbekannt, weil niemand hinsieht.
- Die Berichterstattung an Geschäftsführung und Aufsichtsrat umfasst eine Seite statt eines Ordners.
Klär in 30 Minuten, wie euer Sicherheitsbetrieb aussehen kann
- Einordnung der Ausgangslage
- Grobe Abschätzung von Umfang und Dauer
- Nächste Schritte
