Leitfäden
Firewall-Änderungsbericht: Eine Vorlage für Prüfer und Management
Ein Firewall-Änderungsbericht besteht aus zwei Ebenen. Die erste ist der Änderungsdatensatz: ein Eintrag pro Änderung, der festhält, wer sie beantragt hat, warum, welche Regel auf welchem Gerät geändert wurde, wer sie wann freigegeben hat und ob die Verifikation bestanden ist. Die zweite ist der periodische Bericht, der diese Datensätze zu wenigen Kennzahlen für Management und Prüfer verdichtet. Dieser Beitrag liefert für beide eine Vorlage und ordnet jeden Teil den Anforderungen aus PCI DSS v4.0.1, ISO/IEC 27001:2022 und NIS2 zu.
Wie der Änderungsprozess selbst abläuft (Antrag, Prüfung, Freigabe, Umsetzung), beschreibt unser Leitfaden zum Firewall-Change-Management. Hier geht es um das, was dieser Prozess hinterlassen muss: das Dokument, das Sie übergeben, wenn Prüfer, CISO oder Geschäftsführung nach „dem Firewall-Änderungsbericht“ fragen.
Was gehört in einen Firewall-Änderungsdatensatz?
Ein Firewall-Änderungsdatensatz sollte es jemandem, der nicht dabei war, erlauben, die Änderung allein aus dem Datensatz nachzuvollziehen: den Antrag, die Entscheidung, die genaue Konfigurationsänderung und den Nachweis, dass sie funktioniert hat. Dreizehn Felder decken das ab. Fünf davon (3, 7, 8, 11 und 12) folgen direkt aus dem Wortlaut von PCI DSS Anforderung 6.5.1, die übrigen braucht ein Prüfer, um eine Änderung in beide Richtungen zu verfolgen.
| Nr. | Feld | Inhalt | Warum es im Audit zählt |
|---|---|---|---|
| 1 | Änderungs-ID | Eindeutige ID aus dem Change-System, nie wiederverwendet | Verbindet eine Konfigurationsabweichung am Gerät mit dem Datensatz |
| 2 | Antragsteller | Benannte Person und Team, kein Sammelpostfach | Jemand muss den fachlichen Bedarf später vertreten |
| 3 | Fachliche Begründung | Der Grund in Klartext, dazu die Anwendung oder der Dienst | PCI DSS 6.5.1 verlangt Grund und Beschreibung der Änderung |
| 4 | Ticket-Link | URL des ITSM-Tickets oder Antrags | Dort steht die Diskussion, die der Datensatz zusammenfasst |
| 5 | Betroffene Geräte und Regeln | Hostnamen, Policy oder Regelwerk, Regel-IDs oder -Namen, berührte Objekte | Legt den Stichprobenrahmen für den Prüfer fest |
| 6 | Regel vorher und nachher | Der exakte Regeltext vor und nach der Änderung oder ein Konfigurations-Diff | Zeigt, was auf dem Gerät geändert wurde, nicht was beabsichtigt war |
| 7 | Risikoeinstufung und Sicherheitsauswirkung | Standard, normal, hoch oder Notfall, mit einem Satz zur Sicherheitsauswirkung | PCI DSS 6.5.1 verlangt die Dokumentation der Sicherheitsauswirkung |
| 8 | Freigebender und Zeitstempel | Name, Rolle, Datum und Uhrzeit der Freigabe | Die Freigabe muss vor der Umsetzung liegen, der Zeitstempel belegt das |
| 9 | Umsetzungsfenster | Geplanter Beginn und geplantes Ende | Abgleich mit dem Geräteprotokoll deckt Änderungen außerhalb des Fensters auf |
| 10 | Umsetzender | Benanntes Admin-Konto, mit dem die Änderung erfolgte | Belegt die Trennung von Freigabe und Umsetzung |
| 11 | Verifikationsergebnis | Durchgeführter Test, Ergebnis, Nachweis (Logzeile, Verbindungstest, Screenshot) | PCI DSS 6.5.1 verlangt Tests, dass die Änderung die Sicherheit nicht beeinträchtigt |
| 12 | Rückfallplan | Schritte zum Zurücksetzen und ob sie genutzt wurden | PCI DSS 6.5.1 verlangt Verfahren für Fehlschläge und die Rückkehr in einen sicheren Zustand |
| 13 | Ablaufdatum temporärer Regeln | Löschdatum und Verantwortlicher, oder „dauerhaft“ mit Begründung | Verhindert, dass eine temporäre Regel Teil des Regelwerks bleibt |
Welche Felder werden am häufigsten schlecht ausgefüllt?
Nach unserer Erfahrung scheitern zwei Felder deutlich öfter als der Rest. Das erste ist Feld 6: Teams tragen ein, was sie vorhatten („App-Server darf auf DB über 1433“), statt der Regel, wie sie jetzt auf dem Gerät steht, mit Objektnamen, Zonen und Position im Regelwerk. Vergleicht ein Prüfer diesen Text mit der Live-Konfiguration, passt er nicht, und der Datensatz verliert seinen Wert als Nachweis. Das zweite ist Feld 11, in dem „erledigt“ oder „Test OK“ einen echten Test ersetzt. Schreiben Sie auf, was getestet wurde und mit welchem Ergebnis: „Verbindung von 10.20.4.15 zu 10.30.1.8 auf TCP 1433 erfolgreich, Trefferzähler von Regel 214 gestiegen“. Dieser Satz kostet dreißig Sekunden und stimmt auch dann noch mit dem Gerät überein, wenn ein Prüfer nachsieht.
Feld 13 ist bei Notfalländerungen am wichtigsten. Eine Regel, die während eines Vorfalls ohne Ablaufdatum geöffnet wurde, überlebt den Vorfall oft um Jahre, wie wir in der Notfall-Änderung, die nie zurückgerollt wird, beschreiben.
Was gehört in den monatlichen oder quartalsweisen Management-Bericht?
Der periodische Firewall-Änderungsbericht macht aus einem Stapel Datensätze eine Handvoll Zahlen, die zeigen, ob der Prozess funktioniert. Das Management liest daraus Trends und Risiken. Prüfer lesen ihn als Beleg dafür, dass jemand den Prozess überwacht und ihn nicht nur betreibt. Sieben Kennzahlen reichen. Jede weitere macht die Seite schwerer lesbar.
| Kennzahl | Wie gezählt wird | Was sie zeigt | Warnsignal |
|---|---|---|---|
| Änderungen nach Typ | Anzahl pro Zeitraum: Standard, normal, Notfall; dazu Hinzufügen, Ändern, Entfernen | Arbeitslast und Art der Arbeit | Ein plötzlicher Anstieg ohne erklärendes Projekt |
| Notfallanteil | Notfalländerungen geteilt durch alle Änderungen | Ob die Planung funktioniert oder der Notfallweg zur Überholspur geworden ist | Steigender Anteil bei gleichbleibender Zahl an Vorfällen |
| Fehlgeschlagene oder zurückgerollte Änderungen | Änderungen mit fehlgeschlagener Verifikation oder Rücknahme | Qualität von Tests und Vier-Augen-Prüfung | Wiederholte Fehler am selben Gerät oder im selben Team |
| Hinzugefügte vs. entfernte Regeln | Neue Regeln, gelöschte Regeln, Saldo | Ob das Regelwerk unkontrolliert wächst | Positiver Saldo in jedem Zeitraum |
| Überfällige Rezertifizierungen | Regeln nach ihrem Prüfdatum | Ob die periodische Überprüfung mit dem Regelwerk Schritt hält | Rückstand wächst von Zeitraum zu Zeitraum |
| Erkannte nicht autorisierte Änderungen | Konfigurationsänderungen ohne passende Änderungs-ID | Ob der Änderungsprozess der einzige Weg zur Firewall ist | Jede Zahl über null ohne Erklärung je Fall |
| Abgelaufene, noch aktive temporäre Regeln | Regeln nach ihrem Ablaufdatum aus Feld 13 | Ob temporäre Freischaltungen wirklich enden | Dieselben Regeln tauchen im nächsten Zeitraum wieder auf |
Zwei dieser Kennzahlen tragen den größten Teil der Aussage. Die Zeile nicht autorisierte Änderungen sehen sich Prüfer zuerst an, weil sie den ganzen Prozess testet: Wenn Änderungen ohne Datensatz auf die Firewall gelangen, beschreibt jede andere Zahl im Bericht nur einen Teil der Wirklichkeit. Wie Sie solche Änderungen finden, zeigt unser Beitrag zur Erkennung von Policy-Drift. Die Zeile überfällige Rezertifizierungen verbindet den Änderungsbericht mit der periodischen Regelprüfung aus unserem Leitfaden zur Rezertifizierung von Firewall-Regeln. PCI DSS Anforderung 1.2.7 verlangt, dass die Konfigurationen von Netzwerksicherheitskontrollen mindestens alle sechs Monate überprüft werden. Ein Rückstand an dieser Stelle ist ein Audit-Befund mit Ansage.
Zielwerte geben wir Ihnen bewusst nicht. Uns ist kein belastbarer Branchenvergleich für Notfallanteil oder Fehlerquote bekannt, und eine Zahl von einer Herstellerfolie hilft niemandem. Legen Sie Ihre eigene Schwelle nach zwei oder drei Zeiträumen fest, zeigen Sie den Verlauf der letzten vier bis sechs und geben Sie jeder roten Zahl einen Verantwortlichen und eine Maßnahme. Die erste Frage in der nächsten Runde wird lauten, was aus den roten Zahlen des letzten Quartals geworden ist.
Was wollen PCI-DSS-, ISO-27001- und NIS2-Prüfer sehen?
Alle drei Regelwerke verlangen im Kern dasselbe: ein festgelegtes Änderungsverfahren, Datensätze, die zeigen, dass jede Änderung ihm gefolgt ist, und einen Beleg, dass jemand prüft, ob das Verfahren wirkt. Der Änderungsdatensatz beantwortet die ersten beiden Punkte, der periodische Bericht den dritten.
| Regelwerk | Fundstelle | Inhalt | Wo die Vorlage es abdeckt |
|---|---|---|---|
| PCI DSS v4.0.1 | Anf. 1.2.2 | Alle Änderungen an Netzwerkverbindungen und an NSC-Konfigurationen werden nach dem Change-Control-Prozess aus 6.5.1 freigegeben und gesteuert | Ein Datensatz pro Firewall-Änderung |
| PCI DSS v4.0.1 | Anf. 6.5.1 | Grund und Beschreibung, Sicherheitsauswirkung, dokumentierte Freigabe durch Befugte, Tests, Verfahren für Fehlschläge | Felder 3, 7, 8, 11, 12 |
| PCI DSS v4.0.1 | Anf. 1.2.7 | NSC-Konfigurationen mindestens alle sechs Monate überprüft | Kennzahl überfällige Rezertifizierungen |
| PCI DSS v4.0.1 | Anf. 10.2.1.2 | Audit-Logs erfassen alle Aktionen von Personen mit administrativem Zugriff | Datenquelle für die Kennzahl nicht autorisierte Änderungen |
| ISO/IEC 27001:2022 | Anhang A 8.32 | Maßnahme Änderungssteuerung für informationsverarbeitende Einrichtungen und Systeme | Datensätze als Beleg, dass das Verfahren läuft; Bericht als Überwachung |
| NIS2 | Art. 21 Abs. 2 Buchst. e und f | Sicherheit bei Erwerb, Entwicklung und Wartung; Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen | Datensätze für e, periodischer Bericht für f |
| Durchführungsverordnung (EU) 2024/2690 | Anhang, 6.4 | Änderungen dokumentiert, risikobasiert getestet und auf Auswirkungen bewertet; Notfalländerungen mit Ergebnis und Grund für die Abweichung dokumentiert; Verfahren in geplanten Abständen überprüft | Felder 6, 7, 11; Notfallanteil; der Bericht selbst |
Der PCI-DSS-Wortlaut stammt aus dem Standard v4.0.1 in der Dokumentenbibliothek des PCI SSC. Anforderung 6.5.1 nennt Grund und Beschreibung der Änderung, die Dokumentation der Sicherheitsauswirkung, die dokumentierte Freigabe durch befugte Personen, Tests sowie Verfahren, um Fehlschläge zu behandeln und in einen sicheren Zustand zurückzukehren. Den Rest von Anforderung 1 behandelt unser Beitrag zu den PCI-DSS-4.0-Firewall-Anforderungen.
ISO/IEC 27001:2022 führt die Änderungssteuerung als Maßnahme 8.32 in Anhang A. Den Normtext verkauft ISO, und er schreibt keine Felder vor. Der Auditor beurteilt also, ob Ihr Verfahren und Ihre Datensätze angemessen sind. Die Vorlage oben gibt ihm etwas Konkretes zum Beurteilen.
Die NIS2-Richtlinie spricht nicht von einem „Änderungsbericht“. Artikel 21 Absatz 2 Buchstabe e nennt „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen“, Buchstabe f verlangt „Konzepte und Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen im Bereich der Cybersicherheit“. Die Details stehen in der Durchführungsverordnung (EU) 2024/2690. Im Anhang, Abschnitt 6.4 „Änderungsmanagement, Reparatur und Wartung“, heißt es: „Durch die Verfahren wird sichergestellt, dass diese Änderungen dokumentiert“ werden. Die Verordnung gilt unmittelbar für eine benannte Liste digitaler Anbieter, darunter DNS- und Cloud-Anbieter, Rechenzentren sowie Managed Service und Managed Security Service Provider. Andere wesentliche und wichtige Einrichtungen richten sich nach der nationalen Umsetzung. Unserer Einschätzung nach ist Abschnitt 6.4 trotzdem der konkreteste öffentliche Maßstab, auf den ein Prüfer in jedem NIS2-Sektor zurückgreifen kann. Es lohnt sich, ihn zu erfüllen.
Nach unserer Erfahrung prüfen Auditoren in beide Richtungen. Sie nehmen Änderungen, die am Gerät sichtbar sind (ein Konfigurations-Diff, ein Eintrag im Admin-Log), und fragen nach dem Datensatz. Dann nehmen sie Datensätze und fragen nach dem Nachweis am Gerät. Ein Bericht, der nur in eine Richtung funktioniert, fällt bei der anderen Hälfte der Stichprobe durch.
Bericht aus dem Tool oder aus der Tabelle?
Für eine kleine Umgebung lässt sich ein Firewall-Änderungsbericht aus einer Excel-Tabelle erstellen. Die Kennzahl, der Prüfer am meisten vertrauen, liefert eine Tabelle aber nicht. Sie kennt nur, was jemand eingetragen hat, und kann deshalb nie eine Änderung zeigen, die niemand erfasst hat. Ein Werkzeug, das die Firewall-Konfiguration ausliest, kann das.
| Berichtselement | Tabelle | Change-Werkzeug mit Anbindung an die Firewalls |
|---|---|---|
| Datensatzfelder | Freitext, Spalten werden übersprungen | Pflichtfelder bei Einreichung erzwungen |
| Regel vorher und nachher | Von Hand eingefügt, oft die Absicht | Als Diff vom Gerät gelesen |
| Zeitstempel der Freigabe | Eingetippt, später änderbar | Vom System erfasst |
| Nicht autorisierte Änderungen | Nur mit separatem Diff-Prozess möglich | Konfigurations-Diff gegen Änderungs-IDs abgeglichen |
| Monatliche Kennzahlen | Pivot-Tabellen jedes Mal neu gebaut | Eine gespeicherte Abfrage |
| Manipulationsnachweis | Jeder Bearbeiter kann die Historie umschreiben | Nur anhängende Historie |
Wenn Sie bei der Tabelle bleiben, schließen drei Gewohnheiten den größten Teil der Lücke: Sperren Sie die Spalten, damit Datensätze nach der Freigabe nicht mehr geändert werden können, tragen Sie die Änderungs-ID in das Kommentar- oder Beschreibungsfeld der Regel auf der Firewall ein, und exportieren Sie jeden Monat ein Konfigurations-Diff, das Sie von Hand gegen die Tabelle abgleichen. Wo dieser Ansatz an seine Grenzen kommt, zeigt unser Beitrag dazu, warum Excel-Nachverfolgung im Audit scheitert.
Wie fangen Sie an, wenn es heute nichts gibt?
Beginnen Sie mit dem Datensatz, nicht mit dem Bericht. Ein Bericht auf unvollständigen Datensätzen stellt die Lücken nur ordentlicher dar.
- Nehmen Sie die dreizehn Felder in das Änderungsformular auf, das Sie schon nutzen. Machen Sie zuerst 6, 8 und 11 zu Pflichtfeldern.
- Kennzeichnen Sie jede Regel mit ihrer Änderungs-ID im Kommentar- oder Beschreibungsfeld der Firewall, damit sich die Geräteseite zurückverfolgen lässt.
- Führen Sie einen Abgleich durch: Nehmen Sie das Konfigurations-Diff des letzten Monats und ordnen Sie jede Änderung einem Datensatz zu. Was übrig bleibt, ist Ihre erste Zahl für nicht autorisierte Änderungen.
- Veröffentlichen Sie den ersten Bericht als Ausgangswert, ohne Zielwerte. Schwellen legen Sie fest, sobald Daten aus drei Zeiträumen vorliegen.
Bewahren Sie die Datensätze so lange auf, wie jemand eine Änderung infrage stellen könnte. Das kann länger sein als der Audit-Zyklus, wie unser Beitrag zur Firewall-Änderung als Beweismittel zeigt.
Könnte Ihr Team bis Freitag einen vollständigen Änderungsbericht für das letzte Quartal vorlegen? Der kostenlose NIS2-Readiness-Check zeigt, welche Änderungsnachweise Ihre Firewall-Landschaft heute liefern kann und wo die Lücken liegen.
