Firewall-Regelprüfung für ISO 27001, NIS2, DORA und GDPR
Es ist 07:42 Uhr an einem Montagmorgen. Der CISO eines wachsenden SaaS- und FinTech-Anbieters blickt auf drei separate Nachrichten.
Die erste stammt aus dem SOC. Ein kompromittierter Entwickler-Arbeitsplatz hat über Nacht versucht, eine Verbindung zu einem internen Datenbank-Subnetz herzustellen. Der Datenverkehr wurde blockiert, aber der Analyst möchte bestätigt haben, dass die Firewall-Regel beabsichtigt, aktuell und genehmigt ist.
Die zweite Nachricht kommt von einem großen Unternehmenskunden. Er fordert Nachweise, dass Produktions-, Entwicklungs-, Unternehmens- und Support-Umgebungen segmentiert sind, dass Firewall-Regeln geprüft werden und dass Ausnahmen ablaufen.
Die dritte Nachricht stammt vom Compliance-Manager. Die Organisation ist als wichtiger digitaler Anbieter von NIS2 betroffen, trägt unter GDPR Verantwortung als Auftragsverarbeiter und hat Kunden aus dem Finanzdienstleistungssektor, die IKT-Risikonachweise im Stil von DORA anfordern. Das Leitungsorgan möchte wissen, ob dieselben ISO/IEC 27001:2022-Nachweise alle drei Anforderungen beantworten können.
Dann trifft die Nachbetrachtung des Vorfalls ein. Ein Entwicklungsserver war während einer nächtlichen Änderung beinahe im Internet exponiert. Es gingen keine Kundendaten verloren, aber das Forensikteam entdeckte etwas Schwerwiegenderes als den ursprünglichen Fehler: Eine fünf Jahre alte Firewall-Regel für einen „temporären Test“ erlaubte weiterhin weitreichende Bewegungen zwischen Entwicklung und Produktion. Hätte ein Angreifer Zugriff erlangt, hätte das Netzwerk kaum Widerstand geboten.
Das ist der Moment, in dem viele Organisationen eine schmerzhafte Wahrheit erkennen. Sie verfügen möglicherweise über Firewalls, VLANs, Cloud-Sicherheitsgruppen und Diagramme, aber nicht über Governance für Segmentierungszonen, Regelverantwortung, temporären Zugriff, Änderungsgenehmigungen, Rezertifizierung und Auditnachweise.
Im Jahr 2026 ist „wir haben eine Firewall“ keine belastbare Antwort mehr. Auditoren, Aufsichtsbehörden, Kunden und Versicherer erwarten Nachweise, dass Netzwerke bewusst getrennt sind, Datenverkehr nach geschäftlichem Bedarf gesteuert wird, risikoreiche Ausnahmen kontrolliert werden und Protokolle belegen, dass die Kontrollen wirksam betrieben werden.
Warum Firewall-Governance inzwischen ein Thema für das Leitungsorgan ist
Netzwerksegmentierung wurde früher als rein technisches Engineering-Thema behandelt. Infrastrukturteams waren für VLANs zuständig, Firewall-Administratoren pflegten Regelwerke, Cloud-Teams verwalteten Sicherheitsgruppen, und die Compliance-Funktion sah während Audits lediglich ein Diagramm.
Dieses Betriebsmodell funktioniert nicht mehr.
Die NIS2-Richtlinie verpflichtet wesentliche und wichtige Einrichtungen, geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen umzusetzen, um Risiken für Netz- und Informationssysteme zu beherrschen. Article 21 umfasst Richtlinien zur Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Sicherheit bei Erwerb, Entwicklung und Wartung, Wirksamkeitsbewertung, grundlegende Cyberhygiene, Zugriffskontrolle und Asset-Management. Leitungsorgane müssen diese Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und überwachen.
DORA gilt ab dem 17. Januar 2025 für viele Finanzunternehmen und macht IKT-Risikomanagement zu einer gesteuerten und dokumentierten Disziplin. Articles 5, 6 und 8 verlangen Governance, ein Rahmenwerk für das Management von IKT-Risiken sowie die Identifizierung IKT-gestützter Geschäftsfunktionen, Informations-Assets, IKT-Assets, Abhängigkeiten, kritischer Assets und Interkonnektivität. Articles 9, 10 und 11 adressieren Schutz, Prävention, Erkennung, Reaktion und Wiederherstellung. Articles 24 bis 27 verlangen Tests der digitalen operationalen Resilienz, einschließlich erweiterter Tests für bestimmte Unternehmen. Damit ist Segmentierung ein Resilienzthema, nicht nur ein Firewall-Thema.
GDPR ergänzt die Ebene der datenschutzrechtlichen Rechenschaftspflicht. Article 32 verlangt geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau sicherzustellen, einschließlich Vertraulichkeit, Integrität, Verfügbarkeit und Resilienz. Article 5(1)(f) verlangt Integrität und Vertraulichkeit, und Article 5(2) verlangt Rechenschaftspflicht. Wenn Systeme mit personenbezogenen Daten von kompromittierten Endpunkten, Gastnetzwerken oder unkontrollierten Drittparteipfaden erreichbar sind, kann eine Aufsichtsbehörde fragen, warum diese Pfade existierten.
ISO/IEC 27001:2022 liefert die Managementsystem-Grundlage, die diese Verpflichtungen verbindet. Die Norm verlangt Geltungsbereich, Anforderungen interessierter Parteien, Risikobeurteilung, Risikobehandlung, eine Anwendbarkeitserklärung, operative Planung und Steuerung, Führungsverantwortung, messbare Ziele, dokumentierte Informationen und kontinuierliche Verbesserung. Annex A, unterstützt durch die Leitlinien aus ISO/IEC 27002:2022, enthält die Kontrollbereiche, die für Lieferantenrisiken, Cloud-Services, Protokollierung, Überwachung, sichere Architektur, Trennung von Umgebungen und Änderungsmanagement erforderlich sind.
Der Punkt ist einfach: Netzwerksegmentierung und Firewall-Regelprüfung sind inzwischen Governance-Nachweise.
Das Clarysec-Betriebsmuster: 8.20, 8.22 und 8.32
Clarysec behandelt Segmentierung und Firewall-Prüfung als gemeinsames Betriebsmuster über ISO/IEC 27002:2022-Maßnahmen hinweg, nicht als isolierte technische Aufgaben.
Die drei primären Maßnahmen sind:
| ISO/IEC 27002:2022-Bereich | Governance-Frage | Von Auditoren erwartete Nachweise |
|---|---|---|
| 8.20 Netzwerksicherheit | Werden Netzwerke risikogerecht konzipiert, verwaltet, überwacht und geschützt? | Architekturdiagramme, Firewall-Standards, sichere Netzwerkverfahren, Überwachungsprotokolle, IDS/IPS-Nachweise, Beispiele für VPN- und Cloud-Netzwerkkonfigurationen |
| 8.22 Trennung von Netzwerken | Sind Zonen nach Sensitivität, Funktion und Vertrauensniveau getrennt? | Zonenmodell, Datenflussmatrix, VLAN- und Subnetzdesign, DMZ-Grenzen, Firewall-Regeln zwischen Zonen, Ergebnisse von Segmentierungstests |
| 8.32 Änderungsmanagement | Werden Regeländerungen bewertet, genehmigt, getestet, protokolliert und überprüft? | Änderungstickets, Risikobeurteilungen, Genehmigungen, Rollback-Pläne, Prüfungen nach der Implementierung, Aufzeichnungen zu Notfalländerungen |
In Zenith Blueprint: 30-Schritte-Roadmap für Auditoren [ZB] verortet Clarysec Netzwerksicherheit in der Phase „Kontrollen in der Praxis“, Schritt 20: Maßnahmen 8.18 bis 8.26. Der Leitfaden formuliert die zentrale Auditfrage klar:
„Im Kern verlangt diese Kontrolle, dass Organisationen sicherstellen, dass Netzwerke durch ihre Architektur sicher sind, und nicht erst nachträglich durch Firewalls oder Antivirensoftware ergänzt werden. Das bedeutet, strategisch über Netzwerksegmentierung, Zugriffskontrolle, Verschlüsselung während der Übertragung, Überwachung und Verteidigung in der Tiefe nachzudenken. Es beginnt mit einer einfachen Frage: Wer oder was kommuniziert – und sollte diese Kommunikation stattfinden?“
Diese Frage – „Wer oder was kommuniziert, und sollte diese Kommunikation stattfinden?“ – ist der beste praktische Ausgangspunkt für die Firewall-Regelprüfung. Sie verlagert die Diskussion weg von Tausenden kryptischer ACL-Einträge hin zu geschäftlich begründeten Kommunikationsflüssen.
Derselbe Zenith Blueprint weist Teams an, die Netzwerkarchitektur zu bewerten, indem sie prüfen, ob Firewall-Regeln, IPS/IDS und Fernzugriffskonfigurationen aktuell und gehärtet sind, und bestätigen, dass Cloud-Sicherheitsgruppen, Routing sowie VPC- oder Subnetzregeln der vorgesehenen Architektur entsprechen. Außerdem legt er fest, dass Auditoren ein Netzwerksicherheits-Architekturdiagramm erwarten, das Firewalls, VPN-Gateways, DMZ-Zonen, VLAN-Trennung und Vertrauensgrenzen zeigt.
Für das Änderungsmanagement verortet der Zenith Blueprint die ISO/IEC 27002:2022-Maßnahme 8.32 in der Phase „Kontrollen in der Praxis“, Schritt 21: Maßnahmen 8.27 bis 8.34, und hebt hervor, warum Firewall-Governance scheitert, wenn die Änderungskontrolle schwach ist:
„Diese Kontrolle erkennt eine unbequeme Wahrheit in der IT an: Viele Vorfälle werden nicht durch Angriffe verursacht, sondern durch schlecht gesteuerte Änderungen. Eine zu weit geöffnete Firewall-Regel. Eine aktiv gelassene Debug-Einstellung. Eine vergessene Abhängigkeit nach einer Migration.“
Genau so werden temporäre Firewall-Öffnungen zu dauerhaften Angriffspfaden.
Wie gute Netzwerksegmentierung aussieht
Ein ausgereiftes Segmentierungsprogramm besteht aus vier Ebenen.
Erstens verfügt es über ein Zonenmodell. Zonen sind keine beliebigen Subnetze. Sie sind Vertrauensgrenzen, die an Geschäftsfunktion und Datensensitivität ausgerichtet sind, etwa internetseitig erreichbare DMZ, Produktions-Anwendungsebene, Produktions-Datenbankebene, Unternehmensbenutzernetz, privilegiertes Verwaltungsnetz, Entwicklungsumgebung, Testumgebung, Backup-Netz, Gast-WLAN, OT- oder IoT-Zone und Zone für Drittparteizugriff.
Zweitens verfügt es über eine Kommunikationsflussmatrix. Für jedes Zonenpaar dokumentiert die Organisation erlaubte Quelle, Ziel, Protokoll, Port, Anwendung, Geschäftsverantwortlichen, Systemverantwortlichen, Datentyp, Begründung und Protokollierungsanforderung.
Drittens gibt es Regelverantwortung. Jede Firewall-Regel, Cloud-Sicherheitsgruppenregel oder Richtlinie für einen softwaredefinierten Perimeter hat einen Verantwortlichen, ein Ablauf- oder Rezertifizierungsdatum, ein verknüpftes Änderungsticket und eine geschäftliche Begründung. „Any-to-any“ ist als Feststellung zu behandeln, sofern es nicht formell risikoakzeptiert, zeitlich begrenzt und durch kompensierende Kontrollen abgesichert ist.
Viertens gibt es eine wiederkehrende Überprüfung. Überprüfung bedeutet mehr als den jährlichen Export einer Firewall-Regelbasis. Sie umfasst die Rezertifizierung durch Verantwortliche, den Abgleich mit beobachtetem Datenverkehr, die Erkennung ungenutzter Regeln, die Prüfung temporärer Ausnahmen, die Überprüfung der Internet-Exponierung, Segmentierungstests und den Abgleich mit dem Asset-Inventar.
Clarysecs Netzwerksicherheitsrichtlinie [P-NS] formuliert die Unternehmenserwartung klar:
„Jeglicher Datenverkehr zwischen Zonen muss durch Firewalls oder softwaredefinierte Perimeter-Lösungen gesteuert werden, mit expliziten Default-Deny-Konfigurationen.“
Aus der Unternehmensrichtlinie, Netzwerksicherheitsrichtlinie, Abschnitt „Governance-Anforderungen“, Klausel 5.2.
Dieselbe Richtlinie verknüpft Firewall-Änderungen direkt mit dem Änderungsmanagement:
„Jede Änderung an Firewall-Regelwerken, Routing-Tabellen oder Sicherheitsgruppenkonfigurationen muss der Änderungsmanagement-Richtlinie (P5) der Organisation folgen, einschließlich Rollback-Plänen und Audit-Protokollierung.“
Aus der Unternehmensrichtlinie, Netzwerksicherheitsrichtlinie, Abschnitt „Governance-Anforderungen“, Klausel 5.4.
Für KMU stellt Clarysecs Netzwerksicherheitsrichtlinie für KMU [P-NS-SME] denselben Grundsatz in operativen Begriffen bereit:
„Default-Deny-Regeln müssen für alle eingehenden Verbindungen durchgesetzt werden, sofern sie nicht ausdrücklich erforderlich und genehmigt sind.“
Aus der KMU-Richtlinie, Netzwerksicherheitsrichtlinie für KMU, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.1.2.
Und speziell zur Segmentierung:
„Datenverkehr zwischen Segmenten muss gefiltert werden, und der Zugriff zwischen Segmenten muss dem Prinzip der minimalen Berechtigung folgen.“
Aus der KMU-Richtlinie, Netzwerksicherheitsrichtlinie für KMU, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.2.3.
Diese Richtlinienklauseln ermöglichen es einem Auditor, vom Risiko zur Kontrolle, von der Kontrolle zur Regel, von der Regel zur Genehmigung und von der Genehmigung zu den Protokollen nachzuverfolgen.
Ein Nachweispaket für ISO 27001, NIS2, DORA und GDPR
Viele Teams machen den Fehler, separate Nachweispakete zu erstellen: eines für ISO/IEC 27001:2022, eines für NIS2, eines für GDPR, eines für DORA-Kunden und eines für die Cyberversicherung.
Besser ist es, ein einziges Nachweispaket für Segmentierung und Firewall-Governance aufzubauen, das rahmenwerksübergreifend zugeordnet ist.
Zenith Controls: Der Cross-Compliance-Leitfaden [ZC] ordnet die ISO/IEC 27002:2022-Maßnahme 8.22 Trennung von Netzwerken als präventive Kontrolle ein, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt, dem Cybersicherheitskonzept Protect zugeordnet ist und die operative Fähigkeit der System- und Netzwerksicherheit adressiert. Der Leitfaden verknüpft 8.22 mit 8.20 Netzwerksicherheit, 8.21 Sicherheit von Netzwerkdiensten, 8.7 Schutz vor Schadsoftware, 8.27 Sichere Systemarchitektur und Engineering-Grundsätze sowie 8.31 Trennung von Entwicklungs-, Test- und Produktionsumgebungen.
Der Leitfaden erklärt die Relevanz der Segmentierung für NIS2 wie folgt:
„Die Trennung von Netzwerken ist eine direkte Antwort auf diese Verpflichtungen, da sie Angriffsflächen reduziert und seitliche Bewegung über vernetzte Systeme hinweg verhindert.“
Dieser Satz beschreibt, warum NIS2-Cyberhygieneprogramme Segmentierung nicht als optional behandeln sollten. Ransomware-Eindämmung betrifft nicht nur Endpunktschutz. Sie bedeutet, seitliche Bewegung zu begrenzen, wenn Prävention versagt.
Für GDPR ordnet Zenith Controls 8.22 Article 32 und Recital 49 zu und weist darauf hin, dass Netzwerkdiagramme und Zonenrichtlinien zu zentralen Nachweisen der Einhaltung werden. Für DORA ordnet Zenith Controls Netzwerksicherheit und Trennung dem IKT-Risikomanagement und der Eindämmung von Vorfällen zu. Segmentierungstests können IKT-Resilienznachweise unterstützen, insbesondere wenn sie belegen, dass eine Kompromittierung in einer Zone sich nicht frei in kritische Finanzdienstleistungen, Ablagen personenbezogener Daten oder privilegierte Verwaltungssysteme ausbreiten kann.
| Nachweisartefakt | Verwendung für ISO/IEC 27001:2022 und ISO/IEC 27002:2022 | Verwendung für NIS2 | Verwendung für DORA | Verwendung für GDPR |
|---|---|---|---|---|
| Netzwerksicherheits-Architekturdiagramm | Unterstützt ISMS-Geltungsbereich, operative Steuerung, 8.20 und 8.22 | Zeigt technische Maßnahmen für die Sicherheit von Netz- und Informationssystemen | Zeigt IKT-Interkonnektivität und Abhängigkeiten kritischer Services | Zeigt Schutzgrenzen um Systeme mit personenbezogenen Daten |
| Zonen- und Kommunikationsflussmatrix | Belegt risikobasierte Trennung und Prinzip der minimalen Berechtigung | Unterstützt Cyberhygiene und Wirksamkeitsbewertung | Unterstützt Klassifizierung von IKT-Assets und Abhängigkeiten | Unterstützt technische Maßnahmen nach Article 32 und Rechenschaftspflicht |
| Aufzeichnungen zu Firewall-Regelprüfungen | Nachweis für Kontrollüberwachung und kontinuierliche Verbesserung | Zeigt, dass Maßnahmen überprüft werden und nicht statisch sind | Unterstützt IKT-Risikoüberprüfung und Resilienztests | Belegt die fortlaufende Sicherheit der Verarbeitung |
| Änderungstickets für Firewall-Regeln | Unterstützt 8.32 Änderungsmanagement | Unterstützt sichere Wartung und Nachvollziehbarkeit | Unterstützt gesteuerte IKT-Änderungen und Resilienz | Zeigt, dass Änderungen mit Auswirkungen auf Systeme mit personenbezogenen Daten risikobewertet werden |
| Ausnahmenregister | Unterstützt Risikobehandlung und Restrisikoakzeptanz | Zeigt Managementaufsicht über Abweichungen | Unterstützt Risikotoleranz und Governance | Zeigt Rechenschaftspflicht für temporäre Exponierung |
| Protokolle zu blockiertem und erlaubtem Datenverkehr zwischen Zonen | Unterstützt Protokollierung, Überwachung und Kontrollwirksamkeit | Unterstützt Erkennung und Incident Response | Unterstützt Vorfallklassifizierung und Berichterstattung | Unterstützt Bewertung von Datenschutzverletzungen und Beweissicherung |
Diese Tabelle ist nicht nur eine Compliance-Zuordnung. Sie ist eine Roadmap für die Nachweiserhebung.
Die Firewall-Regelprüfung, die tatsächlich funktioniert
Eine Firewall-Regelprüfung scheitert, wenn sie nur fragt: „Wird diese Regel noch benötigt?“ Regelverantwortliche sagen oft Ja, weil sie befürchten, etwas zu unterbrechen.
Eine bessere Überprüfung stellt sechs Fragen:
- Welchen Geschäftsservice unterstützt diese Regel?
- Welcher Asset-Verantwortliche und welcher Dateneigentümer haben den Kommunikationsfluss genehmigt?
- Befindet sich das Ziel in der richtigen Zone für Daten und Funktion?
- Ist die Regel weiter gefasst, als es der beobachtete Datenverkehr erfordert?
- Ist Protokollierung für risikoreiche Kommunikationsflüsse aktiviert?
- Hat die Regel ein Überprüfungsdatum, ein Ablaufdatum oder einen Ausnahmeeintrag?
Die Netzwerksicherheitsrichtlinie für KMU verlangt eine regelmäßige Überprüfung:
„Der IT-Support-Dienstleister muss jährlich eine Überprüfung der Firewall-Regeln, Netzwerkarchitektur und Wireless-Konfigurationen durchführen.“
Aus der KMU-Richtlinie, Netzwerksicherheitsrichtlinie für KMU, Abschnitt „Governance-Anforderungen“, Klausel 5.6.1.
Die jährliche Überprüfung ist die Basislinie, nicht die Obergrenze. Risikoreiche Regeln erfordern häufigere Rezertifizierung.
| Regelkategorie | Beispiel | Überprüfungsfrequenz | Erwartete Genehmigung |
|---|---|---|---|
| Eingehend aus dem Internet in die Produktion | Öffentliche API zum Anwendungsgateway | Vierteljährlich oder nach wesentlicher Freigabe | Serviceverantwortlicher, Sicherheit, Änderungsgenehmiger |
| Produktions-Datenbankzugriff zwischen Zonen | Anwendungsebene zur Datenbankebene | Vierteljährlich | Anwendungsverantwortlicher und Dateneigentümer |
| Administrativer Zugriff | Jump-Host zu Serververwaltungsports | Monatlich oder vierteljährlich | Infrastrukturverantwortlicher und CISO-Delegierter |
| Drittparteizugriff | Lieferanten-VPN zum Support-Subnetz | Monatlich oder zu vertraglichem Meilenstein | Lieferantenverantwortlicher und Sicherheit |
| Temporäre Ausnahme | Notfallzugriff während einer Migration | Vor Ablauf, maximal 90 Tage | ISMS-Manager oder CISO |
| Standardmäßige interne Regel mit geringem Risiko | Überwachungsserver zu verwalteten Endpunkten | Jährlich | Serviceverantwortlicher |
Die Netzwerksicherheitsrichtlinie ist bei Ausnahmen eindeutig:
„Der Antrag muss vom ISMS-Manager oder CISO geprüft und genehmigt sowie im ISMS-Ausnahmeregister erfasst werden; die maximale Genehmigungsdauer beträgt 90 Tage und kann nach Neubewertung verlängert werden.“
Aus der Unternehmensrichtlinie, Netzwerksicherheitsrichtlinie, Abschnitt „Risikobehandlung und Ausnahmen“, Klausel 7.3.
Für KMU verlangt die Netzwerksicherheitsrichtlinie für KMU, dass Ausnahmeanträge die erforderlichen Mindestangaben enthalten:
„Der Antrag muss Begründung, Geltungsbereich, Dauer und kompensierende Kontrollen enthalten (z. B. IP-Positivlisten, Protokollierung).“
Aus der KMU-Richtlinie, Netzwerksicherheitsrichtlinie für KMU, Abschnitt „Risikobehandlung und Ausnahmen“, Klausel 7.3.3.
Diese Klausel überführt Ausnahmebehandlung aus informellem Chat in auditierbare Risikobehandlung.
Praxisbeispiel: Entfernen einer riskanten Produktions-Datenbankregel
Angenommen, ein Unternehmen findet während der Überprüfung die folgende Regel:
| Feld | Aktueller Wert |
|---|---|
| Quelle | Unternehmensbenutzer-VLAN |
| Ziel | Produktions-Datenbanksubnetz |
| Port | TCP 5432 |
| Aktion | Zulassen |
| Kommentar | Temporärer Zugriff für Reporting-Migration |
| Erstellt | Vor 14 Monaten |
| Verantwortlicher | Unbekannt |
| Protokollierung | Deaktiviert |
Dies ist eine klassische Audit-Feststellung. Sie verletzt das Prinzip der minimalen Berechtigung, hat keinen klaren Verantwortlichen, kein Ablaufdatum, keine aktuelle Begründung und keine Protokollierung. Sie schafft außerdem eine Exponierung nach GDPR Article 32, wenn die Produktionsdatenbank personenbezogene Kundendaten enthält.
Der Abhilfeprozess sollte Nachweise erzeugen und nicht nur eine schlechte Regel entfernen.
| Schritt | Maßnahme | Clarysec-Referenz | Erzeugter Auditnachweis |
|---|---|---|---|
| 1. Regel dem Zonenmodell zuordnen | Bestätigen, ob Unternehmensbenutzer jemals das Produktions-Datenbanksubnetz erreichen sollten | Zenith Blueprint, Kontrollen in der Praxis, Schritt 20 | Aktualisierte Notizen zur Architekturprüfung und Zonenklassifizierung |
| 2. Kommunikationsflussdatensatz erstellen oder aktualisieren | Quelle, Ziel, Port, Datentyp, Verantwortlichen, Begründung und Risiko dokumentieren | Zenith Controls, Zuordnung zu 8.22 | Eintrag in der Zonen- und Kommunikationsflussmatrix |
| 3. Änderungsticket eröffnen | Entfernung oder Ersatz durch einen gesteuerten Pfad für Reporting-Services vorschlagen | Netzwerksicherheitsrichtlinie, Klausel 5.4 | Änderungsaufzeichnung mit Risikoanalyse, Testplan und Rollback-Plan |
| 4. Behandlung entscheiden | Breite Regel entfernen oder durch Nur-Lese-Replikat, Bastion-Host, IP-Positivlisten und Protokollierung ersetzen | Netzwerksicherheitsrichtlinie, Klausel 7.3 | Entscheidung zur Risikobehandlung oder zeitlich begrenzte Ausnahme |
| 5. Protokollierung für genehmigte Kommunikationsflüsse aktivieren | Risikoreiche Firewall-Ereignisse zwischen Zonen an die Überwachung senden | Richtlinie zur Protokollierung und Überwachung, Klausel 6.1.1.6 | SIEM-Aufzeichnungen, Alarmregeln und Überwachungs-Screenshots |
| 6. Segmentierung validieren | Testen, dass das Datenbanksubnetz nur über genehmigte Pfade erreichbar ist | Zenith Blueprint, Schritt 20 | Ergebnis des Segmentierungstests und Abschluss der Abhilfemaßnahme |
Clarysecs Richtlinie zur Protokollierung und Überwachung [P-LM] umfasst externe Kommunikation und Firewall-Regelauslöser als protokollierungsrelevante Ereignisse:
„Externe Kommunikation und Firewall-Regelauslöser“
Aus der Unternehmensrichtlinie, Richtlinie zur Protokollierung und Überwachung, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.1.1.6.
Bei risikoreichen Regeln zwischen Zonen sollten Firewall-Auslöser in das SIEM oder die Überwachungsplattform einfließen, mit Warnmeldungen für ungewöhnliche Quellhosts, Volumina oder Zeitfenster.
Die KMU-Richtlinie verlangt außerdem Änderungsdisziplin:
„Alle Änderungen an Netzwerkkonfigurationen (Firewall-Regeln, Switch-ACLs, Routing-Tabellen) müssen einem dokumentierten Änderungsmanagementprozess folgen.“
Aus der KMU-Richtlinie, Netzwerksicherheitsrichtlinie für KMU, Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Klausel 6.9.1.
Eine einzige Bereinigung dieser Regel erzeugt Nachweise für die operative Steuerung nach ISO/IEC 27001:2022, ISO/IEC 27002:2022 8.20, 8.22 und 8.32, NIS2-Cyberhygiene, GDPR Article 32 und IKT-Risikomanagement im Stil von DORA.
Cloud, SaaS und hybride Netzwerke müssen einbezogen werden
Moderne Segmentierung besteht nicht nur aus VLANs und physischen Firewalls. Sie umfasst AWS-Sicherheitsgruppen, Azure-Netzwerksicherheitsgruppen, Kubernetes-Netzwerkrichtlinien, Cloud-Routing-Tabellen, SaaS-Administrations-Positivlisten, private Endpunkte, VPNs, SD-WAN, identitätsbewusste Proxys und softwaredefinierte Perimeter-Kontrollen.
Für einen SaaS-Anbieter oder regulierten digitalen Dienst sollte die Firewall-Regelprüfung mindestens Folgendes umfassen:
- Internetseitig erreichbare Load Balancer und Anwendungsgateways
- Cloud-Sicherheitsgruppen und Netzwerk-ACLs
- Routing-Tabellen privater Subnetze
- Peering- und Transit-Gateway-Pfade
- VPN- und Remote-Administrationspfade
- Administrationsschnittstellen und Managementebenen
- Kubernetes-Ingress- und Netzwerkrichtlinien
- Zugriff von CI/CD-Runnern auf die Produktion
- Protokollierungsabdeckung für abgelehnte und erlaubte risikoreiche Kommunikationsflüsse
- Support-Zugriff Dritter und Break-Glass-Pfade
Wenn eine Cloud-Sicherheitsgruppe eingehenden Datenbankverkehr aus einem breiten Unternehmens-IP-Bereich erlaubt, behandeln Sie sie wie eine Firewall-Regel. Sie benötigt Verantwortlichkeit, Begründung, Genehmigung, Überprüfung, Protokollierung und Ablaufdatum.
An dieser Stelle stärken unterstützende ISO-Normen zusätzlich die Argumentation. ISO/IEC 27017 schafft Klarheit über Verantwortlichkeiten für Cloud-Sicherheit. ISO/IEC 27033 bietet vertiefte Leitlinien zu Netzwerksicherheitsarchitektur, DMZs, Segmentierungszonen, Verkehrsfilterung und sicherer Kommunikation zwischen Netzwerken. ISO/IEC 27701 stärkt Datenschutz-Governance, wenn personenbezogene Daten über Netzwerke bewegt werden. ISO/IEC 27035 unterstützt die Eindämmung von Vorfällen, und ISO/IEC 27005 unterstützt die Auswahl von Segmentierung als Risikobehandlung für unautorisierten Zugriff, Ausbreitung von Schadsoftware und seitliche Bewegung.
Wie Auditoren dieselbe Kontrolle unterschiedlich prüfen
Eine Stärke von Zenith Controls besteht darin, zu erklären, wie unterschiedliche Auditmethoden dieselbe Kontrolle untersuchen. Die Nachweise können wiederverwendet werden, aber die Fragen unterscheiden sich.
| Audit-Perspektive | Wahrscheinliche Frage | Bester Nachweis |
|---|---|---|
| ISO/IEC 27001:2022-Auditor | Wurde Segmentierung risikobasiert ausgewählt, umgesetzt und überprüft? | Risikobeurteilung, SoA, Netzwerkrichtlinie, Diagramme, Überprüfungsaufzeichnungen |
| Auditor im Stil von ISO/IEC 27007 | Stimmen implementierte Firewall-Regeln und VLAN-Schemata mit der dokumentierten Richtlinie überein? | Stichproben von Firewall-Regeln, Router-ACLs, VLAN-Design, Interviews mit Administratoren |
| Zertifizierungsaudit-Ansatz nach ISO/IEC 27006-1:2024 | Werden kritische Netzwerkgrenzen mit geeigneter Kompetenz und risikobasierter Planung auditiert? | Auditplan, technische Stichproben, Nachweise zu Cloud-Sicherheitsgruppen, Testergebnisse |
| NIST-orientierter Auditor | Werden Grenzen und Informationsflüsse durchgesetzt und überwacht? | Firewall-Regeln, ACLs, Segmentierungstests, Überwachungsaufzeichnungen |
| COBIT 2019-Auditor | Wird Netzwerksicherheit gesteuert, überwacht und berichtet? | Verantwortlichkeitsmatrix, KPIs, Managementberichterstattung, Risikoregister |
| ISACA ITAF-Auditor | Funktionieren allgemeine IT-Kontrollen konsistent? | Änderungstickets, Ausnahmegenehmigungen, Protokolle, Stichproben zur Regelrezertifizierung |
| GDPR-Aufsichtsbehörde | Waren Systeme mit personenbezogenen Daten durch geeignete technische Maßnahmen geschützt? | Datenflussübersichten, Isolation von PII-Zonen, Zugriffspfade, Firewall-Protokolle |
| DORA-fokussierter Prüfer | Unterstützt Segmentierung die IKT-Resilienz und die Eindämmung von Vorfällen? | Abhängigkeitsübersicht für IKT-Assets, Kommunikationsflüsse kritischer Funktionen, Incident-Playbooks, Testaufzeichnungen |
Ein DORA-fokussierter Prüfer kann fragen, ob eine Kompromittierung eines Zahlungsgateways in Kundendatenbanken pivotieren kann. Eine zuständige Behörde nach NIS2 kann fragen, ob Ransomware auf einem administrativen Arbeitsplatz zentrale Systeme der Leistungserbringung erreichen kann. Eine GDPR-Behörde kann fragen, welche netzwerkbezogenen Beschränkungen Systeme geschützt haben, die personenbezogene Daten verarbeiten. Ein ISO-Auditor fragt möglicherweise schlicht nach Risikobeurteilung, SoA, Richtlinie, Verfahren und Nachweisen, dass Überprüfungen stattgefunden haben.
Die besten Programme beantworten all diese Fragen mit denselben Artefakten.
Kennzahlen, die Segmentierung für die Leitungsebene sichtbar machen
NIS2 und DORA verstärken beide die Rechenschaftspflicht des Managements. ISO/IEC 27001:2022 verlangt Führung, Ziele, Rollen, Ressourcen, Berichterstattung und kontinuierliche Verbesserung. Das bedeutet, dass Segmentierung Kennzahlen benötigt, die das Leitungsorgan versteht.
Nützliche Managementkennzahlen sind unter anderem:
- Prozentsatz der Firewall-Regeln mit zugewiesenem Verantwortlichen
- Prozentsatz der Regeln mit dokumentierter geschäftlicher Begründung
- Anzahl abgelaufener temporärer Regeln
- Anzahl der Regeln mit „any“ als Quelle, Ziel oder Service
- Anzahl internetexponierter Services nach Kritikalität
- Prozentsatz risikoreicher Kommunikationsflüsse zwischen Zonen mit aktivierter Protokollierung
- Anzahl von Notfall-Firewall-Änderungen pro Quartal
- Prozentsatz geprüfter Regelstichproben, die genehmigten Änderungstickets zugeordnet sind
- Anzahl fehlgeschlagener Segmentierungstests
- Mittlere Zeit zur Behebung riskanter oder ungenutzter Regeln
- Anzahl von Ausnahmen, die älter als 90 Tage sind
- Anzahl geprüfter und rezertifizierter Zugriffsregeln für Dritte
Die Netzwerksicherheitsrichtlinie nennt „Wirksamkeit von Firewall-Regeln“ als Betrachtungspunkt für Einhaltung und Durchsetzung im Abschnitt „Durchsetzung und Einhaltung“, Klausel 8.2.2. Diese Formulierung ist wichtig, denn die bloße Existenz von Regeln reicht nicht aus. Regeln müssen wirksam, überprüft und am aktuellen Risiko ausgerichtet sein.
Aufbau des Segmentierungs-Nachweispakets für 2026
Ein praktisches Nachweispaket zur Segmentierung und Firewall-Regelprüfung sollte bereitstehen, bevor der Auditor danach fragt.
Mindestens sollten gepflegt werden:
- Aktuelles Netzwerkarchitekturdiagramm einschließlich Cloud- und Hybridzonen
- Standard zur Zonenklassifizierung einschließlich Sensitivität und Vertrauensniveau
- Kommunikationsflussmatrix für kritische Services und Systeme mit personenbezogenen Daten
- Export von Firewall- und Cloud-Sicherheitsgruppenregeln
- Register zu Regelverantwortlichen und Rezertifizierung
- Verfahren zur Firewall-Überprüfung und Überprüfungskalender
- Änderungsaufzeichnungen für geprüfte Firewall-Modifikationen
- Ausnahmenregister mit Genehmigungen, Ablaufdatum und kompensierenden Kontrollen
- Ergebnisse von Segmentierungstests und Aufzeichnungen zu Abhilfemaßnahmen
- Nachweise zu Protokollierung und Überwachung für risikoreiche Kommunikationsflüsse
- Incident-Playbooks, die Eindämmung nach Zone zeigen
- Managementberichtskennzahlen und Sitzungsprotokolle
Ordnen Sie diese Nachweise den Klauseln von ISO/IEC 27001:2022 und den Kontrollbereichen aus Annex A zu. Verweisen Sie anschließend auf NIS2 Article 21, GDPR Article 32, DORA-Anforderungen an IKT-Risikomanagement und Tests, NIST CSF 2.0-Ergebnisse wie GOVERN, PROTECT, DETECT und RESPOND sowie COBIT-Governance-Praktiken.
NIST CSF 2.0 ist besonders nützlich als Kommunikationsebene für das Leitungsorgan. Seine GOVERN-Funktion konzentriert sich auf gesetzliche, regulatorische und vertragliche Anforderungen, Risikobereitschaft, Rollen, Richtlinien und Aufsicht. Die operativen Ergebnisse adressieren Konfigurationsmanagement, Protokollierung, Überwachung, Datenschutz, Incident Response und Wiederherstellung. Dies hilft dem Leitungsorgan, Risiken zu verstehen, ohne Firewall-ACLs lesen zu müssen.
Häufige Feststellungen, die Clarysec in Segmentierungsaudits sieht
Bei SaaS-Anbietern, FinTechs, Managed Service Providern und regulierten KMU treten immer wieder dieselben Feststellungen auf:
- Flaches Netzwerk zwischen Benutzerendpunkten und Produktionsservices
- Produktionsdatenbanken sind aus Entwicklungs- oder Unternehmensnetzwerken erreichbar
- Breite Cloud-Sicherheitsgruppen, die aus alten Vorlagen kopiert wurden
- Temporäre Lieferantenregeln ohne Ablaufdatum
- Firewall-Änderungen außerhalb des Änderungsprozesses
- Regeln ohne Verantwortlichen oder geschäftliche Begründung
- Deaktivierte Protokollierung bei risikoreichen Zulassungsregeln
- Gast-WLAN ist nicht vollständig isoliert
- Administrationsschnittstellen sind aus allgemeinen Netzwerken erreichbar
- Diagramme stimmen nicht mit dem tatsächlichen Routing überein
- Kein Nachweis, dass Regelprüfungen abgeschlossen wurden
- Keine Segmentierungstests nach wesentlichen Architekturänderungen
- Keine Zuordnung zwischen Systemen mit personenbezogenen Daten und Netzwerkzonen
- Keine Managementberichterstattung zur Netzwerkexponierung
Diese Feststellungen sind nicht nur technische Schwächen. Sie untergraben die Fähigkeit der Organisation, NIS2-Cyberhygiene, operationale Resilienz nach DORA und Rechenschaftspflicht nach GDPR Article 32 nachzuweisen.
Von reaktiver Bereinigung zu belastbarer Kontrolle
Netzwerksegmentierung und Firewall-Regelprüfung sind der Punkt, an dem Sicherheitsarchitektur auf Auditrealität trifft. Wenn Sie ein risikobasiertes Zonenmodell, kontrollierte Kommunikationsflüsse zwischen Zonen, genehmigte Firewall-Änderungen, zeitlich begrenzte Ausnahmen, Protokollierungsnachweise und regelmäßige Validierung vorlegen können, beantworten Sie ein breites Spektrum an Fragen zu ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST und COBIT mit einer kohärenten Darstellung.
Clarysec kann Ihnen helfen, diese Darstellung aufzubauen.
Nutzen Sie Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, um die Umsetzung zu strukturieren, insbesondere Kontrollen in der Praxis, Schritt 20 für Netzwerksicherheit und Segmentierung sowie Schritt 21 für Änderungsmanagement. Nutzen Sie Zenith Controls: Der Cross-Compliance-Leitfaden, um ISO/IEC 27002:2022-Maßnahmen 8.20, 8.22 und 8.32 den Audit-Erwartungen aus NIS2, DORA, GDPR, NIST und COBIT zuzuordnen. Verankern Sie Ihre operativen Regeln in Clarysecs Netzwerksicherheitsrichtlinie, Netzwerksicherheitsrichtlinie für KMU und Richtlinie zur Protokollierung und Überwachung.
Ihr nächster Schritt ist einfach und wertvoll: Wählen Sie diese Woche einen kritischen Service aus, etwa Kundenproduktion, Zahlungsabwicklung oder Identitätsmanagement, und führen Sie eine Stichprobenprüfung von 10 Regeln durch. Bestätigen Sie für jede Regel Verantwortlichen, Begründung, Quelle, Ziel, Port, Protokollierung, Änderungsticket und Ablaufdatum. Wenn Sie diese sieben Fakten nicht nachweisen können, haben Sie den Ausgangspunkt für Ihren Segmentierungsverbesserungsplan 2026.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
