Firewall Policy Management automatisieren: der grosse Traum vom automatisierten Nichtstun

Wer heutzutage aktuelle Netzwerkinfrastrukturen und Cloud-Anbindungen sicher betreiben will, wird immer mehr Firewall-Instanzen einsetzen wollen und müssen. Das Firewall Policy Management wird so schnell zu einer Sisyphus-Arbeit. Prozesse und Abläufe wollen eingehalten werden und die Deadline für den Change rückt immer näher.

Die Vorstellung, diesen ganzen Prozess zu automatisieren, ist bestechend. Der Applikationsverantwortliche pflegt neue Verkehrsbeziehungen in einer intuitiven Webgui ein, daraus werden automatisch Change Requests erstellt. Die Change Requests finden selbständig den Weg zum verantwortlichen Security Officer, welcher aufgrund einer automatischen Risikoprüfung schneller als bisher entscheiden kann, was mit dem Request geschehen soll. Im Optimalfall ergibt die automatische Prüfung ja gar, dass kein Security Officer den Segen geben muss und der Change implementiert werden darf.

Auf welchen Firewalls oder Security Devices die neuen Regeln erstellt werden müssen, wird aufgrund der Routing-Informationen im Netzwerk automatisch erkannt. Und folgerichtig erstellt das Tool die «Work orders» für die betroffenen Firewalls. Automatisch werden die Regeln danach noch auf die Firewalls installiert und die Applikation funktioniert.

Alle so generierten Changes sind einem Verantwortlichen zuzuordnen und ein anstehender Security Audit zaubert anstelle von Schweissperlen nur noch ein Lächeln ins Firewall-Admin-Gesicht.

In der Praxis ist ein Firewall-Policy-Management-Projekt ein “Digitalisierungsprojekt”. Manuelle Prozesse werden miteinander verlinkt und automatisiert. Durch die Automatisierung und Integration muss das Tool mit einer Vielzahl an Herstellern und Produkten kompatibel sein. Ein hoher Automatisierungsgrad kann nur erreicht werden, wenn alle Layer-3-Netzwerkkomponenten und alle Security Devices integriert werden können.

Dies verursacht Abhängigkeiten und Kompatibilitätsprobleme für Netzwerk- und Security-Komponenten und erfordert weitere Kompatibilitätstests, bevor solche Komponenten aktualisiert oder ausgetauscht werden können.

Firewall Change Requests werden in Ihrem Ticketing-System eröffnet und dies soll so beibehalten werden. Somit muss das Autmatisierungstool sich in das Ticketing-System integrieren, im einfachsten Fall mittels E-Mail-Kommunikation, im besten Fall per APIs.

Um einen Change berechnen zu können, müssen IP-Adressen, Hostnamen, Ports und allenfalls Applikationen oder Userdefinitionen auch im Automatisierungstool bekannt sein. Unterschiedliche Quellen wie Firewall-Management-Syteme, DNS-Listen oder IPAM-Quellen können verwendet werden.

Für die Traffic-Flow-Berechnung wird die Netzwerk-Topologie abgebildet. Klassische Netzwerkrouter und auch SDN oder Cloud-Plattformen müssen eingebunden werden. Und schlussendlich muss die Firewall Policy analysiert und verstanden werden um die richtigen Aktionen oder Work Orders zu generieren.

Alle diese involvierten Komponenten müssen mit dem Automatisierungstool kompatibel sein, eine Herkules-Aufgabe für den Hersteller. Ein kleiner Change in den APIs, SNMP-OIDs oder CLI-Kommandos und der Hersteller muss dies nachpflegen. Lock-In-Situationen können entstehen, wenn Upgrades und Migrationen (noch) nicht gemacht werden können, weil das Automatisierungstool die neue Version / Komponente noch nicht unterstützt.

Wir alle haben es schon gehört: «Das ist das erste Mal, dass dieses Problem auftritt, bei anderen Kunden funktioniert das». Dies gibt es leider auch bei Policy-Automatisierungen. Keine Umgebung ist identisch zu der nächsten oder der vorherigen. Jede Integration ist einzigartig und birgt andere potentielle Stolpersteine.

Aus meiner Sicht müssen Automatisierungsprojekte Schritt für Schritt angegangen werden, mit einem klaren Zielbild vor Augen. Ein phasenweises Vorgehen mit Vorteilen und einem klaren Nutzen nach dem Abschluss jeder Phase.

Ein PoC weitab und fern von der Realität meines Netzwerks bringt mir noch nicht die Sicherheit, dass das Tool auch tatsächlich für mich funktioniert. Eine Testinstallation in einem produktiven (Teil-)Netzwerk bringt erste Einsichten und sollte im Idealfall direkt als Testumgebung bestehen bleiben. Mit den Learnings dieser Testinstallation werden die weiteren Schritte geplant und der Automatisierungsgrad erhöht.

Ein Firewall-Policy-Automatisierungstool einzuführen und zu betreiben ist keine «fire and forget»-Übung, sondern bedingt einen initialen Aufwand und kontinuierliche Pflege.

Links:

Bei der AVANTEC setzen wir auf die Produkte-Suite von AlgoSec, «Business-driven security management»: https://www.avantec.ch/loesungen/algosec/

Auf der Herstellerseite von AlgoSec finden sich viele Tutorials, Video-Learnings etc., um sich ein Bild von der Lösung zu verschaffen: https://www.algosec.com/resources/