Compliance

NIS2 Firewall-Nachweise: Wie Artikel 21 auf Dokumentation abbildet

Fw
Nicholas Falshaw
||10 min Lesezeit

NIS2 ist im Oktober 2024 in den EU-Mitgliedstaaten in vollem Umfang in Kraft getreten. Die erste Auditwelle erreicht jetzt wesentliche und wichtige Einrichtungen in 18-Monats-Zyklen. Artikel 21 listet zehn Risikomanagement-Maßnahmen. Sechs davon verlangen Firewall-Dokumentation als Nachweis. Dieser Leitfaden bildet jede einschlägige Maßnahme auf das konkrete Artefakt ab, das ein Auditor anfordern wird — ergänzt um das Lückenmuster, das ich über mehr als 280 Enterprise-Firewall-Migrationen wiederkehrend beobachtet habe.

Der häufigste Audit-Fehlermodus ist nicht das Fehlen von Firewalls. Es ist das Fehlen von Firewall-Nachweisen. Der Betreiber führt einen kompetenten Firewall-Bestand, kann aber die Dokumentation nicht in der Form vorlegen, die der Auditor sehen will. Die meisten Audits scheitern an der Dokumentation; nahezu keines am Fehlen technischer Maßnahmen.

Artikel 21 — Die zehn Risikomanagement-Maßnahmen

Artikel 21(2) NIS2 listet zehn Kategorien von Risikomanagement-Maßnahmen. Die sechs, die direkt Firewall-Nachweise berühren:

  • 21(2)(a) Risikoanalyse und Sicherheitsleitlinien für Informationssysteme — die Firewall-Policy muss aus einer dokumentierten Risikoanalyse abgeleitet sein.
  • 21(2)(b) Bewältigung von Sicherheitsvorfällen — Firewall-Logs sind primäres Beweismaterial bei der Vorfallsrekonstruktion.
  • 21(2)(d) Sicherheit der Lieferkette — Vendor-Firewall-Verwaltung, Drittparteien-Zugriffsrichtlinien.
  • 21(2)(e) Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen — Change-Management-Prozess.
  • 21(2)(g) Grundlegende Cyberhygiene und Cybersicherheits-Schulungen — Regelwerks-Hygiene, wiederkehrende Überprüfung.
  • 21(2)(i) Einsatz von Kryptografie und gegebenenfalls Verschlüsselung — Firewall-TLS-Inspection-Policy, Schlüsselverwaltung.

Die vier Dokumentationslücken, die Auditoren zuerst prüfen

Aus beobachteten Audit-Mustern entfallen vier Lücken auf den Großteil der Article-21-Findings. Sie sind vorhersehbar und behebbar.

  1. Genehmigungskette von Änderungen. Pro Änderungsantrag: wer hat angefordert, wer technisch geprüft, wer genehmigt, wann implementiert, wer validiert. E-Mail-Ketten erfüllen das nicht. Das System of Record muss das Workflow-Tool sein.
  2. Zugriffsrichtlinien-Mapping. Eine dokumentierte Zuordnung, welche Benutzerrollen oder Service-Accounts welchen Firewall-Zugriff benötigen — mit Gültigkeitsdaten und Erneuerungsrhythmus. Viele Betreiber haben Rollendefinitionen und Firewall-Regeln, aber kein Mapping, das beides verbindet.
  3. Segmentierungs-Nachweise. Netzzonen-Diagramm, aktuelles Regelwerk mit den zonenübergreifend erlaubten Flüssen, letzter Test der Segmentierungswirksamkeit (oft ein Pen-Test-Bericht). NIS2 erwartet, dass das mindestens jährlich überprüft wird.
  4. Aufbewahrung von Vorfallsdaten. Dokumentierte Aufbewahrungsdauer, Integritätskontrollen (unveränderlicher Speicher oder signierte Datensätze), Suchfähigkeit. NIS2 nennt keine Dauer; sektorspezifische Frameworks empfehlen mindestens 12 Monate, 24 Monate für KRITIS.

Nachweis-Checkliste je Maßnahme

Eine praxisnahe Zuordnung der einschlägigen Artikel-21-Maßnahmen zum konkreten Beweismaterial:

MaßnahmeErforderliches Beweismaterial
21(2)(a)Risikoanalyse-Dokument; Firewall-Policy verknüpft mit identifizierten Risiken; Überprüfungsrhythmus
21(2)(b)IR-Runbook mit Firewall-Aktionen; Log-Aufbewahrungsrichtlinie; exemplarischer Vorfallsbericht mit Firewall-Log-Auszügen
21(2)(d)Lieferantenliste mit Sicherheitsprüfung; Drittparteien-Zugriffsregeln mit Ablaufdatum; Ergebnisse von Lieferanten-Sicherheitsfragebögen
21(2)(e)Change-Management-Verfahren; Auszug aus dem Change-Register; Notfall-Change-Verfahren; Rollback-Nachweise
21(2)(g)Regelwerks-Review-Bericht (mindestens quartalsweise); Schulungsnachweise für Firewall-Operatoren; Hygiene-Metriken
21(2)(i)TLS-Inspection-Policy mit Ausnahmen; Schlüsselverwaltungsverfahren; Verweis auf kryptografischen Standard

Wesentliche vs. wichtige Einrichtungen

NIS2 unterscheidet zwischen wesentlichen Einrichtungen (Anhang-I-Sektoren) und wichtigen Einrichtungen (Anhang-II-Sektoren). Beide unterliegen den Pflichten aus Artikel 21, das Aufsichtsregime unterscheidet sich jedoch erheblich.

  • Wesentliche Einrichtungen: Ex-ante-Aufsicht — die zuständige Behörde kann ohne vorherigen Vorfall auf Anforderung prüfen. Bußgelder bis 10 Mio. EUR oder 2 Prozent des weltweiten Jahresumsatzes. Audit-Rhythmus in der Praxis: 12–18 Monate für Neueinsteiger, danach 24 Monate.
  • Wichtige Einrichtungen: Ex-post-Aufsicht — Audits werden durch Vorfälle oder Hinweise auf Non-Compliance ausgelöst. Bußgelder bis 7 Mio. EUR oder 1,4 Prozent des weltweiten Jahresumsatzes. Die Dokumentationserwartungen sind ähnlich; im Steady State ist die Audit-Frequenz niedriger.

Für Firewall-Nachweise besteht der praktische Unterschied in der Vorbereitungs-Kadenz. Wesentliche Einrichtungen können nicht aufschieben. Wichtige Einrichtungen schon — zahlen aber höhere Kosten, sobald ein Vorfall ein Audit auslöst, weil die Dokumentation nicht vorpositioniert ist.

Das gemeinsame Lückenmuster aus mehr als 280 Migrationen

Über mehr als 280 Enterprise-Firewall-Migrationen, die ich analysiert habe, wiederholt sich ein konsistentes Lückenmuster. Es prognostiziert, welche Artikel-21-Submaßnahme im Audit am wahrscheinlichsten durchfällt.

Erstens: Change-Management-Disziplin verschlechtert sich mit operativem Tempo. Betreiber, die im Normalbetrieb diszipliniert Change-Records pflegen, überspringen sie bei Vorfällen und Notfalländerungen. Das Audit zieht zuerst die Notfall-Change-Records, weil dort die Lücke ist.

Zweitens: Segmentierungs-Nachweise altern schneller als das Netz. Diagramme, die 18 Monate alt sind, sind nach zwei Zonen-Restrukturierungen veraltet. Das Artefakt existiert, ist aber nicht mehr akkurat. Auditoren erkennen veraltete Diagramme sofort.

Drittens: Aufbewahrungsrichtlinie und Aufbewahrungsrealität klaffen auseinander. Die Policy sagt 12 Monate. Die tatsächliche SIEM-Rotation liegt bei 90 Tagen, weil das Speicherbudget gekürzt wurde. Beide Dokumente existieren, sie widersprechen sich. Auditoren prüfen die tatsächliche Speicherkonfiguration gegen die deklarierte Policy.

Viertens: Drittparteien-Zugriffsregeln häufen sich an und werden nie zurückgezogen. Vendor-Zugriffsregeln aus abgeschlossenen Projekten bleiben aktiv. Die Erwartungen aus Artikel 21(2)(d) (Lieferkette) werden durch das Fehlen eines Stilllegungsprozesses verletzt, nicht durch das Fehlen von Regeln.

Das Pre-Audit-Pack

Für eine wesentliche Einrichtung vor dem ersten Auditzyklus deckt ein Bündel aus sechs Artefakten in einem gemeinsamen Ordner den Großteil von Artikel 21 ab. Der Ordner ist das Artefakt — nicht die einzelnen Dokumente.

  1. Risikoanalyse-Dokument (aktuelle Version + Revisionshistorie)
  2. Auszug aus dem Firewall-Change-Register (letzte 12 Monate)
  3. Netzwerk-Segmentierungsdiagramm (aktuell + Datum der letzten Überprüfung)
  4. Regelwerks-Review-Bericht (letzter Quartalsdurchlauf)
  5. Incident-Response-Runbook (mit Abschnitt zu Firewall-Aktionen)
  6. Logging-Konfigurations-Nachweis (Aufbewahrungsbeleg, Integritätskontrollen)

Diese Artefakte decken — mit kleineren Formatanpassungen — auch den Großteil der CISA CPGs, NIST 800-53, ISO 27001 Annex A.13 und der deutschen KRITIS-Verpflichtung aus § 8a BSIG ab. Betreiber, die das Pack auf NIS2-Niveau aufbauen, bestehen angrenzende Audits in der Regel mit denselben Nachweisen.

Über den Autor

Nicholas Falshaw ist Principal Security Architect mit über 17 Jahren Erfahrung in Enterprise-Firewall- und Netzwerksicherheit bei DAX-30-Kunden, KRITIS-regulierten Betreibern und EU-Finanzdienstleistern. Er ist Autor der FwChange-Methodik nach Analyse von mehr als 280 Firewall-Migrationen.

Author and Methodology Behind FwChange

FwChange is built and authored by Nicholas Falshaw, drawing on 17+ years of enterprise firewall experience and 280+ migrations. Read the methodology behind the platform.

Stay Updated

Get firewall management tips, compliance guides, and product updates.

No spam. Unsubscribe anytime.

Fw

Nicholas Falshaw

Principal Security Architect & AI Systems Engineer. 17+ Jahre Erfahrung in Enterprise-Firewall- und Netzwerksicherheit bei DAX-30-Kunden und KRITIS-regulierten Betreibern. Autor der FwChange-Methodik und des 280-Migrationen-Datensatzes.

Work with the Architect Behind FwChange

Nicholas Falshaw — 280+ enterprise firewall migrations, AI-assisted change management methodology. Read the methodology or get in touch.