9
Firewall-Regel - mit vier Augen-Prinzip - dokumentieren und freigeben
Hallo,
wir haben da eine Fortigate-(600E) Firewall.
Da für die Beantragung und Freigabe der neuen Regel bei uns "vier-Augen-Prinzip" erforderliche ist, verwalten wir den "SOLL"-zustand in Excel-Tabellen und legen wir diese als IST-Zustand in der Firewall an.
Die 2. Person soll die Regel sowohl in der Excel-Tabelle als auch in der Firewall akzeptieren bzw. aktivieren.
Trotz unserer Bemühung stimmen Soll- und Ist-Zustand nicht 100% überein weil oft ein Regel mal nach Bedarf geändert und nicht in den Tabellen dokumentiert wird.
Wie verwaltet ihr die Dokumentation der Firewall-Regel bei Euch?
- Initialantrag
- Überprüfung
- Freigabe
- erstes Anlegen
- Überarbeitungen
- Löschen, falls die Regel nicht mehr im Einsatz sind.
Optimal wäre ein Plattform, wo man die Regel anlegen kann, diese werden verständlich dargestellt und bei Freigabe legt es die Regel via CLI an.
Welche Lösungen habt ihr im Einsatz?
Eine 2. Frage ist wie ihr sicherstellt, dass die Regel deaktiviert werden, falls sie nicht mehr im Einsatz sind.
Werden die Regel regelmäßig kontrolliert?
Vielen Dank für eure Rückmeldung.
Gr. I.
wir haben da eine Fortigate-(600E) Firewall.
Da für die Beantragung und Freigabe der neuen Regel bei uns "vier-Augen-Prinzip" erforderliche ist, verwalten wir den "SOLL"-zustand in Excel-Tabellen und legen wir diese als IST-Zustand in der Firewall an.
Die 2. Person soll die Regel sowohl in der Excel-Tabelle als auch in der Firewall akzeptieren bzw. aktivieren.
Trotz unserer Bemühung stimmen Soll- und Ist-Zustand nicht 100% überein weil oft ein Regel mal nach Bedarf geändert und nicht in den Tabellen dokumentiert wird.
Wie verwaltet ihr die Dokumentation der Firewall-Regel bei Euch?
- Initialantrag
- Überprüfung
- Freigabe
- erstes Anlegen
- Überarbeitungen
- Löschen, falls die Regel nicht mehr im Einsatz sind.
Optimal wäre ein Plattform, wo man die Regel anlegen kann, diese werden verständlich dargestellt und bei Freigabe legt es die Regel via CLI an.
Welche Lösungen habt ihr im Einsatz?
Eine 2. Frage ist wie ihr sicherstellt, dass die Regel deaktiviert werden, falls sie nicht mehr im Einsatz sind.
Werden die Regel regelmäßig kontrolliert?
Vielen Dank für eure Rückmeldung.
Gr. I.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5605769961
Url: https://administrator.de/contentid/5605769961
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
9 Kommentare
Neuester Kommentar
Hm, ich traue mich kaum darauf zu antworten, aber in der Regel gibt es ein Standardruleset, das eingehend alles blockt und ausgehend nur Standardports zulässt. Config Export und Import und gut ist.
Und dann wird das kundenspezifisch angepasst, das alles in einer Excel-Datei zu dokumentieren wäre viel zu aufwendig.
Andererseits haben wir auch nicht den Luxus, da ein 4-Auge Prinzip nur für Firewallregeln einzuführen.
Und ändern sich Regeln bei euch so schnell, dass sichergestellt werden muss, dass die auch direkt gelöscht oder deaktiviert werden? Vielleicht sind wir dazu zu klein, aber bei unseren Kunden ändert sich in der Regel kaum was. Auch bei unseren größeren Kunden mit mehreren Standorten ändert sich nach der Initialkonfiguration nicht viel. Vielleicht muss mal der eine Server noch per DNS auf den anderen Server, aber das wars dann auch. Und Änderungen werden in der FW dann im Kommentarbereich mit dem aktuellen Datum und einem Mitarbeiterkürzel versehen und es wird eine Backup-Konfig angelegt.
MfG
Und dann wird das kundenspezifisch angepasst, das alles in einer Excel-Datei zu dokumentieren wäre viel zu aufwendig.
Andererseits haben wir auch nicht den Luxus, da ein 4-Auge Prinzip nur für Firewallregeln einzuführen.
Und ändern sich Regeln bei euch so schnell, dass sichergestellt werden muss, dass die auch direkt gelöscht oder deaktiviert werden? Vielleicht sind wir dazu zu klein, aber bei unseren Kunden ändert sich in der Regel kaum was. Auch bei unseren größeren Kunden mit mehreren Standorten ändert sich nach der Initialkonfiguration nicht viel. Vielleicht muss mal der eine Server noch per DNS auf den anderen Server, aber das wars dann auch. Und Änderungen werden in der FW dann im Kommentarbereich mit dem aktuellen Datum und einem Mitarbeiterkürzel versehen und es wird eine Backup-Konfig angelegt.
MfG
Ja. wir haben zwei Firewall-Tabellen (für zwei FW-Clusters- interne und bei einem Dienstleister) mit Dutzenden Tabellenreitern und Tausenden Regeln für produktive und Testumgebungen, für Projektnetze usw.
Aus den unterschiedlichen Projekten und Systemumstrukturierungen kommen relativ häufig Anfragen.
Wir löschen nicht sofort Regel, es ist aber ein Aspekt sicherzustellen, dass nicht mehr benötigte Regel irgendwann mal gelöscht werden.
Aus den unterschiedlichen Projekten und Systemumstrukturierungen kommen relativ häufig Anfragen.
Wir löschen nicht sofort Regel, es ist aber ein Aspekt sicherzustellen, dass nicht mehr benötigte Regel irgendwann mal gelöscht werden.
Moin,
ich habe zwar zum "vier-Augen-Prinzip" jetzt keine direkte Lösung aber man kann zumindest ein paar der Probleme mit den Bordmitteln begegnen.
Man kann sich über die Security Rating Issues über nicht mehr verwendete Policies benachrichtigen lassen.
Es gibt dann einen Hinweis sobald eine Policy eine bestimmte Zeit nicht genutzt wird (HitCount).
Im FortiManager kann man danach auch Filtern.
Ab FortiOS 7.2 gibt es das "Workflow Management". Damit wird unter anderem für jede Policy ein Audit trail angelegt. Da ist dann genau festgehalten wer welche Änderung vorgenommen hat.
Zusätzlich kann man die Policies dann auch mit einem Ablaufdatum / Uhrzeit versehen.
Da man nachher genau sehen kann wer die Änderung vorgenommen hat ist ja vielleicht die Motivation höher die Excel-Tabelle zu pflegen
https://docs.fortinet.com/document/fortigate/7.2.0/new-features/664644/a ...
Viele Grüße
ich habe zwar zum "vier-Augen-Prinzip" jetzt keine direkte Lösung aber man kann zumindest ein paar der Probleme mit den Bordmitteln begegnen.
Optimal wäre ein Plattform, wo man die Regel anlegen kann, diese werden verständlich dargestellt und bei Freigabe legt es die Regel via CLI an.
Eventuell FortiManager?Welche Lösungen habt ihr im Einsatz?
Eine 2. Frage ist wie ihr sicherstellt, dass die Regel deaktiviert werden, falls sie nicht mehr im Einsatz sind.
Werden die Regel regelmäßig kontrolliert?
Eine 2. Frage ist wie ihr sicherstellt, dass die Regel deaktiviert werden, falls sie nicht mehr im Einsatz sind.
Werden die Regel regelmäßig kontrolliert?
Man kann sich über die Security Rating Issues über nicht mehr verwendete Policies benachrichtigen lassen.
Es gibt dann einen Hinweis sobald eine Policy eine bestimmte Zeit nicht genutzt wird (HitCount).
Im FortiManager kann man danach auch Filtern.
Ab FortiOS 7.2 gibt es das "Workflow Management". Damit wird unter anderem für jede Policy ein Audit trail angelegt. Da ist dann genau festgehalten wer welche Änderung vorgenommen hat.
Zusätzlich kann man die Policies dann auch mit einem Ablaufdatum / Uhrzeit versehen.
Da man nachher genau sehen kann wer die Änderung vorgenommen hat ist ja vielleicht die Motivation höher die Excel-Tabelle zu pflegen
https://docs.fortinet.com/document/fortigate/7.2.0/new-features/664644/a ...
Viele Grüße
Vielen Dank!
Ich werde mir diese Lösung anschauen.
Sieht gut aus, ich werde mal prüfen was mit Provisionierung alles gemacht werden kann.
Wenn wir mit dem Fortimanager Regel erstellen und nach Freigabe auf FortiGate provisionieren könnten, wäre es schon ein großer Schritt.
Auch das kleinste FortiManager Lösung ist etwas "pricey". Wir müssten also ggf. genau schauen, wie wir unsere gesamte Fortigate Infrastruktur damit weiter optimieren können unabhängig von unseren "Excel-Tabellen".
https://www.enbitcon.de/shop/fortinet/fortinet-fortimanager-200f/fmg-200 ...
Gr. I.
Ich werde mir diese Lösung anschauen.
Sieht gut aus, ich werde mal prüfen was mit Provisionierung alles gemacht werden kann.
Wenn wir mit dem Fortimanager Regel erstellen und nach Freigabe auf FortiGate provisionieren könnten, wäre es schon ein großer Schritt.
Auch das kleinste FortiManager Lösung ist etwas "pricey". Wir müssten also ggf. genau schauen, wie wir unsere gesamte Fortigate Infrastruktur damit weiter optimieren können unabhängig von unseren "Excel-Tabellen".
https://www.enbitcon.de/shop/fortinet/fortinet-fortimanager-200f/fmg-200 ...
Gr. I.
Hallo,
Unimus ist eine low-cost-Lösung, um die Konfigurationen/Snippets auf mehrere Geräte zu spielen.
Das ist außerdem ein gutes Beispiel zu dieser Diskussion: Was greift bei UTM-Firewalls wirklich ineinander?
Ich behaupte, wenn ihr ständig Regeln ändert, muss das früher oder später aus dem Ruder laufen, egal wie man es verwaltet. Die Regeln sind eben nicht so leicht verständlich, außerdem z.B. in der Reihenfolge abhängig und vor allem sind sie lokal auf der jeweiligen Firewall.
Es gibt für Firewall-Regeln eine gewünschte Granularität, z.B. Hosts oder Subnetze. In jeder granularen Einheit gibt es Dienste, z.B. ein Subnetz XY, in dem Webserver stehen. Dann mache ich eben eine Regel, nach der ein Adress-Gruppenobjekt "zugriff-subnetzxy-web" per Dienstobjekt web (HTTP/HTTPS) in das Subnetz XY greifen darf. Diese Regel bleibt unverändert; denn solange es in diesem Subnetz Webserver gibt, so lange wird irgendjemand oder -etwas auf die zugreifen müssen.
Die effektiven Rechte werden durch den Inhalt des Gruppenobjekts "zugriff-subnetzxy-web" bestimmt, das auch als Konfigurations-Snippet leicht zu lesen ist, einfach für einen API-Request generiert werden kann, und bei einem ordentlichen Namensschema über alle Firewalls hinweg synchronisiert werden kann (ohne FortiManager oder Unimus).
Grüße
Richard
Unimus ist eine low-cost-Lösung, um die Konfigurationen/Snippets auf mehrere Geräte zu spielen.
Das ist außerdem ein gutes Beispiel zu dieser Diskussion: Was greift bei UTM-Firewalls wirklich ineinander?
Ich behaupte, wenn ihr ständig Regeln ändert, muss das früher oder später aus dem Ruder laufen, egal wie man es verwaltet. Die Regeln sind eben nicht so leicht verständlich, außerdem z.B. in der Reihenfolge abhängig und vor allem sind sie lokal auf der jeweiligen Firewall.
Es gibt für Firewall-Regeln eine gewünschte Granularität, z.B. Hosts oder Subnetze. In jeder granularen Einheit gibt es Dienste, z.B. ein Subnetz XY, in dem Webserver stehen. Dann mache ich eben eine Regel, nach der ein Adress-Gruppenobjekt "zugriff-subnetzxy-web" per Dienstobjekt web (HTTP/HTTPS) in das Subnetz XY greifen darf. Diese Regel bleibt unverändert; denn solange es in diesem Subnetz Webserver gibt, so lange wird irgendjemand oder -etwas auf die zugreifen müssen.
Die effektiven Rechte werden durch den Inhalt des Gruppenobjekts "zugriff-subnetzxy-web" bestimmt, das auch als Konfigurations-Snippet leicht zu lesen ist, einfach für einen API-Request generiert werden kann, und bei einem ordentlichen Namensschema über alle Firewalls hinweg synchronisiert werden kann (ohne FortiManager oder Unimus).
Grüße
Richard
Moin,
Gruß.
Dani
Wie verwaltet ihr die Dokumentation der Firewall-Regel bei Euch?
- Initialantrag
- Überprüfung
- Freigabe
- erstes Anlegen
- Überarbeitungen
- Löschen, falls die Regel nicht mehr im Einsatz sind.
dafür gibt es Ticketsystem mit Workflows... wir bilden das z.B. mit Atlassian JIRA ab.- Initialantrag
- Überprüfung
- Freigabe
- erstes Anlegen
- Überarbeitungen
- Löschen, falls die Regel nicht mehr im Einsatz sind.
Eine 2. Frage ist wie ihr sicherstellt, dass die Regel deaktiviert werden, falls sie nicht mehr im Einsatz sind.
Wenn eine Regel längere Zeit nicht mehr "matched" wird diese auf Liste gesetzt und einmal Jahr geprüft.Werden die Regel regelmäßig kontrolliert?
Bei uns findest zwei Mal im Jahr ein Security Audit von Firewalls und Web Application Firewalls statt. Spätestens dann kommen IST und SOLL Stand zur Prüfung. Natürlich nicht jede Regel. Es werden 30-40 Stichproben durchgeführt. Gibt es für eine oder mehrere Regeln kein Ticket, sind mehr IP-Adressen oder Services freigegeben als angefordert/genehmigt, etc. müssen die beteiligen Personen Stellung beziehen. Im schlimmsten Fall gibt's ne Abmahnung. Wo es kritisch ist haben wir zwei Firewalls hintereinander stehen, welche von zwei unabhängigen Teams verwaltet werden.Gruß.
Dani
Gern.
Für 2 Fortigates (auch mit HA) (VDOMs?) würde ich auch keine FMG Appliance hinstellen.
Eine FortiManager-VM würde vermutlich reichen.
https://docs.fortinet.com/product/fortimanager-private-cloud/7.2
Ansonsten wie von @c.r.s. schon geschrieben - möglichst übersichtlich halten.
Auch das kleinste FortiManager Lösung ist etwas "pricey". Wir müssten also ggf. genau schauen, wie wir unsere gesamte Fortigate Infrastruktur damit weiter optimieren können unabhängig von unseren "Excel-Tabellen".
https://www.enbitcon.de/shop/fortinet/fortinet-fortimanager-200f/fmg-200 ...
Gr. I.
https://www.enbitcon.de/shop/fortinet/fortinet-fortimanager-200f/fmg-200 ...
Gr. I.
Für 2 Fortigates (auch mit HA) (VDOMs?) würde ich auch keine FMG Appliance hinstellen.
Eine FortiManager-VM würde vermutlich reichen.
https://docs.fortinet.com/product/fortimanager-private-cloud/7.2
Ansonsten wie von @c.r.s. schon geschrieben - möglichst übersichtlich halten.
OK, vielen Dank!
Wir werden die Möglichkeiten genau prüfen ...
Wir werden die Möglichkeiten genau prüfen ...
Wir müssten uns den Fortimanager definitiv anschauen. Wenn man dort lediglich Regeln eintragen kann um diese dann an Systeme automatisch auszurollen, können wir uns das Geld dafür sparen. Wenn man aber dort auch mehr hinterlegen kann (Ticketnummer, Namen, Beschreibung, Prüfer, Datum, Änderung/Neu/...) und das System Regeln auch eine gewissen Prüfung (Plausibiltät) unterzieht, könnte es interessant sein.
Im optimalen Fall sollte das System einem 2. User die Möglichkeit bieten, angelegte Regel "durchzuwinken" bzw. zu aktivieren.
Wir werden es mal im öffentlichen Demo anschauen: https://fortimanager.fortidemo.com/p/login/
(Auf ersten schnellen Blick habe ich diese Anforderungen nicht prüfen können)
Im optimalen Fall sollte das System einem 2. User die Möglichkeit bieten, angelegte Regel "durchzuwinken" bzw. zu aktivieren.
Wir werden es mal im öffentlichen Demo anschauen: https://fortimanager.fortidemo.com/p/login/
(Auf ersten schnellen Blick habe ich diese Anforderungen nicht prüfen können)
