Ein historisches Firewall-Regelwerk entflechten

Ein historisches Firewall-Regelwerk verrät viel über ein Netzwerk, nur selten das, was man sich erhofft hatte. Hunderte Einträge, Any-Regeln, Management-Ausnahmen, DMZ-Durchstiche: jeder davon ein Beleg dafür, wo das Zonenmodell im Alltag erodiert ist. Die Versuchung ist, mit dem Löschen zu beginnen. In einer hybriden IT-/OT-Umgebung verursacht man genau so einen Ausfall.

Warum Regeln löschen nicht reicht

Eine Firewall-Regelbereinigung im IT-/OT-Bestand ist kein kosmetisches Projekt. Historische Freigaben, Any-Regeln, Management-Ausnahmen, DMZ-Durchstiche und unklare Objektgruppen sind direkte Hinweise darauf, wo Segmentierung erodiert ist, doch wer sie einfach löscht, riskiert einen Produktionsausfall, weil viele dieser Regeln unbemerkt einen realen Betriebsbedarf abdecken.

Die Arbeit besteht darin, jede Regel auf eine Zone, einen legitimen Flow und eine Betriebsverantwortung zurückzuführen. Zwei Prinzipien ziehen sich durch:

Erst verstehen, dann reduzieren

Policy-Hits, Objektbezüge und Zonenkontext entscheiden, was weg kann, nicht eine Vermutung darüber, was ungenutzt aussieht.

Hybrid statt Silo

Die IT-, DMZ-, Admin- und OT-Pfade werden gemeinsam betrachtet, in einem Gesamtbild, nicht getrennt nach Teams.

01Die Konfiguration extrahieren

Der erste Schritt liest das bestehende Setup ein: Interfaces, Zonen, Policies, Objekte und die offensichtlichen Lücken. Eine Konfigurationsdatei wird automatisch geparst; das Ergebnis ist noch kein Zieldesign, sondern eine belastbare Faktenbasis, die IT, OT und Security auf denselben Stand bringt.

Zonen, Interfaces und nicht zonierte Grenzen werden sichtbar
Breite Objekte und Management-Ausnahmen treten als strukturelle Probleme zutage
Das Inventarwissen stammt aus der Live-Konfiguration, nicht aus PDFs und Change-Tickets

02Die Findings priorisieren

Nicht jede Altlast ist gleich kritisch. Any-Regeln, breite Management-Freigaben, fehlende Inspection und harte IT-/OT-Ausnahmen werden nach Risiko und Machbarkeit eingestuft, damit die Bereinigung dort beginnt, wo es zählt, nicht dort, wo es am einfachsten ist. Das Panel unten ist die Parser-Ausgabe aus der importierten Konfiguration: 33 Findings über Policy, Hardening, VPN und Architektur.

03Die Zielkommunikation ableiten

Bereinigung ohne Zieldesign lässt nur neue Ausnahmen wachsen. Aus dem Zonenmodell und der Kommunikationsmatrix entsteht ein reduziertes Zielregelwerk, und Conduits dokumentieren die erlaubten Übergänge zwischen IT, DMZ und OT, während alles andere standardmässig abgewiesen wird.

IT-, DMZ- und OT-Grenzen als explizite Conduits definieren
Admin-Zugriff auf Jump-Hosts, Session-Kontrollen und freigegebene Ziele beschränken
Die Kommunikationsmatrix wird zur massgeblichen Referenz für das neue Regelwerk

Dieses Prinzip muss zu etwas werden, das ein Team tatsächlich prüfen und freigeben kann. Die Kommunikationsmatrix macht daraus ein explizites Raster: Jedes Zonenpaar erhält eine bewusste Allow- oder Deny-Entscheidung, mit protokollspezifischen Ausnahmen, wo ein Flow wirklich gebraucht wird. Sie ist das Dokument, aus dem das neue Regelwerk gebaut wird, und die Referenz, gegen die ein Auditor es prüfen kann.

Von der Analyse zur Umsetzung

Die Analyse liefert die Faktenbasis und die Priorisierung. Vier Bausteine tragen das Zieldesign anschliessend in ein laufendes Regelwerk:

Matrix und Zielzonen abgleichen

Aus der Analyse wird ein freigabefähiges Zieldesign: Zonen, Conduits und dokumentierte Ziel-Flows für IT, DMZ, Admin und OT.

Pilot-Regeln in Wellen planen

Statt eines riskanten Big Bang werden Regeln mit hoher Wirkung in Pilotpakete gebündelt, jedes mit Wartungsfenster und Rückfallpfad.

Altregeln stilllegen

Historische Ausnahmen, breite Objekte und ungeklärte Freigaben werden nicht blind gelöscht, sondern sauber migriert oder bewusst entfernt.

Review und Verantwortung verankern

Logging, Verantwortlichkeiten und wiederkehrende Reviews verhindern, dass das neue Regelwerk gleich nach Projektende wieder erodiert.

Wie eine gute Bereinigung aussieht

Mehr als Löschkandidaten

Auch Management-Zugriffe, DMZ-Übergänge und OT-Dienste werden geprüft, nicht nur die offensichtlich toten Regeln.

Regeln auf Zonen zurückgeführt

Jede Regel wird gegen ein Zieldesign aus Zonen und Conduits geprüft, nicht als alleinstehende Freigabe belassen.

Das Inventar bleibt sichtbar

Historische Ausnahmen und hybride Pfade werden bewusst migriert oder stillgelegt, nie still ignoriert.

Review-fähiger Betrieb

Logging, Verantwortung und regelmässige Reviews verhindern, dass das Regelwerk erneut unkontrolliert wächst.

Häufige Fragen

Reicht es nicht, ungenutzte Regeln einfach zu löschen?

Nein. In IT- und OT-Netzen sind Regeln oft Stellvertreter für reale Betriebsbedürfnisse, Workarounds oder fehlende Zonen. Ohne Kommunikations- und Zonenkontext kann ein scheinbar unnötiger Eintrag geschäfts- oder produktionskritisch sein.

Funktioniert das nur mit FortiGate?

Das gezeigte Beispiel nutzt die FortiGate-Konfigurationsanalyse. Methodisch gilt der Ablauf aber auch für andere Hersteller: Regelbestand verstehen, Zonen ableiten, Kommunikationsbedarf dokumentieren und das Zielregelwerk daraus entwickeln.

Wie reduziert man das Risiko für den laufenden Betrieb?

Durch Priorisierung und Wellen: kritische Any-Regeln zuerst, flankiert von Logging, Pilotierung, Wartungsfenstern und fachlicher Freigabe durch IT-, OT- und Service-Verantwortliche. Cleanup ist kein einmaliger Sprint, sondern eine gesteuerte Transformation.

Was ist der Unterschied zwischen Cleanup und Redesign?

Cleanup reduziert und ordnet den Bestand. Redesign definiert das Zielsystem. In Brownfield-Projekten braucht man meistens beides: zuerst die bestehenden Regeln verstehen und entflechten, dann ein Zielregelwerk mit Zonen und Conduits etablieren.

Wie hängt das mit IEC 62443 und einer OT-DMZ zusammen?

IEC 62443 liefert das Prinzip: Zonen und Conduits statt ungeordnetem Lateral Movement. Die DMZ ist dabei ein zentraler Übergang. Firewall-Regelbereinigung ist der operative Schritt, um diese Architektur im hybriden IT-/OT-Bestand überhaupt durchsetzbar zu machen.

Geht es nur um Firewall-Regeln, oder auch um VLANs und Switch-ACLs?

Firewall-Regeln steuern den Verkehr zwischen Zonen. VLANs und Switch-ACLs definieren, welche Geräte überhaupt in einer Zone landen und was auf Layer 2 erlaubt ist. Beides gehört zusammen: Die Firewall-Analyse deckt auf, welche Zonen tatsächlich existieren. Daraus ergibt sich, wo VLANs fehlen, falsch geschnitten sind oder ACLs auf dem Switch nachgezogen werden müssen.

Was hat Firewall-Cleanup mit NIS2 zu tun?

NIS2 verlangt dokumentierte Netzsicherheitsmassnahmen und regelmässige Wirksamkeitsprüfungen. Ein Regelwerk mit hunderten undokumentierten Altlasten erfüllt beides nicht. Ein Cleanup dient direkt mehreren Massnahmen aus dem Katalog (Risikoanalyse, Wirksamkeitsprüfung und Zugriffskontrolle), indem es die nachvollziehbare Grundlage liefert: dokumentierte Zonen, begründete Regeln und einen Review-Prozess, den ein Auditor prüfen kann.

Wie stelle ich sicher, dass das Regelwerk langfristig sauber bleibt?

Durch einen definierten Regel-Lebenszyklus: Jede neue Regel braucht einen Antragspfad, einen verantwortlichen Owner, eine dokumentierte Begründung und ein Ablaufdatum oder einen Review-Termin. Regelmässige Audits prüfen, ob Regeln noch einem aktiven Kommunikationsbedarf entsprechen. Ohne Owner und Prozess wächst jedes Regelwerk innerhalb weniger Jahre wieder auf denselben Stand zurück.