Scary Stories to tell in the Network

Halloween steht vor der Tür – hier eine Firewall-Policy-Horrorgeschichte aus der Praxis. (Stellen Sie sich diese für den vollen Effekt gerne mit einer unheimlichen, rauen Mahnstimme vor … oder mit Morgan Freeman, wenn Ihnen das lieber ist.)

Als Sales Engineer verbringe ich viele Tage damit, unsere Produkte vorzuführen und mit Security Engineers, Compliance-Verantwortlichen, DevOps-Managern und CISOs über Firewalls und Netzwerksicherheit zu sprechen. Manchmal sind die Geschichten derjenigen, die an vorderster Front arbeiten, unglaublich – und manchmal schlichtweg beängstigend. Hier eine aktuelle Geschichte eines Kunden, die jeden Firewall-Engineer nachts wach hält.

Szenario:
Das Unternehmen hatte kurz zuvor eine „Zero Trust“-Philosophie eingeführt und viel Zeit investiert, um diesem Ziel näherzukommen. Im vergangenen Jahr konzentrierte man sich darauf, die Firewall-Richtlinien zu bereinigen, indem Regeln exakt auf den geschäftlichen Bedarf zugeschnitten wurden – nicht mehr – also nur die konkreten IPs und Netzwerke, die Zugriff benötigten. Man machte Fortschritte, bis einer der Engineers eine erschreckende Entdeckung machte: eine gefürchtete „Any – Any – Any – Accept“-Regel, verborgen mitten in der Richtlinie.

Man versuchte hektisch herauszufinden, warum diese Regel existierte. Schließlich stellte sich heraus, dass ein Junior Network Engineer sie angelegt hatte, um einfach nur etwas zum Laufen zu bringen. Diese eine Regel untergrub sämtliche Fortschritte in Richtung des Zero-Trust-Ziels und setzte das Netzwerk einem enormen Risiko aus.

Die Regel musste selbstverständlich entfernt werden. Doch sie war seit mindestens 6 Monaten unentdeckt in der Richtlinie enthalten und ließ mit Sicherheit geschäftskritischen Datenverkehr zu. Die Logdaten zeigten sogar, dass es sich um eine äußerst stark genutzte Regel handelte. Natürlich erlaubte sie vermutlich mehr als nur geschäftskritischen Datenverkehr – wahrscheinlich auch bösartigen. Das Problem musste schnell behoben werden.

Zunächst gab es Besprechungen mit den Netzwerkverantwortlichen, in denen man mutmaßte, um welchen Datenverkehr es sich handeln könnte, und kritische Anwendungen sowie Verkehrsströme zusammentrug, von denen Netzwerkkundige annahmen, dass sie diese Regel nutzen könnten. Letztlich entschied man sich jedoch, in den sauren Apfel zu beißen, die Regel zu entfernen und abzuwarten, wer sich beschwert.

Also informierte man die Führungskräfte aller Geschäftsbereiche über diesen Fehler. Mit einiger Verlegenheit kündigte man an, dass eine „Hotline“ mit bereitstehenden Mitarbeitenden eingerichtet werde, und musste letztlich Personen sämtliche geschäftskritischen Funktionen testen lassen, um sicherzustellen, dass ihre Produkte, ihre Anwendungen und alles, worauf sie für ihre Arbeit Zugriff benötigten und was es Kunden/Partnern/Lieferanten ermöglichte, mit ihnen Geschäfte zu machen, nur so lange ausfallen würde, bis alles wieder eingerichtet war. Ja, es kam zu Ausfällen, und ja, man war darauf vorbereitet, neue Regeln zur Behebung der Probleme zu erstellen – aber was für ein Albtraum.

—

Vielleicht haben Sie kein Albtraumszenario wie das oben beschriebene, doch FireMon kann Ihnen die Arbeit dennoch erleichtern, indem es Sie beim Bereinigen Ihrer Firewall-Richtlinien unterstützt. Hier einige Möglichkeiten, wie FireMon das obige Szenario hätte verhindern können. Und falls Sie jemals eine beängstigend freizügige Regel in Ihrer Richtlinie entdecken, sehen Sie sich unbedingt Punkt 6 weiter unten an – für eine schmerzfreie Lösung des Problems.

1) Compliance-Benachrichtigungen und -Berichte:
Wir hätten das Team sofort benachrichtigt, wenn eine derart freizügige Regel in Betrieb gegangen wäre. Sie können im Grunde festlegen, wie freizügig Regeln sein dürfen, etwa „Regeln, die Zugriff auf mehr als 60.000 Ziele erlauben“ oder „Regeln mit Quellen, die größer als ein /16-Netzwerk sind“.

2) Änderungsbenachrichtigungen:
Diese Regel wäre in unserer normalisierten Ansicht aufgeführt worden – unabhängig vom Firewall-Hersteller – und klar als Neuzugang erkennbar gewesen. Sie hätte sich also nicht „einschleichen“ können. Manche Engineers und Führungskräfte erhalten bei jeder Änderung automatisch Berichte über Richtlinienänderungen per E-Mail – oder auch nur eine 30-Tage-Momentaufnahme aller Änderungen.

3) Mit unserem Automatisierungswerkzeug FireMon Policy Planner wäre die riskante Regel sofort gestoppt worden – noch bevor sie ausgerollt wurde. Mithilfe unserer „Pre-Change-Analyse“ wäre die Regel erkannt und markiert worden, bevor sie in die Produktion übertragen wurde und auch nur ein einziges Datenpaket durchgelassen hätte. Deshalb schätzen Compliance-Verantwortliche, dass wir Regeln nicht nur bedarfsgerecht zur Erstellung vorschlagen, sondern – ähnlich wie in einer Sandbox-Umgebung – unsere Compliance-Algorithmen ausführen, bevor wir die Regeln automatisch ausrollen können. Manche Kunden erwerben Policy Planner AUSSCHLIESSLICH wegen dieser Funktion – und greifen über unsere APIs darauf zu.

4) Ebenfalls dank der Änderungsbenachrichtigungen hätte das Team mit Sicherheit gewusst, wer wann welche Änderungen vorgenommen hat. In diesem Fall – es handelte sich um einen Junior Engineer – hätte eine Führungskraft die Änderungen dieses Benutzers der letzten Woche oder zumindest des letzten Monats schnell filtern bzw. sortieren können, um zu sehen, welche Art von Änderungen dieser Benutzer vorgenommen hatte. Auch das Compliance-Team oder sogar der Benutzer selbst hätten sich das ansehen können.

5) Aus Dokumentationssicht kann FireMon die einzige verlässliche Informationsquelle für Fragen wie „Wer hat dies beantragt, wer ist der Anwendungsverantwortliche, wann wurde diese Regel zuletzt überprüft?“ sein. Durch das Filtern und Sortieren von Regeln anhand der Regeldokumentation wäre dies also ebenfalls schneller aufgefallen.

6) Das Beste habe ich mir für den Schluss aufgehoben. Wenn Sie tatsächlich eine übermäßig freizügige Regel haben – etwa weil Ihre Vorgänger einen anderen, „offeneren/flexibleren Stil der Regelerstellung“ pflegten als Sie –, bieten wir eine einfache Möglichkeit, solche Regeln zu bereinigen. Mit der Traffic Flow Analysis betrachtet unser Werkzeug jede einzelne IP-Adresse, die über die Regel läuft, und schlüsselt ein Any/Any/Any in konkrete Verkehrsströme auf. Diese Ströme können Sie exportieren und darauf basierend spezifische Regeln erstellen.