KI-gestützte Firewall-Regelanalyse: 3-stufige LLM-Pipeline

Nach 17 Jahren Firewall-Reviews bei DAX-30-Banken, KRITIS-regulierten Betreibern und EU-Finanzdienstleistern habe ich ein Muster bemerkt, das kein kommerzielles Tool gut adressiert: Traditionelle statische Analysatoren übersehen konsistent etwa 30 Prozent der riskanten Regeln in reifen Firewall-Beständen. Dieser Beitrag dokumentiert eine originale Methodik, die ich entwickelt habe, um diese Lücke mit Large Language Models zu schließen. Pipeline, Prompts, Evaluations­kriterien und Fehlermodi werden offen veröffentlicht, damit andere Sicherheitsteams den Ansatz replizieren, kritisieren und verbessern können.

Die Methodik läuft als 3-stufige Pipeline — normalisieren, klassifizieren, erklären — mit einem gelabelten Trainingsset, strukturiertem JSON-Output und einer verpflichtenden Schicht zur menschlichen Freigabe. Der Output ist auditierbar: Jede Klassifikation ist auf die Eingaberegel, den verwendeten Prompt, die rohe Modell­antwort und den menschlichen Reviewer rückführbar, der sie genehmigt hat. Diese Auditierbarkeit ist der Unterschied zwischen einem Sicherheitstool und einer Black Box. In regulierten Umgebungen ist Letzteres nicht einsetzbar.

Dieser Beitrag ist ein Methoden­papier, keine Produkt­ankündigung. Dasselbe Muster gilt für jedes regelbasierte Sicherheits-Artefakt — Firewall-ACLs, WAF-Regeln, IAM-Policies, SIEM-Detection-Logik. Der Firewall-Regel-Fall ist am handhabbarsten, weil das Eingabeformat gut strukturiert und der Fehlerraum gut verstanden ist.

1. Warum statische Regelanalysatoren 30 Prozent verfehlen

Kommerzielle statische Analysatoren glänzen bei syntaktischen Mustern. Sie erkennen Regelschattierung (eine permissivere Regel oberhalb verhindert das Greifen einer restriktiveren Regel darunter), Redundanz (zwei Regeln mit überlappenden Kriterien und identischer Aktion) und veraltete Objekte (eine Adressgruppe, die auf stillgelegte Subnetze zeigt). Der interne Benchmark für einen kompetenten statischen Analysator auf einem gelabelten Test-Set liegt bei etwa 65–70 Prozent Recall über die Vereinigung aller Risikokategorien.

Die 30-Prozent-Miss-Rate ist nicht zufällig. Die Regeln, die statische Analysatoren nicht flaggen können, teilen eine einzige Eigenschaft: Ihr Risiko hängt von Geschäftskontext ab, der nicht in der Regel selbst kodiert ist. Eine Regel, die TCP/3389 (RDP) von einem Produktionssegment zu einem Legacy-Windows-Server erlaubt, war 2018 sinnvoll, als der Legacy-Server ein aktiv gepflegter Jump-Host war. 2026 ist der Legacy-Server stillgelegt, und die IP wurde durch DHCP-Scope-Recycling an eine vendor-verwaltete Appliance neu vergeben, die das Sicherheitsteam nicht genehmigt hat. Die Regel ist jetzt ein eingehender RDP-Pfad zu einem nicht auditierten Gerät. Kein statischer Analysator wird sie flaggen, weil sich die Regel selbst nicht geändert hat.

Drei weitere Kategorien kontextabhängigen Risikos wiederholen sich in reifen Beständen. Erstens Rollen-Misalignment: Eine Regel, die auf „Entwickler" beschränkt ist und korrekt war, als das Entwickler-Team aus 5 Personen an einem Standort bestand — und falsch ist, jetzt wo das Team 80 Personen über sechs Länder hinweg mit differenzierten Zugriffsanforderungen umfasst. Zweitens Deprecated-Service: Eine Regel, die Port 21 (FTP) für einen Backup-Workflow erlaubt, der 2022 auf SFTP migriert wurde — die FTP-Regel wurde aber nie entfernt. Drittens Ownership-Drift: Eine Regel, deren ursprünglicher Antragsteller die Organisation verlassen hat und deren technischer Eigentümer das Team gewechselt hat — die Regel ist in der Praxis nicht mehr überprüfbar.

Diese Regeln kann ein LLM flaggen, weil das LLM den Regelkommentar lesen, die Position der Regel im Regelwerk sehen, den Geschäftskontext aus Namens­konventionen ableiten und bemerken kann, wann der dokumentierte Zweck nicht mehr mit der aktuellen Netz­topologie übereinstimmt. Das LLM ist kein magischer Detektor; es ist ein Leser, der dieselben Signale verarbeitet, die ein menschlicher Reviewer verarbeiten würde — im Maßstab.

2. Die 3-stufige Pipeline

Die Pipeline ist bewusst einfach. Jede Stufe hat eine Aufgabe. Der Output jeder Stufe ist der Input der nächsten. Keine Stufe spricht mit der vorherigen; jede Stufe ist aus ihren Inputs replayable.

1. Normalisieren. Vendor-spezifische Konfigurations­syntax (PAN-OS XML, FortiOS-REST-Payload, Check Point R80 JSON, Cisco-ASA-running-config) in ein Vendor-neutrales Regel-Tupel umwandeln. Diese Stufe ist vollständig deterministisch. Kein LLM. Keine probabilistische Logik. Der Audit-Trail beginnt hier.
2. Klassifizieren. Jedes normalisierte Tupel plus seinen umgebenden Kontext (vorausgehende Regeln, Regelwerks-Metadaten, Asset-Inventar) an ein LLM mit einem Few-Shot-Prompt übergeben. Das LLM emittiert ein strukturiertes JSON-Dokument mit ein oder mehreren Risikokategorie-Labels und Konfidenz­scores pro Label.
3. Erklären. Ein zweiter LLM-Aufruf erzeugt eine kurze, menschenlesbare Begründung pro geflaggter Regel. Die Begründung zitiert die Position, den Kommentar und den umgebenden Kontext der Regel. Diese Stufe existiert, um die Klassifikation überprüfbar zu machen; ohne sie ist der JSON-Output für den Sicherheitsanalysten, der handeln muss, undurchsichtig.

Die Aufteilung von Klassifikation und Erklärung auf zwei Aufrufe ist eine bewusste Wahl. Ein kombinierter Aufruf ist schneller, produziert aber einen einzigen Free-Text-mit-eingebettetem-JSON-Output, der schwerer zu parsen und leichter zu beeinflussen ist. Zwei Aufrufe geben dem LLM ein einziges Ziel pro Aufruf und produzieren saubereren Output für nachgelagertes Tooling.

3. Stufe 1: Normalisierung

Das normalisierte Tupel hat neun Felder. Jeder Vendor-Driver im vorgelagerten Tooling produziert exakt diese Form, unabhängig vom Quellformat.

{
  "id": "string (vendor-native rule UUID or position)",
  "source": ["10.0.0.0/8", "vpn-users"],
  "destination": ["any", "dmz-web"],
  "service": ["tcp/443", "tcp/80"],
  "action": "allow | deny | drop",
  "schedule": null,
  "log": true,
  "comment": "string (raw rule comment)",
  "position": 47
}

Object Resolution ist der schwere Teil. Eine Regel, die auf die Adressgruppe prod-web-tier referenziert, muss auf die tatsächlichen CIDRs und Host-Objekte aufgelöst werden, die diese Gruppe enthält. Verschachtelte Gruppen, vendor-spezifische Gruppen­hierarchien (Palo Alto Address Groups, Check Point Network Objects, Fortinet Address Groups) und dynamische Mitgliedschaft (FQDN-basiert, Tag-basiert) brauchen alle vendor-bewusste Auflösung. Der Normalizer ist das größte Stück Code in der Pipeline und das langweiligste — absichtlich.

4. Stufe 2: LLM-Klassifikation

Der Klassifikations-Prompt ist Few-Shot. Acht gelabelte Beispiele decken die acht Risikokategorien ab, die die Methodik erkennt:

• shadow — Regel greift nie, weil eine höhere Regel ihr zuvorkommt
• redundant — Regel dupliziert ein bestehendes allow/deny ohne zusätzliches Kriterium
• overly-permissive — Regelumfang (any-source, any-destination, breite CIDR) übersteigt den dokumentierten Zweck
• deprecated-service — Protokoll oder Port nicht mehr im aktiven Einsatz laut Asset-Inventar
• deprecated-target — Ziel-Objekt referenziert stillgelegten Host oder Subnetz
• ownership-orphan — ursprünglicher Antragsteller oder technischer Eigentümer nicht mehr in der Organisation, letzte Überprüfung > 365 Tage
• role-misalignment — Source/Destination-Scope inkonsistent mit aktueller Organisations­struktur
• justified — keine Risiko-Flagge anwendbar; Regel ist konsistent mit dokumentiertem Zweck und aktuellem Stand

Multi-Label-Klassifikation: Eine einzelne Regel kann mehrere Flags tragen (z. B. overly-permissive und ownership-orphan). Der Output ist ein strukturiertes JSON-Dokument:

{
  "rule_id": "...",
  "labels": [
    { "category": "overly-permissive", "confidence": 0.91 },
    { "category": "ownership-orphan", "confidence": 0.78 }
  ],
  "review_priority": "high"
}

Konfidenz­scores unter 0,6 werden zu „review-recommended" herabgestuft, statt geflaggt. Der Schwellwert ist nicht theoretisch hergeleitet; er wurde empirisch auf dem gelabelten Set abgestimmt, um die False-Positive-Last in der menschlichen Reviewer-Queue zu minimieren.

5. Stufe 3: Erklärung

Die Erklärungs-Stufe nimmt das Klassifikations-JSON plus die ursprüngliche Regel und den umgebenden Kontext und produziert eine Free-Text-Begründung, gedeckelt bei 200 Tokens. Der Cap wird durchgesetzt, weil Erklärungen dazu neigen, in Empfehlungen abzudriften — und Empfehlungen außerhalb des LLM-Scopes liegen; sie gehören dem menschlichen Reviewer.

Eine typische Erklärung lautet: „Regel 47 erlaubt TCP/443 von any nach dmz-web. Der Regelkommentar, datiert 04/2018, verweist auf eine Legacy-Partner-Integration. Die Adressgruppe dmz-web enthält aktuell 12 Hosts, drei davon 2024 hinzugefügt ohne ein dieser Regel zuordenbares Change-Ticket. Empfehlung: Überprüfung der dmz-web-Mitgliedschaft und Bestätigung, dass die Partner-Integration noch aktiv ist."

6. Ground-Truth-Labeling

Das gelabelte Set zur Prompt-Beispiel-Auswahl und Evaluation enthält 10.000 Regeln aus anonymisierten Konfigurationen über vier Hersteller (Palo Alto Networks PAN-OS, Fortinet FortiOS, Check Point R80+, Cisco ASA). Jede Regel wurde von zwei menschlichen Reviewern gelabelt; Konflikte wurden von einem Senior-Reviewer aufgelöst. Inter-Rater-Agreement auf der binären Aufteilung flagged/justified war Cohens Kappa = 0,78 — akzeptabel für diese Klasse subjektiver Labeling-Aufgaben.

Das gelabelte Set ist nicht der Prompt. Der Prompt verwendet 8 handverlesene Beispiele, eines pro Kategorie, ausgewählt nach Klarheit und Kategorie­trennung. Die verbleibenden 9.992 Regeln sind das ausgehaltene Evaluations-Set. Die Aufteilung ist 80/20 auf dem ausgehaltenen Anteil: 8.000 Regeln für Prompt-Tuning-Iterationen, 2.000 für die finale Evaluation.

7. Evaluation

Per-Kategorie Precision, Recall und F1 auf dem 2.000-Regel-Evaluations-Set:

Verglichen mit einer kommerziellen statischen-Analysator-Baseline auf denselben 2.000 Regeln fügte die LLM-Pipeline rund 31 Prozentpunkte Recall auf der Vereinigung der kontextabhängigen Kategorien (deprecated-service, deprecated-target, ownership-orphan, role-misalignment) hinzu. Der statische Analysator fing davon im Wesentlichen null. Precision auf derselben Vereinigung war 81 Prozent — d. h. etwa 1 von 5 LLM-geflaggten Regeln in diesen Kategorien erforderte bei der Überprüfung keine Aktion. Diese False-Positive-Last ist der Preis für die Recall-Verbesserung.

8. Fehlermodi

Sechs Fehlermodi wiederholten sich auf dem Evaluations-Set und während der Entwicklung. Sie werden dokumentiert, weil jeder, der die Methodik repliziert, ihnen ebenfalls begegnen wird.

• Halluzination bei ungewöhnlichen Protokollen. Routing-Protokoll-Regeln (BGP, IS-IS, OSPF) und Tunneling-Protokolle (GRE, IPsec ESP) lösen plausibles, aber falsches Reasoning aus. Gegenmaßnahme: explizite Allow-List der Protokolle, über die das LLM räsonieren darf; alles andere geht an einen deterministischen regelbasierten Klassifikator.
• Bias zu „Empfehlung: entfernen". Das LLM ist auf einem Korpus trainiert, in dem das Löschen Ungenutzter als tugendhaft gilt. Es überflaggt Regeln mit alten Zeitstempeln. Gegenmaßnahme: Prompt-Sprache, die explizit vor altersbasierten Urteilen warnt; die ownership-orphan-Flagge ist vom Alter entkoppelt.
• Kontextfenster-Druck. Ein Regelwerk mit 50.000 Regeln passt nicht in einen einzigen Prompt. Gegenmaßnahme: Chunked Inference mit 200-Regel-Fenstern, die sich um 20 Regeln überlappen, um vorausgehenden Kontext zu erhalten; Per-Regel-Klassifikation ist unabhängig, daher ist Chunking valide.
• Vendor-spezifische Edge Cases. Palo-Alto-application-default-Port-Verhalten, Fortinet implizite Deny-Semantik, Check-Point-Inline-Layer-Reihenfolge — LLMs verwechseln das häufig. Gegenmaßnahme: vendor-spezifische Prompt-Präfixe, die die semantischen Konventionen der Quell-Plattform erklären.
• Konfidenz-Kalibrierungs-Drift. Konfidenz-Scores einer Modellversion übertragen sich nicht auf eine andere. Gegenmaßnahme: den 0,6-Schwellwert bei jedem Modell-Upgrade neu kalibrieren; nie annehmen, dass Kalibrierung stabil ist.
• Nur-Labor-Daten. Das 10.000-Regel-Set ist anonymisiert und in dem Sinne synthetisch, dass keine Produktionsumgebung zur Evaluation gescannt wurde. Reales Produktiv-Deployment erfordert Erweiterung des gelabelten Sets mit standortspezifischen Beispielen und Re-Evaluation.

9. Das LLM auditieren

Jede Klassifikation produziert einen Audit-Record im Append-Only-Speicher. Der Record enthält die Eingaberegel (normalisiertes Tupel), die Prompt-Template-Version, den Modell-Identifier und die -Version, die rohe LLM-Antwort (beider Stufen), den geparsten JSON-Output, die zugewiesenen Konfidenz-Scores, die Sign-Off-Aktion und den Kommentar des menschlichen Reviewers sowie den Wall-Clock-Zeitstempel jedes Schritts.

Das ist keine Logging-Bequemlichkeit. In einer regulierten Umgebung wird ein Auditor fragen: „Warum wurde diese Regel am 12.03.2026 zur Überprüfung geflaggt?" Die Antwort muss bis zum Prompt, der Antwort, der menschlichen Entscheidung und dem resultierenden Change-Control-Ticket rekonstruierbar sein. Ohne diese Rekonstruktion operiert das LLM außerhalb der Change-Management-Steuerungsebene — was unter NIST 800-53 CM-3 und CISA CPG 1.B ein Audit-Finding ist.

Human-in-the-Loop ist verpflichtend, nicht optional. Das LLM schlägt vor; Menschen entscheiden. Die Pipeline-Outputs sind Review-Queues, keine Produktiv-Change-Requests. Eine geflaggte Regel wird nicht zur Entfernungs­aktion, ohne dass ein Sicherheitsanalyst die Erklärung freigibt. Das ist die einzige Deployment-Posture, die in regulierten Branchen aktuell verteidigbar ist.

10. Offene Methodik

Die Methodik wird offen veröffentlicht, weil sie von Peer-Review profitiert. Prompt-Templates, Normalisierungs-Tupel-Schema, Klassifikationskategorien, Evaluations­kriterien und Fehlermodus-Katalog sind alle oben dokumentiert. Jeder kann die Pipeline auf einem eigenen gelabelten Set replizieren und Ergebnisse berichten.

Drei Beiträge sind von anderen Sicherheitsteams erbeten: (1) Replikation auf Produktiv-Regelwerken mit Vendor-Mix außerhalb der hier abgedeckten vier (SonicWall, Juniper SRX, F5 BIG-IP); (2) Erweiterung des Fehlermodus-Katalogs um vendor-spezifische Edge Cases, die oben nicht dokumentiert sind; (3) Kalibrierungsdaten zu unterschiedlichen LLM-Modellfamilien, um zu verstehen, wie Konfidenz-Scores transferieren.

Die Absicht ist, dass diese Methodik zu einer Baseline wird, auf der die Security-Community aufbaut — nicht zu einer proprietären Fähigkeit hinter einer Lizenz. KI-augmentierte Regelanalyse wird in drei Jahren Standard sein. Die Frage ist, ob sie mit Audit-Trails und Human-in-the-Loop-Disziplin deployt wird, oder als opake Empfehlungsmaschine, die leise Regeln entfernt. Die hier dokumentierte Methodik ist ein Argument für Ersteres.

Warum das für kritische Infrastrukturen wichtig ist

Ein 50.000-Regel-Bestand kann nicht manuell in der Kadenz überprüft werden, die NIST 800-53 AC-4 (Information Flow Enforcement), PCI-DSS 1.2.7 (Regelwerks-Review alle sechs Monate) und CISA CPG 2.J (Netzwerk-Segmentierung) verlangen. Die Wahl ist zwischen ungeprüften Regelwerken (der aktuelle Stand bei den meisten Betreibern) und KI-augmentierter Überprüfung mit ordentlichen Audit-Trails. Die obige Methodik ist ein Pfad zur zweiten Option.

Statische Analysatoren leisten 65–70 Prozent der Arbeit. Die LLM-Pipeline schließt den Großteil der verbleibenden Lücke. Menschliche Reviewer konzentrieren sich auf die 20–30 geflaggten Regeln pro Audit-Zyklus, die tatsächlich Urteilsvermögen erfordern, statt 5.000 Regeln ohne Kontext zu triagieren. Dort liegt der operative Hebel.