Praxisbericht Firewall-Orchestrierung
Je komplexer die Organisation, desto schwieriger wird es für IT-Verantwortliche, den Überblick über alle Firewall-Regeln zu behalten. Spätestens wenn ein Unternehmen Firewalls unterschiedlicher Hersteller einsetzt, fehlt meist eine einheitliche Sicht auf sämtliche Konfigurationen. Unser Autor gibt Tipps zum Thema Firewall-Orchestrierung.
Firewall Orchestrierung, auch Network Security Policy Management (NSPM) genannt, unterstützt den gesamten Firewall-Rule-Lifecycle-Prozess. Orchestrierung bedeutet hier vor allem „integrierte Automation“: Die täglichen Prozesse wie Dokumentation von Änderungen, Report-Generierung, Beantragung und Umsetzung von Änderungen aber auch komplexere Themen wie Regelwerk-Rezertifizierung oder Soll-Ist-Abgleich sollen vereinfacht beziehungsweise den Firewall-Administratoren und Nutzern zu einem möglichst großen Teil abgenommen werden.
Dies muss natürlich für alle in einem Unternehmensnetzwerk vorhandenen Firewall-Systeme unterschiedlicher Hersteller funktionieren. Hier bietet ein Firewall-Orchestrator eine normalisierte Schnittstelle zu den eingesetzten Firewall-Plattformen, sei es im eigenen Rechenzentrum oder in der Cloud.
Die Motivation und regulatorische Zwänge
Viele Unternehmen gehen den Schritt hin zu einem Orchestrierungstool aus Eigenantrieb, um die vorhandenen manuellen oder zu umständlichen Prozesse zu vereinfachen. Es gibt aber auch einige Unternehmen, für die saubere Firewall-Betriebsprozesse gesetzlich vorgeschrieben sind. Das sind zum Beispiel Finanzdienstleister, Unternehmen, die unter die KRITIS-Verordnung fallen oder auch solche, die für einen Online-Shop Kreditkarteninformationen verarbeiten.
Für diese Firmen gilt es, den Überblick im Dschungel der Regulatorik zu bewahren. Hier seien nur die wichtigsten aktuellen Regularien genannt, die bei einem Audit einer Aufsichtsbehörde zu bösen Überraschungen führen können, wenn der Firewall-Rule-Lifecycle-Prozess nicht sauber aufgesetzt ist:
Betroffene | verbindlich ab | Regulierungsbehörde | Regelungen |
---|---|---|---|
deutsche Versicherungen | sofort | BaFin | VAIT (Versicherungsaufsichtliche Anforderungen an die IT) |
deutsche Banken | sofort | BaFin | BAIT (Bankaufsichtliche Anforderungen an die IT) |
deutsche Betreiber kritischer Infrastrukturen | sofort | BSI | BSI KRITIS-Verordnung |
alle Unternehmen, die Kreditkartendaten verarbeiten | sofort | PCI Security Standards Council | PCI DSS 4.0 (Payment Card Industry Data Security Standard) |
europäische Betreiber kritischer Infrastrukturen sowie zusätzlich ITK-Dienstleister, Öffentliche Verwaltungen und Forschungseinrichtungen | Oktober 2024 | EU | NIS-2 (Maßnahmen zur Gewährleistung eines hohen gemeinsamen Sicherheitsniveaus von Netz- und Informationssystemen) |
europäische Finanzunternehmen sowie ITK Dienstleister | Januar 2025 | EU | DORA (Digital Operational Resilience Act) |
Beispielsweise müssen Finanzdienstleister, die den Regularien der BaFin unterliegen, darauf achten, dass eine regelmäßige Sichtung und Rezertifizierung der Firewall-Regeln erfolgt. Für KRITIS-Unternehmen ist zu erwarten, dass ein Auditor künftig ähnliche Anforderungen stellt. Werden Kreditkartendaten verarbeitet, ist eine Rezertifizierung der Firewall-Regeln ohnehin erforderlich. In diesem Fall erhöht sich der Turnus auf halbjährlich (nach PCI-DSS).
Die Herangehensweise
In der Praxis hat sich eine stufenweise Einführung von Firewall-Orchestrierungsprozessen bewährt. Hier bieten sich die folgenden Evolutionsstufen an:
- Reporting / Dokumentation von Änderungen
- Antragstellung ohne Implementierung aber mit teilautomatisierten Schritten
- dezentrale Rezertifizierung von Regeln
- Vollautomatische Implementierung (ggf. manueller Genehmigungsschritt) von beantragten Änderungen
Egal ob dieser stufenweise Ansatz gewählt wird oder alle benötigten Funktionalitäten parallel implementiert werden sollen, Unternehmen sollten vor dem Kauf einer Lösung ein sehr konkretes Konzept zur Vorgehensweise entwickelen. So kann es bei der Realisierung einer dezentral aufgehängten Rezertifizierung vorkommen, dass benötigte Basisdaten (etwa die Zuordnung von Regeln zu Applikationen) im Unternehmen noch nicht vorliegen. In einem solchen Fall wird nicht selten ein Vorprojekt benötigt, dass hier die notwendigen Voraussetzungen schafft.
Geht es bei der Rezertifizierung rein um die Erfüllung von regulatorischen Auflagen, kann es aber auch ein valider Ansatz sein, sich die deutlich voneinander abweichenden Lösungen in den Produkten auf dem Markt einmal anzusehen und zu entscheiden, ob ein Herstelleransatz die eigenen Bedürfnisse bereits abdecken kann.
Ein weiter Tipp ist zunächst der Mietkauf auf ein Jahr, anstatt sich durch einen unbefristeten Lizenzkauf länger an einen Hersteller zu binden. In den ersten zwölf Monaten nach Kauf sollte man ein gutes Gefühl entwickeln können, ob man sich den richtigen Partner ausgewählt hat.
Einige Punkte sollte man bei der Einführung besonders im Auge behalten, da es hier häufig zu Problemen kommt.
Herausforderungen im Firmenumfeld selbst wie mangelhafte Basisdaten (CMDB – Configuration Management Database, IPAM – IP Address Management) oder der fehlende Überblick der Applikationsbetreiber über die Kommunikationsbedürfnisse ihrer Applikation (Know your Application).
Insbesondere bei einem dezentralen Ansatz (Verantwortung des Regelwerks liegt nicht bei einer Stelle sondern bei vielen Teilverantwortlichen) ist es wichtig, dass die der Regelaufteilung zugrundeliegenden Daten (etwa IP-Adressdaten aus dem IPAM) korrekt und tagesaktuell sind. Wenn die Basisdaten nicht stimmen, ist der darauf aufbauende automatisierte Prozess von vorneherein zum Scheitern verurteilt.
Und natürlich sind auch die Fachkenntnisse der Netzwerkverantwortlichen wichtig. Wenn niemand (oder nur Wenige) im Unternehmen den Kommunikationsbedarf der eingesetzten Anwendungen kennt, können weder die korrekten Firewall-Regeln beantragt noch diese später auf ihre Sinnhaftigkeit überprüft und rezertifiziert werden. Hier, wie so häufig, lohnt es sich, in die Weiterbildung der Mitarbeiter zu investieren.
Unzulänglichkeiten im einzusetzenden Orchestrierungsprodukt
Hier sind zum Beispiel fehlende Flexibilität der etablierten Hersteller bei Kundenwünschen und fehlende umfassend verfügbare Schnittstellen zur Automation zu nennen. Wenn das ausgewählte Orchestrierungstool entweder keine Schnittstelle für ein bestimmtes Feature bietet oder die Bereitschaft des Herstellers zur Erweiterung der Produktmöglichkeiten nur gering ausgeprägt ist, wird die Automatisierung schwierig bis unmöglich. Neben den angebotenen Features ist somit erfahrungsgemäß die Bereitschaft des Herstellers, auf Kundenwünsche einzugehen, ein entscheidender Faktor für den Erfolg eines Projekts.
Automatisierungsgrad und der hierfür notwendige Aufwand
Eine vollständige Automatisierung ist meistens nicht möglich, nur mit sehr viel Aufwand zu erreichen und auch nicht anzustreben. Es gibt immer Entscheidungen, die von Menschen übernommen werden müssen. Dabei sollte man das Augenmerk auf eine für die jeweilige Unternehmensgröße passende Lösung legen. So ist eine zentrale Rezertifizierung von mehr als 1.000 Firewall Regeln allein durch das Firewall-Team nicht praktikabel. In solchen Größenordnungen sollte ein dezentraler Ansatz gewählt werden, etwa durch eine Unterteilung des Regelwerks in anwendungs- oder abteilungsbezogene Regelgruppen, die dann von den zuständigen Teams dezentral gepflegt und geprüft werden können. Ein Orchestrierungstool bringt erst dann einen echten Mehrwert, wenn mit dessen Hilfe ein Prozess etabliert werden kann, der hier entsprechend den Bedürfnissen des jeweiligen Unternehmens skaliert. Der Gesamtaufwand sollte nicht unterschätzt werden: Je nach dem Grad der zu erreichenden Automatisierung sind zur Einführung einer Lösung Projektlaufzeiten von zwei Jahren durchaus üblich. Oft ist eine Evolution der Prozesse notwendig und sinnvoll, um eine optimale Unterstützung aller beteiligten Fraktionen zu erreichen. Es gilt eine Balance zwischen zentral (in der Regel beim Netzwerk-Team) und dezentral (meist bei den Anwendungsverantwortlichen) angesiedelten Tätigkeiten zu etablieren.
Open-Source-Produkt für Firewall Orchestrierung
Seit 2022 gibt es mit dem Firewall Orchestrator auch eine in Deutschland entwickelte Open-Source-Lösung, die viele der hier angesprochenen Probleme adressiert. Beispielhaft ist in Schaubild 2 die Definition einer Compliance-Matrix zu sehen, welche zur Prüfung von beantragten Regeln verwendet werden kann. Hier ist einfach kontrollierbar, ob die beantragte Kommunikation den Sicherheitsvorgaben auf Zonenebene genügt.
Der in Deutschland entwickelte Firewall Orchestrator ist auf github unter https://github.com/CactuseSecurity/firewall-orchestrator verfügbar. Unternehmen können ihn ohne Lizenzgebühren nutzen. Er unterstützt die gängigen Firewalls wie zum Beispiel von Check Point, Fortinet, Palo Alto, Juniper, Azure und Cisco.
Melvin Hayn ist Marketing Manager bei der Cactus eSecurity GmbH (https://cactus.de)