280 Firewall-Migrationen: Datenanalyse 2026

Zwischen 2018 und 2025 habe ich mehr als 280 Enterprise-Firewall-Migrationen geleitet oder unterstützt — bei DAX-30-Kunden, KRITIS-regulierten Betreibern und Tier-1-Finanzdienstleistern. Nachdem das letzte Projekt abgeschlossen war, habe ich die Engagement-Aufzeichnungen ausgewertet und einen strukturierten Datensatz erstellt. Dieser Beitrag ist die Zusammenfassung der Kennzahlen: Cutover-Zeiten, Regelmengen, Fehlerklassen und herstellerspezifische Edge Cases, die wiederkehrend aufgetaucht sind.

Der vollständige Datensatz ist die Grundlage der FwChange-Methodik und des technischen White Papers. Es handelt sich um Single-Author-Forschung, nicht um Hersteller-Marketing. Alle Zahlen sind anonymisiert und aggregiert; keine Kundennamen werden offengelegt.

1. Datensatz: Umfang und Zusammensetzung

280 Migrationen ist die Endsumme der Projekte, in denen ich als verantwortlicher oder unterstützender Engineer für Regelübersetzung, Validierung oder Cutover-Ausführung zuständig war. Kleinere Beratungsmandate, in denen ich Arbeit anderer geprüft habe, sind ausgeschlossen. Der Zeitraum ist Januar 2018 bis Dezember 2025.

• Hersteller-Mix Quellseite: Cisco ASA (38%), Check Point R7x/R80+ (24%), Juniper SRX/Netscreen (16%), Fortinet FortiGate (12%), Palo Alto PAN-OS (6%), sonstige (4% — überwiegend McAfee Sidewinder und Stonesoft-Restbestände).
• Hersteller-Mix Zielseite: Palo Alto PAN-OS (51%), Fortinet FortiGate (29%), Check Point R80+ (11%), Cloud-nativ (AWS Security Groups + Azure NSG, 6%), sonstige (3%).
• Durchschnittliche Regelbasis-Größe: 4.700 Regeln pro Estate; Median 2.800; größtes Einzel-Estate 47.000 Regeln.
• Objektmengen: durchschnittlich 18.000 Adressobjekte, 3.200 Services, 1.400 Gruppen.
• Branchenverteilung: Finanzwesen 31%, Industrie 22%, Energie/Versorgung 14%, Gesundheitswesen 11%, öffentlicher Sektor 10%, Telekommunikation 8%, sonstige 4%.

2. Cutover-Zeiten

Die Cutover-Dauer war keine reine Funktion der Regelmenge. Drei Projektgrößen kristallisierten sich heraus, die mehr durch Komplexität (Anzahl Zonen, Hersteller-Vielfalt, Audit-Umfang) als durch reine Regelzahl unterschieden waren.

Der Sprung von manuell zu KI-gestützt ab 2024 ist kein Zauber. Die größten Einsparungen entstanden durch wegfallende Nacharbeit: Objektauflösung, NAT-Übersetzung, App-ID-Divergenz und Shadow-Rule-Bereinigung sind die vier größten Zeitfresser, und alle vier reagieren gut auf LLM-gestützte Analyse, sobald das Modell Zugriff auf die normalisierte Regelbasis hat.

3. Verteilung der Fehlerklassen

Über alle 280 Migrationen hinweg wurden 1.847 unterschiedliche Cutover-Defekte erfasst (Durchschnitt 6,6 pro Migration). Defekte wurden auf Ursachen-Ebene klassifiziert, nicht auf Symptom-Ebene. Die Taxonomie wurde iterativ über den gesamten Datensatz entwickelt; der Begleitbeitrag (Firewall-Migration-Fehler-Taxonomie) erläutert jede Klasse im Detail. Die Verteilung in Stichworten:

• Übersetzungsfehler (28%) — Regelsemantik wurde in der Zielsyntax falsch dargestellt. Häufigster Fall: PAN-OS-„Application“ gegenüber ASA-„Service“ und Cluster-XL-Reihenfolge bei Check Point.
• Lücken in der Objektauflösung (24%) — verschachtelte Gruppen, dynamische Objekte und FQDN-Objekte, die in der Zielumgebung nicht zu denselben IPs auflösen.
• NAT-Semantik-Drift (19%) — Source/Destination-NAT-Reihenfolge, Hide-NAT versus Static und Policy-basiertes NAT werden zwischen Herstellern unterschiedlich gehandhabt.
• Verlust von Logging-Einstellungen (12%) — Per-Regel-Logging-Optionen wurden in der Übersetzung nicht erhalten; SIEM-Anbindungen brachen still ab.
• App-ID-Divergenz (10%) — PAN-OS-App-ID erkannte Verkehr, den ASA-Service-Einträge nicht trafen, oder umgekehrt.
• Implicit-Deny-Inversionen (7%) — Default-Deny-Reihenfolge zwischen Quelle und Ziel führte zu unterschiedlichem Endzustands-Verhalten für nicht gematchten Verkehr.

Übersetzungsfehler und Objektauflösung machen zusammen mehr als die Hälfte aller Cutover-Defekte aus. Beides ist deterministisch, sobald die Quell-Regelbasis vollständig vorliegt, und beides lässt sich durch konsequente Vor-Cutover-Validierung verhindern.

4. Herstellerspezifische Edge Cases

Jeder Hersteller hat wiederkehrende Edge Cases, die in praktisch jeder Migration auftauchen, in der dieser Hersteller beteiligt ist. Senior-Engineers kennen sie; in offiziellen Migrationsleitfäden tauchen sie selten auf.

Cisco ASA → PAN-OS

• ASA-Service-Objekte, die TCP und UDP in einer Definition kombinieren, müssen in zwei PAN-OS-Service-Objekte aufgeteilt werden.
• „any“ in Object-Group-Form bei ASA verschleiert die Absicht; PAN-OS bevorzugt explizite Zonen.
• Identitätsbasierte ASA-Regeln mit LDAP/AD-Gruppen erfordern auf PAN-OS eine User-ID-Konfiguration, nicht nur eine Regelübersetzung.

Check Point R7x → R80+ oder PAN-OS

• Inline-Layer-Regeln in R80+ lassen sich nicht sauber in flache Regelbasen übersetzen; geordnete Policies müssen flach gemacht werden.
• Cluster-XL-Installations-Reihenfolge kann von der Policy-Reihenfolge abweichen. Vor HA-Cutover mit Single-Gateway-Trockendurchlauf testen.
• SmartDashboard-Objekte mit identischem Anzeigenamen, aber unterschiedlichen UIDs verursachen stille Kollisionen beim Export über die Management-API.

Juniper SRX → FortiGate oder PAN-OS

• Junos-Zonen sind teilweise feiner gegliedert als PAN-OS-Zonen — Konsolidierung erfordert eine bewusste Entscheidung.
• „then count“-Statements liefern Per-Regel-Trefferzähler, die andere Hersteller anders bereitstellen.
• SRX-Dynamic-VPN-Policies haben kein direktes PAN-OS-Pendant; meist ist ein GlobalProtect-Neuaufbau erforderlich.

Fortinet FortiGate-zu-FortiGate (Versionssprünge)

• Große Versionssprünge (5.x → 7.x) führen neue Policy-ID-Anforderungen ein; In-Place-Upgrade behält IDs, plattformübergreifende Migration nicht.
• FortiManager-Policy-Package-Import verliert Per-Regel-Kommentare, sofern sie nicht explizit migriert werden.
• SSL-Inspection-Profile, die an Policies gebunden sind, benötigen einen Zertifikatskettenneuaufbau am neuen Endpunkt.

5. Was sich im 7-Jahres-Fenster geändert hat

Drei Trends haben die Migrationslandschaft zwischen 2018 und 2025 verschoben.

1. Cloud-native Ziele wuchsen von 1% auf 6% der Migrationen. AWS Security Groups, Azure NSGs und in geringerem Maße GCP-Firewall-Regeln übernahmen Perimeter-Funktionen, die zuvor an Hardware-Appliances hingen. Die Übersetzung auf Cloud-native Ziele bringt eigene Fehlermodi mit (kein FQDN-Objekt-Support, Regel-Limits pro Security Group, regionsweise Replikation), die es im Appliance-zu-Appliance-Zeitalter nicht gab.
2. Anwendungsbewusste Policies wurden Standard. Bis 2022 referenzierten mehr als 80% neuer Policies Anwendungen statt nur Ports/Protokolle. Das erhöhte die Übersetzungskomplexität, reduzierte aber die Regelmengen für neue Estates im Schnitt um 35–45%.
3. KI-gestützte Analyse wechselte von Forschung zu Produktion. Der Schnittpunkt 2024 markiert, wann LLM-Tooling reif genug war, realistische Hersteller-Syntax-Übersetzung mit nachprüfbarem Ergebnis zu liefern. Frühere Versuche (2020–2022) produzierten zu viele Übersetzungsfehler, um in regulierten Umgebungen vertrauenswürdig zu sein.

6. Methodik

Die Aufzeichnungen stammen aus Projektabschluss-Berichten, Change-Management-Tickets und Post-Cutover-Reviews. Regel- und Objektmengen kamen aus den Exports der Quell-Firewall-Management-Plattformen. Die Defekt-Taxonomie wurde iterativ entwickelt: Eine erste Liste von 14 Kategorien wurde nach Erreichen der Mustersättigung um Migration 180 auf die heutigen sechs Klassen reduziert. Defektzählungen stammen aus Cutover-Window-Incident-Logs und den ersten 30 Tagen nach dem Cutover.

Alle Zahlen sind auf Engagement-Ebene anonymisiert. Die Branchenverteilung erhält den Regulierungskontext, ohne Kundennamen offenzulegen. Der Datensatz selbst ist derzeit nicht veröffentlicht; das White Paper greift auf die aggregierten Erkenntnisse zurück.

7. Einschränkungen

• Der Datensatz ist europa- und DACH-lastig; US-Federal- und APAC-Mandate sind dünn vertreten.
• Vor 2020 sind die Aufzeichnungen weniger vollständig; Defektzählungen für 2018–2019 sind konservativ.
• Cloud-native Migrationen sind im Vergleich zum aktuellen Marktmix unterrepräsentiert — bei einer 2026/2027-Aktualisierung dürfte sich das verschieben.
• Der Datensatz beruht auf der Erfahrung eines einzelnen Engineers. Querchecks mit Peer-Datensätzen sind willkommen.

8. Praktische Konsequenzen

Drei umsetzbare Lehren für Teams, die aktuell eine Migration planen:

1. Budget für die Übersetzungsvalidierung einplanen, nicht für die Übersetzung selbst. Der Engpass ist nicht das Konvertieren der Syntax, sondern der Nachweis, dass die Übersetzung die Absicht erhält. Automatisiertes Diff-Testing gegen ein repräsentatives Traffic-Capture ist die günstigste Versicherung.
2. Objektauflösung als eigene Phase planen. Adressgruppen-Flachlegen, FQDN-Auflösung und Dynamic-Object-Behandlung als eigenen Workstream mit eigenen Akzeptanzkriterien zu führen, verhindert, dass Objektfehler in Regelfehler kaskadieren.
3. Cutover-Kapazität für Logging- und NAT-Verifikation reservieren. Diese beiden Fehlerklassen verursachen zusammen 31% der Post-Cutover-Defekte und werden in einer reinen Regelvalidierung leicht übersehen.

Der Begleitbeitrag zur Fehler-Taxonomie geht jede Defektklasse mit Erkennungsmustern, typischen Symptomen und Präventionsstrategien durch. Zusammen mit dem White Paper bilden diese drei Artefakte den praktischen Output von sieben Jahren Migrationsarbeit.