Die Frage kommt in fast jedem NIS2-Gespräch: Müssen wir jetzt eine Angriffserkennung betreiben? Die ehrliche Antwort hat zwei Teile. Wörtlich vorgeschrieben ist sie nur für eine Gruppe. Praktisch unverzichtbar ist sie für alle – und der Grund dafür steht nicht im Paragrafen über Angriffserkennung, sondern in dem über Meldefristen.
Diese Seite nimmt beide Teile auseinander. Sie sagt, was § 31 wörtlich verlangt, was § 30 und § 32 zusammen bewirken, und was eine überwachte Erkennung davon abdeckt. Und sie sagt, was sie nicht abdeckt – damit niemand einen Dienst für eine Konformität hält.
Drei Paragrafen, ein Zusammenhang
Keiner der drei steht für sich. Erst zusammen ergeben sie die Pflicht, die im Betrieb spürbar ist.
- § 31: Die wörtliche Pflicht – für kritische AnlagenBetreiber kritischer Anlagen müssen Systeme zur Angriffserkennung einsetzen, die Parameter des laufenden Betriebs kontinuierlich und automatisch auswerten, Bedrohungen fortwährend identifizieren und dem Stand der Technik entsprechen. Das ist eine ausdrückliche Vorgabe mit technischen Mindestanforderungen.
- § 30: Die abgeleitete Pflicht – für alle EinrichtungenAbsatz 2 Nr. 2 verlangt die Bewältigung von Sicherheitsvorfällen, Nr. 6 die Bewertung der Wirksamkeit. Beides setzt voraus, dass Vorfälle bemerkt werden. Ob dafür eine Erkennung angemessen ist, bemisst sich nach Absatz 1: Risikoexposition, Größe, Kosten, Schwere möglicher Vorfälle.
- § 32: Die Uhr, die alles entscheidetErstmeldung spätestens 24 Stunden nach Kenntniserlangung. Die Frist läuft nicht ab dem Angriff, sondern ab dem Moment, in dem die Einrichtung davon weiß. Wer einen Angriff drei Wochen nicht bemerkt, hat keine Frist verletzt – aber er muss der Aufsicht erklären, warum er drei Wochen nichts bemerkt hat.
Warum „Kenntnis“ das eigentliche Problem ist
Die Formulierung „nach Kenntniserlangung“ wird gelegentlich als Entlastung gelesen: Was man nicht weiß, muss man nicht melden. Das ist richtig und zugleich der gefährlichste Satz im Gesetz. Denn späte Kenntnis ist kein Zufall. Ein Angreifer, der sich Wochen im Netz bewegt, hinterlässt Spuren – fehlgeschlagene Anmeldungen, neue Konten, ungewöhnliche Verbindungen zu ungewöhnlichen Zeiten. Dass niemand sie sieht, ist eine Eigenschaft der Einrichtung, nicht des Angriffs.
Genau dort setzt die Aufsicht an. Die Frage nach einem Vorfall lautet nicht nur „Haben Sie fristgerecht gemeldet?“, sondern „Waren Ihre Maßnahmen nach § 30 angemessen?“. Eine Einrichtung mit Risikoexposition, die über Wochen nichts bemerkt, wird diese Frage schwer bejahen können. Die Angriffserkennung ist damit nicht Pflicht, weil ein Paragraf sie nennt, sondern weil ohne sie zwei andere Paragrafen nicht einzuhalten sind.
Für die Praxis heißt das: Die Erkennung muss zu der Zeit arbeiten, zu der Angriffe stattfinden. Das ist nachts und am Wochenende. Eine Erkennung, deren Meldungen am Montagmorgen gelesen werden, erzeugt Kenntnis am Montagmorgen – und die 24 Stunden laufen ab dann. Was in den 60 Stunden davor geschehen ist, steht im Protokoll, aber nicht in einer Meldung.
Was eine überwachte Erkennung abdeckt – und was nicht
Dieselbe Trennung wie auf der NIS2-Übersicht, hier auf die Erkennung zugespitzt. Links das Gesetz, in der Mitte der Beitrag eines Dienstes wie G DATA MXDR, rechts das, was bei der Einrichtung bleibt.
| Anforderung | Beitrag der überwachten Erkennung | Bleibt bei der Einrichtung |
|---|---|---|
| Kontinuierliche, automatische Auswertung (§ 31) | Agent auf jedem Endpunkt, Korrelation im Analyse-Backend, rund um die Uhr | Festlegung, welche Systeme überwacht werden – und welche nicht |
| Fortwährende Identifikation von Bedrohungen (§ 31) | Bewertung durch Analysten: Erkennung in unter einer Minute, Analyse in unter drei, Reaktion in unter 30 Minuten laut Hersteller | Einstufung, ob ein erkannter Vorfall erheblich im Sinne des § 32 ist |
| Bewältigung von Vorfällen (§ 30 Abs. 2 Nr. 2) | Eindämmung im vereinbarten Rahmen: Isolieren, Prozesse beenden, Angreifer aussperren | Entscheidung über Eingriffe, die den Betrieb stören; Wiederanlauf |
| Kenntnis und Meldung (§ 32) | Zeitachse: welcher Endpunkt, welcher Prozess, welche Anmeldung, wann gestoppt | Registrierung, Meldezugang, Absenden der Meldung |
| Wirksamkeitsbewertung (§ 30 Abs. 2 Nr. 6) | Vorfallberichte und Lagebild in der Konsole | Die Bewertung und ihre Konsequenzen |
| Stand der Technik (§ 31) | Zertifizierungen und unabhängige Tests des Herstellers als Beleg | Prüfung, ob der gewählte Dienst für die eigene Anlage angemessen ist |
Welche Stufe zu NIS2 passt
G DATA bietet die Überwachung in Stufen an, und für NIS2-Häuser ist ein Unterschied zwischen ihnen entscheidend: In der Stufe G5 bearbeiten die Analysten die Vorfälle, die der Hersteller als kritisch einstuft; in G7 alle. Ob ein Vorfall erheblich im Sinne des § 32 ist, entscheidet aber die Einrichtung – nach den Maßstäben des Gesetzes, nicht nach der Einstufung eines Herstellers. Ein Vorfall, der technisch unkritisch wirkt, kann meldepflichtig sein, wenn er einen Dienst beeinträchtigt.
Deshalb empfehlen wir NIS2-Einrichtungen die Stufe, in der jeder Vorfall bearbeitet wird und die Rufkette angerufen wird. Der Anruf verkürzt den Weg zur Kenntnis auf Minuten; die Bearbeitung aller Vorfälle sorgt dafür, dass nichts in der Konsole liegt, was später als nicht gemeldet gilt. Das ist kein Verkaufsargument für die teurere Stufe, sondern die Konsequenz aus der Frist.
Was keine Stufe leistet: die Entscheidung. Wer stuft ein, wer meldet, wer gibt Eingriffe frei – das legen wir mit Ihnen bei der Einrichtung fest, aber entscheiden müssen Sie. Die Angriffserkennung liefert Kenntnis. Was daraus folgt, bleibt Sache der Einrichtung und ihrer Leitung.
Weiter im Thema
Häufige Fragen
- Wir sind wichtige Einrichtung, keine kritische Anlage – gilt § 31 für uns?
- Nein, § 31 richtet sich wörtlich an Betreiber kritischer Anlagen. Für Sie gilt § 30, und dort steht Angriffserkennung nicht als eigener Punkt. Sie folgt aus der Vorfallbewältigung und den Meldefristen: Ohne Erkennung sind beide nicht zu erfüllen, und die Angemessenheit Ihrer Maßnahmen würde im Vorfall daran gemessen.
- Reicht ein Virenschutz mit Alarmfunktion als Angriffserkennung?
- Für die meisten Angriffe, die heute Schaden anrichten, nicht. Ein Virenschutz erkennt bekannte Schadsoftware. Er sieht nicht, wenn ein gültiges Konto missbraucht oder ein vorhandenes Werkzeug zweckentfremdet wird. § 31 verlangt die Auswertung von Betriebsparametern und die Identifikation von Bedrohungen – das ist Verhaltensanalyse, nicht Signaturabgleich. Und selbst eine gute Erkennung nützt nichts, wenn nachts niemand ihre Meldungen liest.
- Können wir die Erkennung mit eigener Bereitschaft betreiben?
- Ja, wenn Sie Fachleute haben, die nachts und am Wochenende Meldungen bewerten können, und die Technik, die Verhalten statt Signaturen auswertet. In mittelständischen Häusern scheitert das selten an der Technik, sondern an der Bereitschaft: Drei Personen reichen nicht für einen Schichtbetrieb über 365 Tage. Deshalb kaufen die meisten die Bereitschaft ein und behalten die Entscheidung.
- Meldet der Dienstleister für uns an das BSI?
- Nein. Die Meldepflicht trifft die Einrichtung, Registrierung und Zugang laufen auf Ihren Namen. Der Dienst liefert die technischen Angaben in der Frist – welcher Endpunkt, welcher Prozess, welche Zeitachse. Einstufen und absenden müssen Sie. Das ist keine Lücke im Dienst, sondern der Wille des Gesetzes.
- Wie schnell muss die Erkennung sein, damit wir die 24 Stunden halten?
- Das Gesetz nennt keine Erkennungszeit, nur die Meldefrist ab Kenntnis. Entscheidend ist der Weg vom Ereignis zur Kenntnis bei einer entscheidungsbefugten Person. Eine Erkennung, die nachts erkennt, aber morgens gelesen wird, erzeugt Kenntnis am Morgen. Eine, die nachts anruft, erzeugt sie nachts. Darin liegt der praktische Unterschied zwischen den Stufen.
Quellen und Nachweise
- § 30 BSIG – Risikomanagementmaßnahmen · Bundesministerium der Justiz (gesetze-im-internet.de)amtlich
- § 31 BSIG – Besondere Anforderungen an die Risikomanagementmaßnahmen von Betreibern kritischer Anlagen · Bundesministerium der Justiz (gesetze-im-internet.de)amtlich
- § 32 BSIG – Meldepflichten · Bundesministerium der Justiz (gesetze-im-internet.de)amtlich
- G DATA MXDR – Managed Extended Detection and Response · G DATA CyberDefense AG