Best Practices
Policy-Drift-Erkennung: Nicht autorisierte Firewall-Änderungen aufspüren
Zwischen den Audits driften Firewall-Konfigurationen auseinander. Während eines Vorfalls werden Notfallregeln hinzugefügt und nie wieder entfernt. Netzwerkobjekte werden ohne Change-Ticket geändert. NAT-Regeln verändern sich im Zuge von Troubleshooting-Sitzungen. Bis zum nächsten Compliance-Assessment hat sich die Firewall-Konfiguration von dem entfernt, was einst genehmigt wurde – und niemand weiß mehr genau, wie oder wann. Die Policy-Drift-Erkennung deckt diese nicht autorisierten Änderungen auf, bevor es die Auditoren tun.
Dieser Leitfaden erklärt, was Policy Drift ist, warum sie für die Compliance entscheidend ist, wie das Baseline-Management funktioniert, welche 8 Drift-Typen FwChange erkennt, wie die Schweregrade klassifiziert werden und welche 3 Workflows zur Behandlung von Drift-Ereignissen zur Verfügung stehen.
Was ist Policy Drift?
Policy Drift ist die Abweichung zwischen der genehmigten (als Baseline festgehaltenen) Konfiguration einer Firewall und ihrer aktuell laufenden Konfiguration. In einer perfekten Welt durchläuft jede Änderung einen formellen Change-Management-Prozess – beantragt, geprüft, genehmigt, umgesetzt und dokumentiert. In der Realität geschehen Änderungen jedoch außerhalb des Prozesses: Notfallzugriffe während eines Vorfalls, ein schneller Fix in einem Wartungsfenster, der nie dokumentiert wurde, oder ein gut gemeinter Eingriff eines Technikers, der eine Regel direkt auf der Firewall ergänzt, anstatt den Workflow zu durchlaufen.
Jede dieser am Prozess vorbei vorgenommenen Änderungen erzeugt Drift. Einzeln betrachtet mögen sie unbedeutend sein. In ihrer Gesamtheit jedoch verwandeln sie die Firewall-Konfiguration über Monate oder Jahre in etwas, das nicht mehr dem entspricht, was geprüft und genehmigt wurde. Das ist zugleich ein Compliance-, ein Sicherheits- und ein operatives Problem.
Warum Drift für die Compliance entscheidend ist
Jedes wichtige Compliance-Rahmenwerk verlangt ein kontrolliertes Change Management für Netzwerksicherheitsgeräte. Wenn ein Auditor Ihre dokumentierte Änderungshistorie mit der tatsächlichen Firewall-Konfiguration abgleicht und Abweichungen feststellt, werden diese Abweichungen zu Audit-Befunden.
Drift und Compliance-Rahmenwerke
- PCI-DSS 4.0: Anforderung 1.2.7 schreibt eine Überprüfung der Konfigurationen mindestens alle 6 Monate vor. Drift zwischen den Überprüfungen ist ein unmittelbarer Befund.
- ISO 27001: Anhang A.12.1.2 verlangt Change-Management-Verfahren. Nicht autorisierte Änderungen verletzen diese Kontrolle.
- NIS2: Artikel 21 fordert angemessene Maßnahmen für die Behandlung von Sicherheitsvorfällen und die Aufrechterhaltung der Sicherheit. Unentdeckte Drift untergräbt beides.
- KRITIS: Die BSI-Anforderungen umfassen ein dokumentiertes Konfigurationsmanagement. Drift bedeutet undokumentierte Konfigurationsänderungen.
Den Auditor interessiert nicht, warum die Drift entstanden ist. Ihn interessiert, dass sie entstanden ist und dass Sie sie nicht entdeckt haben. Ein Drift-Erkennungssystem, das kontinuierlich läuft, belegt eine proaktive Governance – das Gegenteil davon, abzuwarten, bis ein Auditor Ihre Probleme findet. Mehr zur PCI-DSS-Firewall-Compliance und zu den KRITIS-Anforderungen finden Sie in unseren entsprechenden Leitfäden.
Baseline-Management
Die Drift-Erkennung beginnt mit einer Baseline: einer Momentaufnahme der genehmigten Firewall-Konfiguration zu einem bestimmten Zeitpunkt. Die Baseline erfasst den vollständigen Zustand der Firewall – Regeln, Objekte, NAT-Einträge und Systemkonfiguration – und kennzeichnet ihn als „bekannt guten“ Zustand.
Das Erstellen einer Baseline ist ein bewusster Akt. Sie prüfen die aktuelle Konfiguration, bestätigen, dass sie Ihrem genehmigten Zustand entspricht, und speichern sie. Von diesem Zeitpunkt an gilt jede Abweichung von der Baseline als Drift. Baselines sollten aktualisiert werden, nachdem genehmigte Änderungen Ihren Change-Management-Prozess durchlaufen haben, damit der Abgleich stets den aktuellsten genehmigten Zustand widerspiegelt.
8 Drift-Typen
FwChange erkennt 8 unterschiedliche Typen von Konfigurations-Drift und deckt damit das gesamte Spektrum an Änderungen ab, die auf einer Firewall auftreten können:
Regel hinzugefügt
In der aktuellen Konfiguration existiert eine neue Firewall-Regel, die in der Baseline nicht vorhanden war. Dabei kann es sich um eine Notfallregel, eine nicht autorisierte Ergänzung oder eine über einen parallelen Workflow hinzugefügte Regel handeln.
Regel entfernt
Eine Regel, die in der Baseline vorhanden war, ist nicht mehr vorhanden. Jemand hat sie gelöscht, ohne den Change-Prozess zu durchlaufen. Das kann ebenso gefährlich sein wie eine nicht autorisierte Ergänzung, wenn eine kritische Sicherheitsregel entfernt wurde.
Regel geändert
Eine Regel existiert sowohl in der Baseline als auch in der aktuellen Konfiguration, aber ihre Eigenschaften haben sich verändert – Quelle, Ziel, Dienst, Aktion oder andere Attribute wurden modifiziert.
Objekt hinzugefügt
Ein neues Netzwerkobjekt (Adressgruppe, Dienstgruppe) wurde angelegt. Objekte legen fest, worauf Regeln verweisen, daher können neue Objekte auf bevorstehende Regeländerungen hindeuten.
Objekt entfernt
Ein Netzwerkobjekt aus der Baseline wurde gelöscht. Falls Regeln noch darauf verweisen, kann dies zu Policy-Fehlern oder unbeabsichtigtem Datenverkehrsverhalten führen.
Objekt geändert
Ein bestehendes Netzwerkobjekt wurde verändert – Mitglieder wurden zu Adressgruppen hinzugefügt oder daraus entfernt, Dienstdefinitionen geändert. Das kann den Geltungsbereich einer Regel unbemerkt erweitern oder einschränken.
NAT geändert
NAT-Regeln (Network Address Translation) wurden hinzugefügt, entfernt oder geändert. NAT-Änderungen können Datenverkehr auf eine Weise umleiten, die Sicherheitsrichtlinien umgeht.
Konfiguration geändert
Die allgemeine Systemkonfiguration hat sich verändert – Logging-Einstellungen, Schnittstellenzuordnungen, Routing oder andere geräteweite Einstellungen, die die Sicherheitslage beeinflussen.
Klassifizierung der Schweregrade
Nicht jede Drift ist gleich dringend. FwChange klassifiziert Drift-Ereignisse anhand der Art der Änderung und ihrer potenziellen sicherheitsrelevanten Auswirkung in 5 Schweregrade:
- Kritisch: Änderungen mit direkter sicherheitsrelevanter Auswirkung – das Entfernen von Deny-Regeln, das Hinzufügen weitreichend permissiver Regeln, das Verändern von Zonengrenzen.
- Hoch: Erhebliche nicht autorisierte Änderungen – neue Regeln, die externen Zugriff erlauben, das Entfernen von Logging, NAT-Änderungen, die kritische Dienste betreffen.
- Mittel: Änderungen mit moderatem Risiko, die einer Prüfung bedürfen – Regeländerungen, Objektänderungen, die den Geltungsbereich von Regeln betreffen, Konfigurationsanpassungen.
- Niedrig: Änderungen mit geringem Risiko – kleinere Objektergänzungen, das Entfernen deaktivierter Regeln, kosmetische Änderungen.
- Info: Informative Änderungen – Aktualisierungen von Beschreibungen, Änderungen von Kommentaren, nicht sicherheitsrelevante Konfigurationsänderungen.
3 Workflows zur Behebung
Wird eine Drift erkannt, muss sie behoben werden. FwChange stellt für jedes Drift-Ereignis 3 Behebungs-Workflows bereit:
Genehmigen (Baseline aktualisieren)
Die Änderung war legitim, hat aber den normalen Prozess umgangen. Vielleicht handelte es sich um einen Notfall-Fix, der nachträglich dokumentiert werden muss. Das Genehmigen des Drift-Ereignisses aktualisiert die Baseline, sodass sie die Änderung enthält, und erstellt einen Nachweis, dass die Abweichung geprüft und akzeptiert wurde. Dies ist die häufigste Behebung für Änderungen, die im Rahmen der Reaktion auf einen Vorfall vorgenommen wurden.
Ignorieren
Die Drift wird zur Kenntnis genommen, erfordert aber keine Maßnahme und keine Aktualisierung der Baseline. Das ist angemessen für bekannte temporäre Zustände – ein laufendes Wartungsfenster, eine geplante Migration, die noch nicht abgeschlossen ist, oder eine Konfiguration, die ohnehin bald wieder angepasst wird. Das Drift-Ereignis wird als geprüft markiert, die Baseline bleibt jedoch unverändert.
Zurücksetzen
Die Änderung war nicht autorisiert und muss rückgängig gemacht werden. Das Zurücksetzen stellt die Firewall-Konfiguration so wieder her, dass sie der Baseline entspricht. Dies ist die angemessene Reaktion, wenn jemand eine nicht genehmigte Änderung vorgenommen hat, die über keinen Prozess autorisiert wurde. In der Praxis wird das Zurücksetzen sparsam eingesetzt, da zuvor sichergestellt werden muss, dass es keine aktiven Dienste beeinträchtigt.
Automatisierte Erkennung
Manuelle Drift-Prüfungen sind unpraktikabel. Bis Sie Konfigurationen manuell abgeglichen haben, sind die Informationen bereits veraltet. FwChange führt die Drift-Erkennung nach einem automatisierten Zeitplan aus – standardmäßig stündlich – mittels eines Cron-Jobs, der die aktuelle Firewall-Konfiguration mit der aktiven Baseline vergleicht.
Wird eine Drift erkannt, erstellt das System Drift-Ereignisse mit allen Details: was sich geändert hat, wann es erkannt wurde, die Klassifizierung des Schweregrads sowie die konkreten Unterschiede zwischen Baseline und aktuellem Zustand. Bei Ereignissen mit hohem und kritischem Schweregrad werden die Administratoren benachrichtigt, damit sie umgehend prüfen und beheben können.
Best Practices
- Erstellen Sie nach jedem genehmigten Änderungsfenster eine Baseline. Halten Sie die Baseline aktuell, damit Sie gegen den jüngsten genehmigten Zustand abgleichen und nicht gegen eine veraltete Momentaufnahme von vor Monaten.
- Prüfen Sie Drift-Ereignisse wöchentlich. Selbst Drift mit niedrigem Schweregrad summiert sich. Eine wöchentliche Prüfung verhindert, dass sich Drift zwischen den Audit-Zyklen aufstaut.
- Dokumentieren Sie Notfalländerungen nachträglich. Wenn Notfallregeln den normalen Prozess umgehen, nutzen Sie den Genehmigen-Workflow, um sie zu dokumentieren und in die Baseline zu übernehmen. Das Ziel ist ein vollständiger Nachweis, kein perfekter Prozess.
- Verfolgen Sie Drift-Kennzahlen im Zeitverlauf. Die Zahl der Drift-Ereignisse pro Firewall und Monat zeigt Ihnen, wie gut Ihr Change-Management-Prozess funktioniert. Steigende Drift deutet auf Lücken im Prozess hin; sinkende Drift auf dessen Akzeptanz.
- Verzahnen Sie die Drift-Erkennung mit dem Change Management. Die Drift-Erkennung ist am wirksamsten, wenn sie Teil Ihres gesamten Governance-Rahmens ist und nicht ein isoliertes Werkzeug. Jedes Drift-Ereignis sollte auf die Frage zurückführen: „Warum hat diese Änderung den Prozess nicht durchlaufen?“
Policy Drift ist unvermeidlich. Nicht autorisierte Änderungen werden vorkommen – bei Vorfällen, bei Wartungsarbeiten und durch menschliche Fehler. Die Frage ist nicht, ob Drift auftritt, sondern ob Sie sie erkennen. Eine automatisierte Drift-Erkennung mit Baseline-Management, Schweregrad-Klassifizierung und Behebungs-Workflows verschafft Ihnen die Sichtbarkeit und Kontrolle, die Auditoren erwarten und die der Sicherheitsbetrieb erfordert.
