BEKOM OPEN PROPalo-Alto-Firewall-ExitOPNsense, pfSense evaluieren
Palo-Alto-NGFW ablösen: OPNsense, pfSense, Check Point Quantum und VyOS im Vergleich, Policy-Konvertierung und Migrationspfad für Mittelstand und Enterprise.
Warum Palo-Alto-Firewall-Exit aktuell ist
Palo Alto Networks positioniert seine NGFW-Plattform konsequent als Enterprise-Security-Fabric mit eng verzahnten Subscription-Modulen: Threat Prevention, WildFire, Advanced URL Filtering, DNS Security, GlobalProtect, IoT Security, SD-WAN. Jedes Modul ist einzeln lizenziert, die Preise entwickeln sich über die letzten Jahre nach oben. Gleichzeitig verschiebt sich der Produkt-Fokus in Richtung Prisma Access und Cortex XSIAM – Cloud-zentrische Plattformen, die ein anderes Betriebsmodell und eine andere Beschaffungslogik voraussetzen. Für Mittelstands-Organisationen, die eine Palo-Alto-NGFW als lokale Perimeter-Firewall betreiben, entstehen damit Fragen jenseits der reinen Funktionstiefe: Passt die Bündelungslogik langfristig zum Bedarf? Rechtfertigt der Funktionsumfang den Subscription-Druck? Sind Panorama-Zentrale, App-ID und WildFire wirklich geschäftskritisch, oder werden sie pflichtig mitgekauft?
Der Wechsel von Palo-Alto-Firewalls betrifft geschäftskritische Perimeter-Sicherheit und kann operative Geschäftsprozesse wie standortübergreifende VPN-Verbindungen, Auftragsverarbeitung über sichere Kanäle oder Compliance-relevante Audit-Trails beeinträchtigen. → BEKOM OPEN PRO Security
Warum Palo-Alto-Kunden eine strategische Neubewertung anstellen
Der Druck zur Neubewertung kommt aus mehreren Richtungen gleichzeitig. Im Kern steht nicht Unzufriedenheit mit der Firewall-Technologie, sondern ein verändertes Kosten-Nutzen-Verhältnis.
Typische Auslöser:
Subscription-Preisanpassungen bei Modul-Bundles – kontinuierliche Erhöhungen bei der Bündelung mehrerer Protection-Module (Threat Prevention, WildFire, URL Filtering, DNS Security) ohne Einzel-Lizenzierung
Hardware-Refresh mit Subscription-Reset – Generationswechsel der PA-Serie zwingt zum Plattformwechsel mit erneuter Subscription-Verlängerung über die volle Hardware-Laufzeit
Fokus-Verschiebung auf Prisma Access – Cloud-zentrische Plattform-Strategie führt SD-WAN-nahe Lösungen aus dem klassischen NGFW-Portfolio heraus und zwingt zur Re-Architektur
Konsolidierungsdruck und Cloud-Abhängigkeiten – mehrere Security-Plattformen (EDR, SIEM, SASE) sind bereits im Einsatz, gleichzeitig wirft Cloud-Abhängigkeit einzelner PAN-Funktionen (WildFire-Cloud-Sandbox, DNS Security in AWS-Regionen) Compliance-Fragen auf
Der Ausgang der Neubewertung ist nicht zwangsläufig ein Wechsel – oft führt er zu Modul-Bereinigung, Subscription-Right-Sizing oder einem Teil-Exit auf weniger kritischen Standorten.
Wann sich ein Palo-Alto-Exit-Assessment bei BEKOM rechnet
Wenn Subscription-Verlängerung, Panorama-Komplexität oder ungenutzte Modul-Bündel die Budget- und Risiko-Sicht ins Wanken bringen, ist eine strukturierte Bewertung der Optionen die nächste sinnvolle Stufe. BEKOM begleitet das Palo-Alto-Exit-Assessment herstellerneutral und ohne vorgegebenes Zielprodukt.
Typische Anlässe für ein Assessment:
Renewal-Stichtag mit Bundle-Eskalation – Subscription-Verlängerung mit Preissprung, Pflicht-Bundling von Threat Prevention, WildFire, URL Filtering und DNS Security ohne aktive Nutzung aller Module
Panorama-Komplexität intern nicht beherrschbar – Device-Groups, Templates, Variable-Substitutions und Hierarchie-Konflikte überfordern das interne Team; Wechsel oder externe Begleitung wird unausweichlich
App-ID-Modul-Bündel ohne reale Nutzung – Log-Analyse zeigt, dass nur ein Bruchteil der lizenzierten App-ID-Taxonomie tatsächlich angesprochen wird; Subscription-Right-Sizing wird zur Option
Hardware-Refresh und Plattform-Konsolidierung – Generationswechsel der PA-Serie, Konsolidierung mit SASE/EDR-Stack oder Verlagerung in den deutschen Datenraum stehen ohnehin an
Im Strategiegespräch werden Standortlandschaft, Vertragslage und Migrationsfenster geklärt – das Ergebnis ist ein schriftliches Angebot mit dokumentiertem Bewertungsrahmen.
Compliance- und Audit-Druck als zusätzlicher Treiber
Cloud-Abhängigkeit einzelner PAN-Module, US-Anbieter-Bindung und SOC-Integrations-Tiefe wirken nicht nur auf das IT-Budget, sondern auf die Audit- und Compliance-Position. Branchen mit strenger Datensouveränitäts-Anforderung bewerten Palo Alto damit zunehmend als strategisches Risiko.
Compliance-Treiber im Mittelstand:
Cloud-Sandbox und DNS-Security in US-Regionen – WildFire-Sandbox-Analyse und DNS Security laufen in Cloud-Plattformen mit Datenstandort-Beschränkungen; DSGVO-Auskunft wird komplexer
Datenstandort der Threat-Telemetrie – App-ID- und Threat-Intelligence-Telemetrie wandert in Anbieter-Cloud; Sub-Auftragsverarbeiter-Liste wächst mit jeder Modul-Aktivierung
Audit-Spuren für ISO 27001, TISAX und KRITIS – Regelwerk-Historie, Change-Verfahren und Datenstandorte sind Bestandteil der Zertifizierung; Open-Source-Plattformen mit deutscher Sub-Auftragsverarbeiter-Liste sind hier nachweisleichter
CISO- und Aufsichtsorgan-Berichtslast – steigende Subscription-Kosten ohne dokumentierte Nutzungs-Quote sind zunehmend gegenüber Geschäftsführung und Aufsichtsorgan begründungsbedürftig
Diese Treiber summieren sich zu einem dokumentierbaren Anlass, eine geordnete Bewertung der Palo-Alto-Abhängigkeit anzustoßen – ohne damit das Ergebnis vorwegzunehmen.
Alternativen im Vergleich
Die Zielplattformen für einen Palo-Alto-Exit unterscheiden sich in Funktionsmodell, Hardware-Ansatz und Betriebsphilosophie deutlich. Die folgende Einordnung betrachtet vier Optionen mit klar unterschiedlichem Profil. Weiterführend: Netzwerksicherheit & Firewall.
OPNsense – pragmatische Open-Source-Zielplattform
OPNsense deckt klassische NGFW-Funktionen in Open-Source-Ausprägung ab: Paketfilter, stateful Inspection, Anwendungserkennung (ntopng, Zenarmor-Plugin), IDS/IPS über Suricata, Reverse-Proxy über HAProxy. Die Plattform wird von der niederländischen Deciso B.V. gepflegt und hat starke DACH-Präsenz.
Charakteristika:
Lizenzmodell: Open Source (BSD 2-Clause), optionale Business-Edition
Vergleichspunkte zu Palo Alto: Paketfilter-Logik, VPN (IPsec, WireGuard, OpenVPN) und IDS-Funktionalität gleichwertig; App-ID-Ebene ist über Plugins abbildbar, nicht in identischer Tiefe; Zentrale Verwaltung via API, nicht mit Panorama-Komfort
Hardware: Deciso-Appliances oder freie x86-Hardware
Support: Community, Deciso Business Edition, DACH-Partner-Ökosystem
OPNsense passt, wenn App-ID-Funktionalität nicht die primäre Schutzebene ist und Netzwerksegmentierung, VPN, Web-Proxy und IDS den Kern bilden. Der Funktionsabstand zu Palo Alto im NGFW-Kern ist kleiner, als die Marketing-Positionierung vermuten lässt.
pfSense – globale Open-Source-Plattform mit Enterprise-Angebot
pfSense wird von Netgate gepflegt. pfSense Plus als kommerzielle Variante läuft exklusiv auf Netgate-Hardware mit TAC-Support.
Charakteristika:
Lizenzmodell: pfSense CE Open Source (Apache 2.0), pfSense Plus proprietär
Funktionsabdeckung: vergleichbar mit OPNsense (gleiche pf-Basis), andere Paketauswahl und Support-Struktur
Hardware: Netgate-Appliances oder freie Hardware
Support: TAC-Support bei Netgate, globales Partnernetzwerk
pfSense ist relevant, wenn eine weltweite Herstellerbasis, Netgate-Hardware mit TAC-Support oder bestehende pfSense-Standorte im Verbund vorhanden sind. Für rein deutschsprachige Mittelstandslandschaften ist OPNsense häufig die naheliegendere Wahl.
Check Point Quantum – proprietäre Enterprise-Alternative
Check Point Quantum ist die Enterprise-NGFW-Linie von Check Point mit eigener Policy-Sprache, SmartConsole und Quantum Security Management. Wer die NGFW-Tiefe behalten, aber den Hersteller wechseln möchte, findet hier eine nahe Alternative.
Charakteristika:
Lizenzmodell: proprietäre Software-Blades mit Subscription-Verlängerung
Funktionsabdeckung: Application Control, IPS, Threat Emulation, URL Filtering, Identity Awareness – vergleichbar mit Palo-Alto-Subscription-Bündeln
Zentrale Verwaltung: SmartConsole mit zentralem Management-Server, architektonisch nahe an Panorama
Support: Check Point TAC, starkes Enterprise-Partnernetzwerk
Check Point Quantum passt, wenn die Funktionstiefe von Palo Alto weiter benötigt wird und der Wechsel primär aus Kommerz- oder strategischen Gründen erfolgt. Der Herstellerbindungs-Charakter bleibt, die Verlagerung wirkt auf die Lieferantenbeziehung, nicht auf das Architekturmodell.
VyOS – rein Linux-basierte Routing- und Firewall-Plattform
VyOS ist eine Linux-basierte, CLI-zentrierte Open-Source-Plattform für Routing, VPN, Firewalling und Load-Balancing. Relevanter Spezial-Kandidat für Rechenzentrums-Szenarien.
Charakteristika:
Lizenzmodell: Open Source (LTS-Releases über Subscription bei VyOS Networks), Rolling-Release frei
Funktionsabdeckung: klassisches Routing, Firewalling, BGP/OSPF, IPsec, WireGuard, NAT, QoS – ohne GUI, konsequent konfigurationsbasiert
Integration: passt in Infrastructure-as-Code-Pipelines, Ansible-freundlich, CI/CD-nah
Support: VyOS-Subscription für LTS-Releases, Community für Rolling-Release
VyOS ist die richtige Wahl für Automatisierungs-nahe Teams mit Rechenzentrums-Fokus, DevOps-Kompetenz und CLI-Präferenz. Für klassische Mittelstands-Standortfirewalls ist der Bedienansatz meist zu technisch – dort passt OPNsense besser.
Migrationspfad und Phasen
Der Umzug einer Palo-Alto-Landschaft läuft anwendungs- und standortgetrieben. Die Phasen sind klar abgegrenzt, jede endet mit einem Freigabepunkt, den IT-Leitung und Security gemeinsam zeichnen.
Phase 1: Policy-Assessment und Telemetrie-Baseline
Die bestehende PAN-Landschaft wird nicht nur konfigurativ, sondern verhaltensbasiert erfasst – Logs, App-ID-Treffer und Subscription-Nutzung werden ausgewertet.
Inhalt der Phase:
Export und Strukturierung aller Sicherheitsregeln, NAT-Policies, QoS-Definitionen und Decryption-Profile aus PAN-OS
Analyse der App-ID-Treffer pro Regel anhand von Log-Daten: welche App-IDs werden tatsächlich angesprochen, welche Regeln sind redundant, welche Subscriptions sind ungenutzt
Erfassung von Panorama-Templates, Device-Groups, Variable-Substitutions und Hierarchie-Konflikten
Inventar von GlobalProtect-Gateways, Portal-Konfigurationen, Client-Zertifikaten und Authentifizierungsquellen
Ergebnis ist eine faktengestützte Entscheidungsgrundlage – inklusive einer Aussage darüber, welche PAN-spezifischen Bausteine tatsächlich geschäftskritisch sind und welche wegfallen können.
Phase 2: Pilot-Konvertierung und Funktions-Benchmark
Ein repräsentatives Standort- oder Segment-Regelwerk wird auf die Zielplattform übertragen und gegen die PAN-Baseline verglichen.
Inhalt der Phase:
Aufbau der Ziel-Appliance (OPNsense, pfSense, Check Point Quantum oder VyOS) in einer Testumgebung mit produktionsnaher Topologie
Regelwerk-Konvertierung: Übertragung von Objekten, Gruppen, NAT-Rules und Security-Policies; App-ID-Regeln werden in Port-/Domain-/Kategorien-basierte Regeln zerlegt oder via Plugin auf Application-Ebene nachgebildet
Decryption-Strategie auf der Zielplattform: TLS-Inspection-Umfang und Zertifikatsverteilung neu festlegen
Funktions-Benchmark: Prüfung von Durchsatz, Latenz, IPS-Erkennungsrate, Proxy-Verhalten gegen die PAN-Baseline unter Last
Die Pilotphase liefert eine ehrliche Gap-Analyse: welche Funktionen sind auf dem Zielsystem äquivalent, welche brauchen Kompensation, welche entfallen – und ob die Kompensation vertretbar ist.
Phase 3: Segment- und Standort-Rollout
Der produktive Umzug erfolgt in logisch abgegrenzten Stufen: Perimeter, DMZ-Zonen, interne Segmentierung, Remote-Access. Bis zum Cutover-Abnahmepunkt jeder Stufe bleibt die PAN-Plattform rückfallfähig.
Inhalt der Phase:
Stufen-Planung nach Kritikalitätszonen und Abhängigkeit zu laufenden Panorama-Templates
Cutover-Verfahren pro Stufe: Interface-Übernahme, Routing-Umstellung, NAT-Konsistenz, VPN-Reauthentifizierung, definierter Fallback-Pfad
Ausführung mit Abnahmekriterien: Applikations-Erreichbarkeit, Latenz-Budget, Durchsatz, IDS-/IPS-Alarm-Profil, SIEM-Log-Konsistenz
Koexistenz: PA-Appliance und Ziel-Plattform laufen parallel, bis Stufe inkl. Nachbeobachtung abgenommen ist
Kritische Perimeter (Hauptstandort, Internet-Uplink) folgen erst, nachdem kleinere Segmente den Prozess bestätigt haben.
Phase 4: Panorama-Abbau und SIEM-Re-Integration
Nach der letzten Stufe werden PAN-Appliances und Panorama kontrolliert abgebaut, Telemetrie-Pfade auf die neue Plattform umgestellt.
Inhalt der Phase:
Abnahme-Review: Regelwerk-Vollständigkeit, GlobalProtect-Ablösung, Threat-Coverage, Decryption-Abdeckung
Rückbau der PA-Hardware, Kündigung oder Nichtverlängerung der Subscription-Module zum Vertragsende, Abbau des Panorama-Servers
Re-Integration der neuen Plattform in SIEM, SOC und Compliance-Reporting; Anpassung von Korrelationsregeln und Dashboards
Übergabe an das interne Team oder strukturierter Übergang in den Managed Service
Mit dieser Phase endet das Projekt; der Regelbetrieb übernimmt mit dokumentierter Policy-Baseline und aktualisierter Telemetrie-Landkarte.
Betriebsmodelle nach der Migration
Mit dem Umstieg stellt sich die Betriebsfrage neu. Drei Modelle stehen zur Wahl und lassen sich innerhalb der Vertragslaufzeit anpassen.
Internes Security-Team
Das eigene Team verantwortet die neue Plattform vollständig: Regelwerk-Lifecycle, Threat-Intelligence-Integration, IPS-Signaturen, SIEM-Korrelation, Incident-Reaktion.
Stärken:
Policy-Ownership bleibt vollständig im Haus, kurze Wege zu Applikations-Teams
Unmittelbarer Zugriff auf Log-Daten und Forensik ohne Service-Schnittstelle
Threat-Intelligence und IPS-Feed-Auswahl werden eigenständig gewählt und gesteuert
Detailentscheidungen im Incident-Fall bleiben bei den Verantwortlichen
Geeignet, wenn:
- Security-Kompetenz im Team breit abgedeckt ist (inkl. Vertretungsregelung)
- Rufbereitschaft für schwere Security-Incidents intern organisierbar ist
- Firewall-Änderungen eng mit dynamischen Anwendungsentwicklungen getaktet sein müssen
Managed Service durch BEKOM
BEKOM übernimmt die NGFW-Plattform mit vertraglich geregelten Leistungen: Policy-Changes nach dokumentiertem Prozess, Patch-Zyklen, IDS-Signatur-Management, Threat-Feed-Integration, 24/7-Incident-Reaktion, Reporting an IS-Beauftragte und Auditoren.
Stärken:
Zentraler Change-Prozess mit dokumentierter Historie und Vier-Augen-Freigabe
Security-Operations-Reaktion rund um die Uhr ohne interne Rufbereitschaftslinie
Abgestimmtes Reporting gegenüber Informationssicherheits-Beauftragten, Datenschutz und Revision
Klare Trennung zwischen Plattform-Betrieb (BEKOM) und strategischer Steuerung (Kunde)
Geeignet, wenn:
- Das interne Team entlastet werden soll, um Kapazität für Anwendungs- und Architekturthemen zu gewinnen
- Sicherheits-SLAs gegenüber Auftraggebern, Versicherungen oder Audit-Standards belegt werden müssen
- Compliance-Anforderungen (ISO 27001, TISAX, BSI-Grundschutz, KRITIS) eine dokumentierte Betriebsstruktur verlangen
Geteiltes Betriebsmodell
Architektur-Entscheidungen, Policy-Richtlinien und strategische Change-Hoheit bleiben beim Kunden; operative Routine und 24/7-Reaktion übernimmt BEKOM.
Stärken:
Policy-Ownership bleibt im Haus, operative und reaktive Last reduziert
24/7-Bereitschaft, Threat-Intelligence-Kuration und Forensik-Tiefe extern abgedeckt
Aufgabenanteile lassen sich im Zeitverlauf anpassen – mehr intern, wenn Kompetenz wächst
Dokumentation hält Wissen auch bei personellen Wechseln stabil
Geeignet, wenn:
- Ein Security-Team vorhanden ist, aber nicht in jeder Schicht tragfähig bleibt
- Change-Hoheit bewusst intern liegen soll
- Spezialthemen (TLS-Inspection-Design, SD-WAN-Integration, Threat-Hunting) punktuell extern laufen
BEKOM ist Partner für den Palo-Alto-Exit
Ein Palo-Alto-Exit ist mehr als ein Firewall-Wechsel – er betrifft Policy-Qualität, Telemetrie-Strategie und die Architektur der Sicherheits-Operations insgesamt. Drei Merkmale prägen die Zusammenarbeit mit BEKOM: eine Bewertung ohne Plattform-Vertriebsinteresse, eine geschlossene technische Verantwortung vom Policy-Assessment bis zum Regelbetrieb und ein auf deutschsprachige Mittelstands-Organisationen zugeschnittener Kommunikations- und Rechtsraum.
Bewertung ohne Plattform-Vertriebsinteresse
BEKOM ist weder OPNsense-, pfSense-, Check-Point- noch Palo-Alto-Reseller und hat keine Lizenzprovisionen aus der Plattform-Entscheidung. Die Empfehlung orientiert sich an Policy-Komplexität, App-ID-Nutzungsprofil, Telemetrie-Strategie und Betriebsstruktur.
Das bedeutet in der Projektrealität:
Bewertungsraster (Funktionsabdeckung, Policy-Migrationsaufwand, Betriebslast, Subscription-Profil) werden vor Projektbeginn schriftlich vereinbart
Jede Empfehlung wird gegen mindestens eine plausible Alternative argumentiert
OPNsense, pfSense, Check Point Quantum und VyOS laufen durch dasselbe Raster
Ein begründeter Verbleib auf Palo Alto mit Modul-Bereinigung ist ausdrücklich ein zulässiges Ergebnis
Weder Subscription-Provisionen noch Partnertargets fließen in die Entscheidung ein
App-ID-Nutzungsanalysen, Rule-Hit-Auswertungen und Decryption-Mappings werden offen dokumentiert
Daraus entsteht eine Grundlage, die gegenüber Geschäftsführung, CISO, Audit (ISO 27001, TISAX, KRITIS-Prüfer) dokumentierbar ist und bei Bedarf von Dritten nachgeprüft werden kann.
Geschlossene technische Verantwortung
Policy-Assessment, Pilot-Konvertierung, Rollout und anschließender Betrieb werden von denselben technischen Rollen geführt. Die Übergaben zwischen den Phasen laufen ohne Re-Briefing.
Das heißt konkret:
App-ID-Analysen und Rule-Hit-Statistiken aus Phase 1 gehen direkt als Arbeitsgrundlage in die Pilot-Konvertierung
Konvertierungsmuster und Gap-Befunde aus Phase 2 (Decryption-Profile, IPS-Signatur-Mapping, GlobalProtect-Ersatz) werden zum Rollout-Baustein
Das Rollout-Team übergibt an den Betrieb mit einem gemeinsam erstellten Runbook inklusive Policy-Change-Prozess und Threat-Response-Playbooks
Eine benannte technische Leitung begleitet das Projekt vom ersten Log-Export bis zum dokumentierten Regelbetrieb
Beratungs-, Migrations- und Betriebsrollen laufen unter einheitlicher Vertragsstruktur
Eskalations- und Abnahmewege bleiben über alle Phasen identisch
Das senkt die Schnittstellenverluste, die bei Projektketten mit wechselnden Dienstleistern typisch sind – besonders relevant bei NGFW-Migrationen, bei denen App-ID-Semantik und Decryption-Profile in Log-Archiven für Jahre nachwirken.
Mittelstands-orientierter Vertragsrahmen
Vertragsgestaltung, Ansprechpartner und Betriebssprache sind auf deutschsprachige Organisationen ausgerichtet. Keine Eskalation an internationale SOC-Tiers, keine Übersetzungsbeilagen zu kritischen Vertragsklauseln.
Im Alltag bedeutet das:
Vertrag, Leistungsbeschreibung, Policy-Change-Prozesse und SLAs auf Deutsch
Rechtsraum Deutschland, keine außereuropäischen Vertragsklauseln im Streitfall
Ansprechpartner mit Erfahrung in mittelständischen Security-Organisationsstrukturen
Security-Eskalationen erreichen verantwortliche Rollen ohne Zeitzonenverzug
Abstimmungen mit CISO, Geschäftsführung und Revision in gemeinsamer Sprache
Datenverarbeitung, Log-Speicherung und Incident-Forensik laufen in Deutschland, ohne Weitergabe an Offshore-Teams
Gegenüber globalen Security-Service-Modellen und internationalen Integrator-Ketten ist dieser Rahmen ein belegbares Abgrenzungsmerkmal – besonders für Organisationen mit KRITIS-, DSGVO- oder Revisionsanforderungen.
Kostenstruktur eines Palo-Alto-Exits
Ein NGFW-Wechsel wirkt auf drei Kostenebenen über den Lebenszyklus. Pauschale Einsparungen verspricht BEKOM nicht — ein strukturiertes Assessment ordnet die Ebenen gegen die heutige Ausgangslage und liefert eine belastbare Vergleichsgrundlage. Die tatsächliche Kostenwirkung hängt von Standortzahl, Modul-Profil, Panorama-Komplexität und Renewal-Terminen ab und wird pro Organisation ermittelt.
Bestandsseite – Palo Alto heute
Auf der Bestandsseite wirken nicht nur die Subscription-Listenpreise, sondern auch Panorama-Lizenzen, Hardware-Garantie und gebundenes Personal. Ein vollständiger Vergleich erfasst alle vier Treiber statt nur den sichtbaren Lizenz-Anteil.
Kostentreiber im laufenden Palo-Alto-Betrieb:
Subscription-Bundles pro Schutzmodul – Threat Prevention, WildFire, Advanced URL Filtering, DNS Security, GlobalProtect, IoT Security mit eigener Renewal-Logik und Bündel-Verschiebungen
Panorama-Lizenzen und Management-Server – zentrale Verwaltung wird mit Anzahl Geräten und Funktionsumfang lizenziert; bei Multi-Site-Topologie ein eigener Posten
Premium-Support und Hardware-Garantie – Premium Support, Partner Support, Hardware-Garantie-Verlängerung und Reservegeräte für die PA-Serie
Personalkapazität für Panorama-Pflege und Audit – gebundene Stunden für Policy-Pflege, Template-Hierarchien, App-ID-Tuning und Audit-Reporting an CISO und Revision
Im Assessment werden diese Treiber gegen den heutigen Bestand gerechnet und ergeben die Bestandsseite des Vergleichs.
Migrationsphase – einmalige Aufwände
Während der Migration entstehen einmalige Aufwände, die als abgegrenzte Pakete vereinbart werden. Der Vorteil: jede Phase hat eigenen Umfang und eigene Abnahme — die Investitions-Entscheidung bleibt zwischen den Phasen reversibel.
Einmalige Migrations-Aufwände:
Policy-Assessment mit App-ID-Telemetrie – Log-Analyse, Rule-Hit-Auswertung, Panorama-Template-Auflösung und GlobalProtect-Inventar als Grundlage für Konvertierungsaufwand
Pilot-Konvertierung mit Funktions-Benchmark – Aufbau der Zielappliance, Konvertierung eines repräsentativen Standort-Regelwerks, Funktions- und Performance-Benchmark gegen PAN-Baseline
Stufen-Rollout mit SIEM-Re-Integration – pro Stufe Cutover, Decryption-Zertifikatstausch, GlobalProtect-Ablösung, SIEM-Korrelationsregeln-Anpassung und Hypercare
Parallel-Subscription während der Übergangsphase – PA-Subscription läuft bis zum letzten Standort weiter; Doppel-Kosten werden im Stufen-Plan berücksichtigt
Die Anteile werden im Angebot getrennt ausgewiesen, sodass interne Budgetbegründungen und spätere Vergleiche sauber möglich bleiben.
Zielseite – laufender Open-Source-Betrieb
Auf der Zielseite verschieben sich die Treiber von Subscription-Lizenzen zu Plattform-Betrieb. Bei OPNsense oder pfSense entfällt der Lizenz-Anteil weitgehend; dafür entstehen Kosten für Plattform-Betrieb, optional kommerzieller Support und Threat-Intelligence-Feeds.
Kostenebenen im laufenden Betrieb:
Monatliche Plattform-Service-Pauschale – abhängig von Anzahl Standorten, HA-Topologie (CARP-Cluster, Multi-Site), SLA-Stufe und Service-Modell (Fully Managed oder Co-Managed)
Hardware aus Hersteller-Bezug oder Standard-x86 – Deciso-Appliances bei OPNsense, Netgate-Hardware bei pfSense oder Standard-x86; ohne Subscription-Reset bei Hardware-Tausch
Optional Business-Edition oder TAC-Support – Deciso Business Edition bei OPNsense, Netgate TAC bei pfSense, kommerzieller Support bei Check Point Quantum als Übergangs-Variante
Modular ergänzende Beratungs-Pakete – SOC-Anbindung, Threat-Hunting, Major-Upgrades und Compliance-Begleitung sind als getrennte Pakete buchbar, ohne in der monatlichen Pauschale zu wachsen
Pauschale Einsparungs-Versprechen vermeidet BEKOM bewusst — die belastbare Aussage entsteht erst aus dem Bestands-Vergleich des konkreten Falls.
Warum BEKOM bei Palo-Alto-Firewall-Exit statt Systemhaus oder Eigenbetrieb
BEKOM arbeitet bei Firewall-Exit-Projekten herstellerunabhängig mit Standard-Technologien wie OPNsense, pfSense oder IPFire – ohne Vendor-Lock-in in proprietäre Plattformen.
Die Migration wird durch einen festen Ansprechpartner koordiniert, der sowohl die bestehende Palo-Alto-Konfiguration als auch die Ziel-Architektur überblickt. Statt einzelne Firewall-Appliances zu verkaufen, dokumentiert BEKOM die neue Security-Architektur in einem Service-Design-Dokument mit definierten SLA für Verfügbarkeit und Reaktionszeiten. Deutsche Rechenzentren gewährleisten dabei, dass Management-Komponenten und zentrale Policy-Verwaltung datenschutzkonform in der DACH-Region verbleiben – besonders relevant bei regulierten Branchen mit Compliance-Anforderungen.
Häufige Fragen zum Palo-Alto-Firewall-Exit
Ist ein Palo-Alto-Exit für jede Organisation wirtschaftlich begründbar, oder lohnt er sich nicht immer?
Nein, nicht in jedem Fall. In Landschaften mit aktiv genutzter App-ID-Granularität, tiefer GlobalProtect-Integration und laufenden Prisma-Access-Planungen kann ein Verbleib mit Modul-Bereinigung wirtschaftlicher sein als ein Vollumstieg. Entscheidend ist das Abgleichen von Subscription-Kostenentwicklung, tatsächlich genutzter Funktionstiefe und Migrationsaufwand. Das Assessment liefert die Grundlage — das Ergebnis kann Vollmigration, Teil-Exit oder strukturierter Verbleib sein.
Wie gut lassen sich App-ID-basierte Regeln auf OPNsense oder Open-Source-Plattformen übertragen?
Nicht 1:1, aber in vielen Fällen ausreichend. App-ID-Regeln werden in OPNsense als Kombination aus Port-Rules, Domain-/FQDN-Aliases, Kategorien-Filter (via Zenarmor-Plugin oder Proxy-Kategorien) und IDS-Signaturen nachgebildet. Die Log-Analyse aus Phase 1 zeigt, welche App-IDs tatsächlich angesprochen werden — häufig nutzen Organisationen nur einen Bruchteil der Palo-Alto-Taxonomie, der sich gut auf die Zielplattform abbilden lässt.
Was geschieht mit GlobalProtect-Clients und VPN-Endgeräten während der Migration?
GlobalProtect wird nicht konvertiert, sondern durch einen neuen VPN-Stack ersetzt: IPsec IKEv2 mit EAP, WireGuard oder OpenVPN — je nach Client-Landschaft, Endgeräte-Profil und Zielplattform. Die Client-Rollout-Stufe wird parallel zum Perimeter-Rollout geplant, inklusive Kommunikation an Nutzer, neuer Konfigurationsprofile und Support-Vorbereitung. GlobalProtect-Gateway und -Portal werden erst nach vollständiger Umstellung aller Nutzer und Bestätigung der Funktionsfähigkeit abgeschaltet.
Wie läuft ein bestehender Palo-Alto-Wartungsvertrag während der Migration weiter?
Premium-Support und Subscription-Bundles gelten bis zum regulären Ablauf und werden bis zur Außerbetriebnahme weiter genutzt. Der Migrationsfahrplan wird typischerweise so gelegt, dass die Stilllegung vor der nächsten großen Subscription-Verlängerung abgeschlossen ist. Kündigung einzelner Module kann ggf. vorzeitig erfolgen, wenn der Vertrag Teil-Kündigung zulässt. Kommerzielle Feinheiten werden vor der ersten Rollout-Stufe vertraglich geklärt.
Kann Panorama-zentralisierte Verwaltung durch ein Open-Source-Äquivalent ersetzt werden?
Nur teilweise – und das ist eine bewusste Architektur-Entscheidung. OPNsense und pfSense lassen sich per API und Konfigurations-Automatisierung (Ansible, Terraform) zentral steuern, bieten aber keine Panorama-äquivalente UI. Für Landschaften mit vielen Standorten bedeutet das einen Wechsel vom GUI-zentrierten Betrieb zu einem konfigurations- oder Script-basierten Ansatz. Wer Panorama-Komfort weiter benötigt, ist mit Check Point Quantum Management strukturell näher dran.
Was geschieht mit WildFire-Sandbox-Anbindung und DNS Security?
Diese Module werden nicht 1:1 ersetzt, sondern durch funktionsäquivalente Bausteine abgelöst: Für Sandbox-Analyse stehen externe Sandbox-Dienste oder SOC-integrierte Lösungen zur Verfügung; DNS-Security wird über DNS-Filter-Dienste (z. B. DoH/DoT mit Allowlist-/Blocklist-Pflege) oder Threat-Intelligence-Feeds auf dem Paketfilter nachgebildet. Die Entscheidung hängt davon ab, wie intensiv diese Module aktiv sind – die Log-Analyse liefert die Grundlage.
Welche Performance-Erwartungen sind an die Zielplattform realistisch?
Palo-Alto-PA-Serien verwenden dedizierte ASICs für Paketverarbeitung und Decryption, OPNsense und pfSense laufen softwarebasiert auf x86-CPUs. Für typische Mittelstands-Durchsätze (bis mehrere Gbit/s mit aktivem IDS/IPS und TLS-Inspection) ist moderne x86-Hardware ausreichend, ein Dimensionierungs-Benchmark in Phase 2 liefert die belastbare Aussage. Bei sehr hohen Durchsätzen (10 Gbit/s+ mit voller Decryption) bleibt die ASIC-Plattform im Vorteil – dort ist Check Point Quantum die nähere Alternative.
Welche Risiken bestehen bei der Migration?
Typische Befunde: App-ID-Regeln müssen in Port-/Domain-Logik zerlegt werden und werden dabei transparenter für das Team; Decryption-Zertifikate brauchen neue Verteilung; IPS-Signatur-Coverage unterscheidet sich zwischen PAN Threat Prevention und Suricata oder Check Point IPS; SIEM-Korrelationsregeln müssen auf neue Log-Formate angepasst werden. Diese Risiken werden in der Pilotphase identifiziert, in Runbooks dokumentiert und im Rollout adressiert.
Was kostet das Palo-Alto-Exit-Assessment bei BEKOM?
Das Assessment ist ein eigenständiges Beratungsprojekt. Der Aufwand richtet sich nach Anzahl der PA-Standorte, Panorama-Hierarchie-Komplexität, Log-Volumen für die App-ID-Analyse und gewünschter Tiefe der Vergleichsanalyse. Dem Auftrag geht ein unverbindliches Strategiegespräch voraus, in dem Umfang und Abgrenzung definiert werden. Darauf basierend entsteht ein schriftliches Angebot mit Phasenlogik, Abnahmekriterien und pro Phase ausgewiesenen Leistungen.
Kann BEKOM den Betrieb der bestehenden Palo-Alto-Landschaft übernehmen?
Ja. Wenn das Assessment einen schrittweisen Exit oder zeitweisen Verbleib empfiehlt, kann BEKOM den Betrieb der PAN-Plattform als Managed Service übernehmen – mit dokumentiertem Change-Prozess, Patch-Management, Incident-Response und Reporting. Das ermöglicht einen ruhigen Migrationsverlauf ohne Stichtagsdruck. Eine spätere Teil- oder Vollablösung lässt sich aus diesem laufenden Managed-Service-Verhältnis heraus strukturiert vorbereiten.
Nächster Schritt: Palo-Alto-Exit-Evaluierung
Den Einstieg bildet ein Strategiegespräch zur aktuellen PAN-Landschaft, zu realistischen Zielplattformen und zur passenden Umsetzungsform. Das Gespräch ist unverbindlich und löst keine Folgeverpflichtung aus; ein schriftliches Angebot für das Assessment entsteht erst nach gemeinsamer Abgrenzung von Umfang und Zielbild.
Das Assessment verschafft Klarheit über den aktuellen Palo-Alto-Subscription-Umfang und erstellt eine Bestandsaufnahme der tatsächlich genutzten NGFW-Features. BEKOM liefert eine konkrete Architektur-Empfehlung für Open-Source-Alternativen wie OPNsense oder pfSense, einschließlich Migrations-Roadmap und Service-Design für den künftigen Betriebsumfang. Das Ergebnis ist ein dokumentierter Überblick über Kosten, Risiken und technische Machbarkeit des Firewall-Exit.
Strategiegespräch vereinbaren
Im Strategiegespräch klären BEKOM-Spezialisten mit CISO und Security-Team die Ausgangslage: Standort-Topologie, Panorama-Struktur, Subscription-Profil und Integrationsanforderungen. Das Ergebnis ist eine erste fachliche Einordnung – ergebnisoffen und ohne festgelegte Zielplattform.
Strukturiertes Assessment durchführen
Im Assessment entstehen Policy-Inventar mit App-ID-Nutzungsanalyse, Panorama-Template-Auflösung, GlobalProtect-Erhebung, Alternativen-Bewertung und dokumentiertes Zielbild. Die Entscheidungsvorlage enthält begründete Empfehlung, Risikoliste und einen Phasenplan für den Stufen-Rollout.
Pilot und Stufen-Rollout begleiten
Nach Freigabe begleitet BEKOM die Umsetzung: Pilot-Konvertierung mit Funktions-Benchmark, stufenweise Produktivmigration mit Parallelbetrieb und Rückfall-Optionen bis zur dokumentierten Übergabe. Die Beteiligungsform reicht von Beratung über Projektpartnerschaft bis zur vollständig übernommenen Migrationsdurchführung.