Fachbeitrag
Die KI Ihres Firewall-Herstellers bewertet ihre eigenen Änderungen. Deshalb nutzt sie im Alltag kaum jemand
Alle drei Leader im Gartner Magic Quadrant 2026 für Hybrid Mesh Firewall verkaufen inzwischen KI, die Firewall-Regeln schreibt oder eine Regeländerung vor dem Commit prüft. Trotzdem stellt Gartner fest, dass Kunden KI-gestützte Orchestrierung und LLM-Assistenten für die tägliche Firewall-Administration noch nicht voll nutzen, so die Zusammenfassung des Berichts bei Redmond Channel Partner. Unsere Lesart: Das ist kein Kompetenzproblem. Die Auswirkungsanalyse ist in die Management-Konsole des Herstellers gewandert. Die Plattform, die geändert wird, bewertet damit ihre eigene Änderung, und ein Change Advisory Board hat gute Gründe, diese Bewertung allein nicht zu akzeptieren.
Der Bericht erschien am 7. September 2026. Fortinet, Palo Alto Networks und Check Point waren die einzigen drei Leader, Cisco der einzige Visionary. Ein Jahr zuvor, in der ersten Ausgabe, hatte Gartner geschrieben, der größte Effekt von KI werde in der Automatisierung täglicher Firewall-Aufgaben wie Änderungsmanagement und routinemäßiger Richtlinienbewertung liegen, wie BankInfoSecurity berichtete. Zwölf Monate später gibt es die Funktionen. Die tägliche Nutzung hinkt hinterher.
Was die Leader für Regeländerungen tatsächlich ausliefern
Jeder der drei Leader, und Cisco aus dem Visionary-Feld, hat inzwischen eine KI- oder Analysefunktion direkt im Änderungspfad. Die Formulierungen in der eigenen Dokumentation ähneln sich stark: Das Werkzeug nimmt eine Absicht entgegen, erzeugt oder prüft eine Regel und sagt, was die Änderung bewirkt. Die Tabelle zeigt, was die Hersteller selbst schreiben, im englischen Original.
| Hersteller (Position im MQ 2026) | Funktion | Was der Hersteller dazu schreibt |
|---|---|---|
| Fortinet (Leader) | FortiAI-Assist in FortiManager | „Translates operational and security intent into policy changes“ und „validates scripts before deployment“ |
| Palo Alto Networks (Leader) | Policy Analyzer in Strata Cloud Manager | Pre-Change-Analyse, um „the impact of a new rule“ gegen das bestehende Regelwerk zu bewerten |
| Check Point (Leader) | Agentic Network Security Orchestration | „Translates intent into policy, delivering one-click Zero Trust posture tightening“ |
| Cisco (Visionary) | Policy Change Impact Analyzer in AgenticOps | Analysiert anstehende Regeländerungen „and assesses potential traffic impacts“; veröffentlicht am 17. September 2026 |
Fortinet plant laut SDxCentral und Redmond Channel Partner in den nächsten zwölf Monaten ein einheitliches Model-Context-Protocol-Framework (MCP) für agentenbasierte Automatisierung. Redmond Channel Partner berichtet außerdem, dass alle 12 von Gartner bewerteten Hersteller einen LLM-Chat-Assistenten anbieten, mit sehr unterschiedlichem Reifegrad. Regel schreiben und Regel bewerten wachsen in einer Konsole zusammen.
Die Auswirkungsanalyse war früher Aufgabe eines Dritten
Die Auswirkungsanalyse einer Firewall-Änderung beantwortet vor dem Go-live eine Frage: Welchen Verkehr erlaubt, blockiert oder verdeckt diese Regel, und passt das zum Antrag? Viele große Umgebungen haben diese Frage jahrelang mit einem Werkzeug beantwortet, das nicht vom Firewall-Hersteller stammte. Policy-Management-Suiten von Drittanbietern wie Tufin, AlgoSec und FireMon haben ihr Geschäft darauf gebaut, das Regelwerk jedes Herstellers zu lesen und eine geplante Änderung dagegen zu bewerten. Es ging dabei nie nur um Multi-Vendor-Abdeckung. Es ging darum, dass die Bewertung von außerhalb der Plattform kam, die geändert wurde.
Diese Funktion haben die Hersteller jetzt übernommen. Der Policy Analyzer von Palo Alto prüft eine neue Regel vor dem Commit auf Shadows, Redundanzen und Generalisierungen. Ciscos Analyzer betrachtet anstehende Änderungen über mehrere Geräte hinweg. Fortinets Assistent schreibt die Änderung und validiert sie. In jedem Fall schreibt oder empfängt dieselbe Plattform desselben Unternehmens die Regel, führt die Prüfung durch und meldet das Ergebnis. Niemand in dieser Schleife hat ein Interesse, das von dem der Plattform abweicht.
Wer sollte die Auswirkungen einer Firewall-Änderung bewerten?
Die Auswirkungen einer Firewall-Änderung sollte jemand bewerten, der die Änderung nicht vorgenommen hat und dem die betroffene Plattform nicht gehört. Das ist gewöhnliches Kontrolldesign. Die Kontrolle CM-4 in NIST SP 800-53 verlangt, Änderungen am System vor der Umsetzung auf mögliche Sicherheits- und Datenschutzauswirkungen zu analysieren, und weist diese Arbeit Personal mit Sicherheits- oder Datenschutzverantwortung zu. Kontrolle AC-5 im selben Katalog fordert Funktionstrennung, laut Erläuterung durch Aufteilung von Funktionen auf verschiedene Personen oder Rollen.
Diese Kontrollen wurden für Menschen geschrieben. Wer einen Firewall-Antrag stellt, genehmigt ihn nicht selbst, und wer ihn umsetzt, zeichnet nicht die Verifikation ab. Für Werkzeuge hat niemand die entsprechende Regel formuliert, weil bis vor Kurzem das Werkzeug, das eine Änderung bewertete, selten dasselbe war, das sie vornahm. Wenn die KI des Herstellers die Regel aus Ihrer Absicht formuliert und der Analyzer desselben Herstellers anschließend bestätigt, dass die Regel Ihrer Absicht entspricht, ist aus dem Vier-Augen-Prinzip stillschweigend ein Zwei-Augen-Prinzip geworden, und beide Augen gehören demselben Unternehmen.
Das ist eine andere Frage als in unserem früheren Beitrag über KI-Agenten mit Schreibzugriff auf Firewall-Richtlinien, der fragte, wer eine von einem Agenten vorgeschlagene Änderung abzeichnet. Hier liegt die Frage einen Schritt davor: Wessen Analyse liest die Person, die abzeichnet?
Warum nutzen Kunden die KI nicht, die sie bereits gekauft haben?
Unserer Einschätzung nach setzen Kunden Hersteller-KI vor allem deshalb nicht in der täglichen Firewall-Administration ein, weil ein Änderungsprozess ihr Ergebnis nicht als unabhängigen Nachweis akzeptieren kann. Laut der Zusammenfassung bei Redmond Channel Partner begrenzt die geringe Nutzung die Wirkung auf die Richtlinienoptimierung. Die übliche Erklärung lautet, den Teams fehle Know-how oder Vertrauen. Wir halten eine prozedurale Erklärung für genauer.
- Das Change Advisory Board verlangt eine Auswirkungsbewertung, auf die es sich verlassen kann. Eine vom Hersteller erzeugte Bewertung einer vom Hersteller erzeugten Regel ist eine Meinung, nicht zwei. Boards, die schon ein Audit hinter sich haben, kennen den Unterschied.
- Der Nachweis muss den Hersteller überdauern. Liegt die Auswirkungsanalyse nur im Cloud-Manager des Herstellers, endet der Nachweis mit dem Abonnement. Das zählt bei der nächsten Migration, und es zählt, wenn ein Änderungsdatensatz zum rechtlichen Beweismittel wird.
- Gemischte Umgebungen brechen das Modell. Jeder Analyzer ist auf das eigene Regelwerk ausgelegt. Ein Pfad über zwei Hersteller bekommt zwei Teilurteile und kein gemeinsames, eine Lücke, die jede Multi-Vendor-Umgebung kennt.
Damit ist nicht gesagt, dass die Werkzeuge der Hersteller falsch rechnen. Die Shadow- und Redundanzprüfungen von Palo Alto gehören zur selben Analyseklasse, die unsere Methodik zur Regelanalyse beschreibt, und sie sind nützlich. Das Problem ist ihre Stelle in der Genehmigungskette.
Wo Hersteller-KI in den Änderungsprozess gehört
Hersteller-KI passt gut an den Anfang einer Firewall-Änderung und schlecht an ihr Ende. Eine Regel aus einem Ticket entwerfen, ein Duplikat erkennen, bevor jemand einen Antrag stellt, Shadows in einem jahrelang unberührten Regelwerk aufräumen: Das alles ist Vorbereitung, und Vorbereitung braucht keine Unabhängigkeit. Die Freigabe braucht sie.
| Schritt der Änderung | Hersteller-KI passt | Braucht unabhängige Prüfung |
|---|---|---|
| Antrag in einen Regelentwurf übersetzen | Ja | Nein |
| Duplikate und Shadows vor dem Einreichen finden | Ja | Nein |
| Auswirkungsbewertung für das Change Advisory Board | Nur als Zuarbeit | Ja |
| Verifikation nach der Änderung und Rezertifizierung | Nur als Zuarbeit | Ja |
Praktisch heißt das: drei Entscheidungen schriftlich festhalten, bevor jemand die Funktionen einschaltet. Erstens legt die Änderungsrichtlinie fest, welche Bewertungen aus einer Quelle kommen müssen, die der Hersteller nicht kontrolliert, sei es ein zweites Werkzeug, ein anderes Team oder beides. Zweitens wird die Analyse des Herstellers in den eigenen Änderungsdatensatz exportiert, damit der Nachweis Ihnen gehört und den Vertrag überlebt. Drittens werden KI-entworfene Regeln bei der Rezertifizierung genauso behandelt wie von Menschen entworfene. Eine Regel, an deren Antrag sich niemand erinnert, kann auch niemand begründen.
Was das für die nächste Firewall-Entscheidung bedeutet
Für Entscheider ist die brauchbare Schlussfolgerung enger als „Hersteller-KI ist nicht so weit“. Hersteller-KI kann Arbeit erledigen. Für Zusicherung ist sie falsch platziert, und ihr Kauf ersetzt die unabhängige Prüfung nicht. Die Unabhängigkeit, die Policy-Werkzeuge von Drittanbietern früher automatisch mitbrachten, muss heute bewusst eingeplant werden. Aus Hunderten Migrationen wissen wir: Die Änderungen, die schiefgingen, waren selten die ungeprüften. Es waren die, die von denselben Leuten mit denselben Annahmen geprüft wurden, die sie auch geschrieben hatten.
Das betrifft direkt die Beschaffung. Eine Firewall-Ausschreibung, etwa ein ASA-Ersatz, sollte jeden Bieter fragen, wie sich die Auswirkungsbewertungen seiner KI exportieren, außerhalb seiner Konsole prüfen und mit etwas abgleichen lassen, das ihm nicht gehört. Ein Hersteller, der darauf keine Antwort hat, zeigt Ihnen damit, wo seine KI für Ihr Change Advisory Board aufhört, nützlich zu sein.
Warum das zählt
Gartner hat vor einem Jahr vorhergesagt, dass Änderungsmanagement der Bereich sein werde, in dem KI im Firewall-Betrieb am meisten bewirkt. Die Hersteller haben die Funktionen geliefert, und die Kunden nutzen sie im Alltag noch nicht voll. Das als Zögern zu lesen, verfehlt den Punkt. Die Werkzeuge sind genau an der einen Stelle angekommen, von der ein Änderungsprozess seine Zusicherung nicht beziehen kann: auf der Plattform, die geändert wird. Funktionstrennung galt schon immer für Menschen. Jetzt muss sie auch für Werkzeuge gelten, und wer diese Regel zuerst aufschreibt, kann die KI auch einsetzen.
Könnte Ihr Change Advisory Board zeigen, wer die Auswirkungen der Firewall-Änderungen des letzten Monats bewertet hat und wem dieses Werkzeug gehört? Der kostenlose NIS2-Readiness-Check geht die Nachweise durch, die ein Firewall-Änderungsprozess erbringen muss.
Über FwChange
FwChange ist eine Methodik für Firewall-Änderungsmanagement

