Systeme zur Angriffserkennung (SzA)

Die Pflicht zum Einsatz von Systemen zur Angriffserkennung wurde mit dem IT-Sicherheitsgesetz 2.0 eingeführt und galt für KRITIS-Betreiber ab dem 1. Mai 2023 (§ 8a Absatz 1a BSIG a. F.). Mit dem NIS2-Umsetzungsgesetz, in Kraft seit dem 6. Dezember 2025, steht sie nun in § 31 Absatz 2 BSIG: Betreiber kritischer Anlagen müssen Systeme einsetzen, die „geeignete Parameter und Merkmale aus dem laufenden Betrieb kontinuierlich und automatisch erfassen und auswerten“ – unter Einhaltung des Stands der Technik. § 2 BSIG definiert SzA als durch technische Werkzeuge und organisatorische Einbindung unterstützte Prozesse, also ausdrücklich nicht als bloßes Produkt, sondern als Zusammenspiel von Technik und Organisation. Die Umsetzung ist nach § 39 BSIG durch Sicherheitsaudits, Prüfungen oder Zertifizierungen nachzuweisen – im neuen Recht alle drei Jahre (zuvor alle zwei Jahre nach § 8a Absatz 3 BSIG a. F.).

Maßstab für Umsetzung und Prüfung ist die „Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung“ des BSI (Version 1.1 vom 18.11.2024, gegenüber der Erstfassung von September 2022 redaktionell angepasst; sie nimmt noch auf die alte Rechtslage Bezug). Die Orientierungshilfe gliedert die Anforderungen in die drei Bereiche Protokollierung, Detektion und Reaktion und formuliert sie in Anlehnung an den IT-Grundschutz als MUSS-, SOLLTE- und KANN-Anforderungen; als weiterführende Orientierung verweist sie unter anderem auf die Bausteine OPS.1.1.5, DER.1 und DER.2.1. Bewertet wird über ein Umsetzungsgradmodell von 0 bis 5: Stufe 3 bedeutet, dass alle MUSS-Anforderungen in allen Bereichen erfüllt sind; Stufe 4 verlangt zusätzlich alle SOLLTE-Anforderungen (Ausnahmen nur stichhaltig begründet), Stufe 5 schließt die KANN-Anforderungen ein. Für den Nachweis soll grundsätzlich mindestens Umsetzungsgrad 3 erreicht werden; Abweichungen nach unten sind nur mit Begründung zulässig.

Wirksame Detektion beginnt mit der Frage, welche Protokolldaten überhaupt erhoben werden. Die Orientierungshilfe verlangt, alle für die kritische Dienstleistung maßgeblichen Systeme zu identifizieren, die notwendigen Protokoll- und Protokollierungsdaten zentral zu speichern und sie gefiltert, normalisiert, aggregiert und korreliert für die Auswertung bereitzustellen. Die Erschließung der Quellen soll priorisiert von außen nach innen erfolgen – von den Netzgrenzen zu den inneren Netzbereichen, auf Systemebene ausgehend von zentralen kritischen Systemen wie Prozessleit- und Automatisierungstechnik. Der Geltungsbereich umfasst ausdrücklich IT und OT ebenso wie Rechenzentren und Embedded Systems. Zusätzlich sind Datenschutz und gesetzliche Löschfristen zu beachten und ein Change-Prozess einzurichten, der die Protokollierung bei Änderungen im Anwendungsbereich nachzieht.

Detektionsinhalte werden zunehmend wie Software entwickelt: versioniert, getestet und wiederverwendbar. Als offenes, YAML-basiertes Signaturformat für Log-Ereignisse hat sich Sigma etabliert; Regeln lassen sich über sigma-cli und pySigma in die Abfragesprachen gängiger SIEM-Plattformen konvertieren und über das gemeinschaftlich gepflegte SigmaHQ-Repository austauschen. Für die Planung der Abdeckung empfiehlt die BSI-Orientierungshilfe eine standardisierte Methode wie MITRE ATT&CK beziehungsweise ATT&CK for ICS. Die Enterprise-Matrix beschreibt in Version 19 (April 2026) 15 Taktiken, 222 Techniken und 475 Sub-Techniken; ein Mapping der eigenen Regeln auf ATT&CK macht nachvollziehbar, welche Angriffstechniken erkannt werden – und wo Lücken bestehen.

In der Praxis entsteht Angriffserkennung aus dem Zusammenspiel mehrerer Bausteine. Ein SIEM sammelt und korreliert Protokolldaten aus heterogenen Quellen zentral und bildet die geforderte kontinuierliche, automatisierte Auswertung mit Alarmierung bei Schwellenwertüberschreitungen ab. EDR liefert detaillierte Telemetrie und Reaktionsmöglichkeiten auf Endpunkten und Servern; NDR erkennt Auffälligkeiten im Netzverkehr und deckt damit auch Bereiche ab, in denen sich keine Agents installieren lassen – etwa OT-Umgebungen oder Embedded Systems. Die Orientierungshilfe fordert darüber hinaus konkret zentral verwaltete Schadcodedetektion sowie netzbasierte Intrusion-Detection-Systeme (NIDS) an den Übergängen zwischen internen und externen Netzen. Kein einzelnes Werkzeug erfüllt die Anforderungen allein; entscheidend ist die dokumentierte Abdeckung des gesamten Geltungsbereichs.

Detektions-Use-Cases sind kein einmaliges Projekt, sondern ein Portfolio mit Lebenszyklus: Bedrohungsanalyse und Priorisierung, Regelentwicklung, Test und Kalibrierung im Normalbetrieb (Baselining), produktiver Betrieb mit Tuning sowie regelmäßige Überprüfung und Aussonderung. Die Orientierungshilfe verlangt ausdrücklich, Detektionsmechanismen auf Basis der Qualifizierung sicherheitsrelevanter Ereignisse nachzujustieren und Signaturen stets aktuell zu halten. Typische Lücken in Prüfungen und Projekten sind eine unvollständige Log-Quellen-Abdeckung insbesondere in OT-Netzen, fehlende oder nicht geübte Reaktionsprozesse, keine belastbare Regelung für die Auswertung außerhalb der Geschäftszeiten, Alarmmüdigkeit durch nicht kalibrierte Regeln sowie fehlende Dokumentation von Planung und begründeten Ausnahmen – Letzteres fällt spätestens bei der Bewertung des Umsetzungsgrads auf.