§ 31 BSIG: Systeme zur Angriffserkennung (SzA) in der OT

Was verlangt § 31 BSIG von Betreibern kritischer Anlagen?

§ 31 BSIG regelt die besonderen Anforderungen an die Risikomanagementmaßnahmen von Betreibern kritischer Anlagen. Die Vorschrift hat zwei Absätze:

• Absatz 1: Für die informationstechnischen Systeme, Komponenten und Prozesse, die für die Funktionsfähigkeit der kritischen Anlage maßgeblich sind, können Maßnahmen erforderlich sein, die über das Schutzniveau anderer besonders wichtiger Einrichtungen nach § 30 Abs. 1 BSIG hinausgehen – soweit der Aufwand nicht außer Verhältnis zu den Folgen eines Ausfalls oder einer Beeinträchtigung steht.
• Absatz 2: Für dieselben Systeme müssen Betreiber kritischer Anlagen Systeme zur Angriffserkennung (SzA) einsetzen. Diese sollen geeignete Parameter und Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten, Bedrohungen fortlaufend identifizieren und vermeiden sowie für eingetretene Störungen geeignete Beseitigungsmaßnahmen vorsehen. Dabei soll der Stand der Technik eingehalten werden; auch hier gilt der Verhältnismäßigkeitsvorbehalt.

Betreiber kritischer Anlagen gelten nach § 28 Abs. 1 Nr. 1 BSIG stets als besonders wichtige Einrichtungen. Was eine kritische Anlage ist, bestimmt § 2 Nr. 22 BSIG mit Verweis auf das KRITIS-Dachgesetz.

Was hat sich gegenüber § 8a Abs. 1a BSIG geändert?

Viele Fachbeiträge und Angebote zitieren noch § 8a BSIG. Diese Fassung ist überholt: Mit dem NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) wurde das BSI-Gesetz neu gefasst; die neue Fassung gilt seit dem 6. Dezember 2025.

Inhaltlich ist die SzA-Pflicht weitgehend gleich geblieben: Schon § 8a Abs. 1a BSIG a. F. verlangte, dass SzA geeignete Parameter und Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten. Neu sind vor allem die Begriffe, die Einbettung in das NIS2-System der Einrichtungskategorien und der längere Nachweiszyklus.

Was ist ein System zur Angriffserkennung im Sinne des BSIG?

§ 2 Nr. 41 BSIG definiert Systeme zur Angriffserkennung als durch technische Werkzeuge und organisatorische Einbindung unterstützte Prozesse zur Erkennung von Angriffen auf informationstechnische Systeme. Die Erkennung erfolgt, indem die in einem System verarbeiteten Daten mit Informationen und technischen Mustern abgeglichen werden, die auf Angriffe hindeuten.

Entscheidend ist der Zusatz „organisatorische Einbindung“: Ein Sensor allein ist noch kein SzA. Erst Auswertung, Bewertung und Reaktion durch Menschen mit klaren Zuständigkeiten machen daraus ein System im Sinne des Gesetzes – also im Kern die Funktion eines SOC.

Was verlangt die Orientierungshilfe des BSI?

Das BSI hat die Anforderungen in der Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung (OH SzA, aktuell Version 1.1 vom 18. November 2024) konkretisiert. Sie gliedert die Anforderungen in drei Bereiche und unterscheidet MUSS-, SOLLTE- und KANN-Anforderungen:

1. Protokollierung – unter anderem eine Sicherheitsrichtlinie für die Protokollierung, die Konfiguration auf System- und Netzebene, Zeitsynchronisation und eine zentrale Protokollierungsinfrastruktur.
2. Detektion – kontinuierliche Überwachung und Auswertung der Protokolldaten, ergänzende Detektionssysteme sowie festgelegte Meldewege für sicherheitsrelevante Ereignisse.
3. Reaktion – technische und organisatorische Maßnahmen, um Störungen durch Angriffe zu verhindern oder auf sie zu reagieren.

Die Umsetzung wird in Umsetzungsgraden von 0 bis 5 bewertet. Umsetzungsgrad 3 bedeutet, dass alle MUSS-Anforderungen in allen drei Bereichen erfüllt sind, ein Teil der SOLLTE-Anforderungen geprüft wurde und ein kontinuierlicher Verbesserungsprozess geplant oder etabliert ist. Nach den BSI-Unterlagen sollte grundsätzlich mindestens Umsetzungsgrad 3 erreicht werden; Abweichungen nach unten sind zu begründen. Der Umsetzungsgrad wird im Rahmen der Nachweisprüfung an das BSI übermittelt. Inzwischen hat das BSI die Anforderungen der OH SzA in das Bewertungsschema RUN (Reife- und Umsetzungsgradbewertung im Rahmen der Nachweisprüfung) integriert.

Welche Pflichten haben besonders wichtige und wichtige Einrichtungen?

Unabhängig von der SzA-Pflicht müssen besonders wichtige und wichtige Einrichtungen nach § 30 BSIG geeignete, verhältnismäßige technische und organisatorische Maßnahmen ergreifen, die den Stand der Technik einhalten und europäische und internationale Normen berücksichtigen sollen. § 30 Abs. 2 BSIG nennt zehn Mindestmaßnahmen, darunter:

• Konzepte für Risikoanalyse und Sicherheit in der Informationstechnik,
• die Bewältigung von Sicherheitsvorfällen,
• Aufrechterhaltung des Betriebs mit Backup-Management, Wiederherstellung und Krisenmanagement,
• Sicherheit der Lieferkette, einschließlich der Beziehungen zu Dienstleistern,
• Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen.

Für die OT heißt das: Auch ohne ausdrückliche SzA-Pflicht muss ein Hersteller oder Versorger, der als wichtige Einrichtung gilt, Vorfälle im Produktionsnetz erkennen und bewältigen können. Für die Lieferkette ist insbesondere die Überwachung von Fernwartungszugängen der Anlagenlieferanten relevant.

Welche Meldefristen gelten nach § 32 BSIG?

24 Stunden

Besonders wichtige und wichtige Einrichtungen melden erhebliche Sicherheitsvorfälle an eine gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK):

1. Frühe Erstmeldung – unverzüglich, spätestens 24 Stunden nach Kenntniserlangung, mit der Angabe, ob ein rechtswidriger oder böswilliger Hintergrund oder grenzüberschreitende Auswirkungen vermutet werden.
2. Meldung – spätestens 72 Stunden nach Kenntniserlangung, mit einer ersten Bewertung von Schweregrad und Auswirkungen und gegebenenfalls Kompromittierungsindikatoren.
3. Zwischenmeldung – auf Ersuchen des BSI.
4. Abschlussmeldung – spätestens einen Monat nach der Meldung; dauert der Vorfall noch an, stattdessen eine Fortschrittsmeldung und die Abschlussmeldung nach Abschluss der Bearbeitung.

Betreiber kritischer Anlagen geben zusätzlich die betroffene Anlage, die kritische Dienstleistung und die Auswirkungen auf diese an. Die Frist beginnt mit der Kenntniserlangung. Ohne Monitoring im Produktionsnetz bleibt ein Angriff womöglich wochenlang unbemerkt – und es fehlen die Daten, um zu beurteilen, ob ein Vorfall erheblich ist.

Wie wird die Umsetzung nachgewiesen?

Betreiber kritischer Anlagen weisen die Umsetzung der Maßnahmen nach § 30 Abs. 1 in Verbindung mit § 31 Abs. 1 und 2 BSIG – also einschließlich der SzA – nach § 39 BSIG durch Sicherheitsaudits, Prüfungen oder Zertifizierungen nach. Den ersten Nachweiszeitpunkt legt das BSI fest, frühestens drei Jahre nach der Einstufung als Betreiber; danach ist der Nachweis alle drei Jahre zu erbringen. Unter § 8a Abs. 3 BSIG a. F. galt ein Zwei-Jahres-Zyklus – deshalb kursieren in der Literatur unterschiedliche Angaben. Für Betreiber, die bereits nach altem Recht als KRITIS-Betreiber galten, enthält § 39 Abs. 3 BSIG Übergangsregelungen. Ergebnisse und festgestellte Mängel sind dem BSI zu übermitteln.

Wie hängen EnWG und KRITIS-Dachgesetz damit zusammen?

Energiewirtschaft. Für Betreiber von Energieversorgungsnetzen und Energieanlagen waren die IT-Sicherheitsanforderungen bisher in § 11 Abs. 1a und 1b EnWG geregelt, die SzA-Pflicht in § 11 Abs. 1e EnWG a. F. Mit dem NIS2UmsuCG ist § 5c EnWG die Grundlage für einen neuen IT-Sicherheitskatalog der Bundesnetzagentur, der im Einvernehmen mit dem BSI festgelegt wird. Nach Angaben der Bundesnetzagentur gelten bis zur Veröffentlichung des neuen Katalogs die bisherigen IT-Sicherheitskataloge für die bisherigen Adressaten fort, und bestehende SzA sind weiterhin nach § 11 Abs. 1e EnWG a. F. zu betreiben. Als Orientierung verweist die Bundesnetzagentur auf die OH SzA des BSI. Prüfen Sie im Einzelfall, welches Regime für welche Anlage greift.

KRITIS-Dachgesetz. Das KRITIS-Dachgesetz setzt die CER-Richtlinie (EU) 2022/2557 um und wurde am 16. März 2026 verkündet (BGBl. 2026 I Nr. 66). Es regelt die physische Resilienz kritischer Anlagen – etwa Risikoanalysen, Resilienzmaßnahmen und Meldungen an das BBK. Die Cybersicherheit bleibt im BSIG geregelt. Für Betreiber kritischer Anlagen heißt das: Physischer Schutz nach KRITIS-Dachgesetz und Angriffserkennung nach § 31 BSIG sind getrennte Pflichten, die in der Praxis eng zusammenhängen – etwa wenn ein OT-SOC auch Zutritts- oder Gebäudeleittechnik überwacht.

Wie setzt ein SOC für OT die SzA-Anforderungen um?

Die folgende Zuordnung zeigt, wie sich die Bereiche der OH SzA in konkrete Fähigkeiten eines OT-SOC übersetzen lassen. Sie ist unsere fachliche Einordnung, keine amtliche Auslegung.

Welche Rolle spielt die IEC 62443 als Stand der Technik?

§ 31 Abs. 2 BSIG verlangt, dass SzA den Stand der Technik einhalten sollen, und § 30 BSIG verweist auf einschlägige europäische und internationale Normen. Für industrielle Automatisierungs- und Steuerungssysteme ist die IEC 62443 die maßgebliche Normenreihe. Die IEC 62443-3-3 enthält mit SR 6.1 (Zugänglichkeit von Audit-Logs) und SR 6.2 (kontinuierliche Überwachung) Systemanforderungen, die sich direkt auf die SzA-Bereiche Protokollierung und Detektion abbilden lassen. Wer seine OT-Angriffserkennung an der IEC 62443 ausrichtet, hat eine gut begründbare Referenz für den Stand der Technik.

Was sollten Betreiber jetzt tun?

1. Einstufung prüfen: Betreiber kritischer Anlage, besonders wichtige oder wichtige Einrichtung – und welche Anlagen betroffen sind.
2. Geltungsbereich der SzA klären: Alle für die Funktionsfähigkeit der Anlage maßgeblichen Systeme einbeziehen, ausdrücklich auch Leittechnik und Produktionsnetz.
3. Lücken bewerten: Den eigenen Stand gegen die OH SzA bzw. RUN einschätzen und den angestrebten Umsetzungsgrad festlegen.
4. Passives OT-Monitoring ausbauen: Zuerst an den kritischen Conduits und in der industriellen DMZ.
5. Melde-Runbook testen: Vom OT-Alarm bis zur frühen Erstmeldung innerhalb von 24 Stunden – in einer Übung mit der Leitwarte.
6. Dienstleister sorgfältig auswählen: Wer das SzA auslagert, sollte vertraglich sicherstellen, dass der Anbieter die OT abdeckt und die Melde- und Nachweispflichten unterstützt.

Mehr zu Aufgaben und Betriebsmodellen lesen Sie in Was ist ein SOC für OT?