Eine praktische Geschichte der Firewall – Teil 2: Der Wert des Managements

Jody Brazil CEO at FireMon Check Point und Stateful-Inspection-Firewalls gewannen den frühen Kampf gegen Proxy-Firewalls (Teil 1: Die frühen Jahre). Es liegt nahe anzunehmen, dass es allein um die Inspektionstechnologie ging, doch damit übersieht man eine zentrale Innovation der Check Point-Lösung: das Policy Management. Dass sich Stateful-Inspection-Firewalls Mitte der 90er-Jahre gegen die Proxy-Konkurrenz durchsetzten, lag zu einem erheblichen Teil an der einfachen Verwaltung. Ein Großteil dieses Artikels befasst sich mit Check Point. Das liegt in erster Linie an der dominierenden Rolle, die Check Point Ende der 90er- und Anfang der 2000er-Jahre im Firewall-Markt spielte. Wahrscheinlich liegt es aber auch an meiner eigenen Berührung mit Check Point in jenen Jahren. Ich freue mich über Ihre Sichtweise und Ihre Kommentare. Mitte der 90er-Jahre entwickelten sich Netzwerke rasant. Ethernet war beispielsweise eine Option, aber nicht immer das eingesetzte lokale Netzwerkprotokoll (erinnern Sie sich an Token Ring?). Eine Anbindung an das Internet war nicht selbstverständlich, sie wurde diskutiert. Einwahlverbindungen waren noch verbreitet, und AOL war der dominierende Anbieter. Firewalls als Mainstream-Technologie zu bezeichnen, hätte bedeutet, das Internet als Mainstream misszuverstehen. Eine Folge dieser sich schnell verändernden Netzwerke war ein erhebliches Maß an Unkenntnis und fehlender Erfahrung. Vor diesem Hintergrund sollte die Verwaltbarkeit einer Firewall als wesentlicher Markttreiber für den letztlichen Gewinner in diesem Markt nicht übersehen werden. Heute sprechen wir in der Softwareentwicklung von User Experience und Usability. Diese Schlagworte gab es damals noch nicht, doch der Grund, weshalb wir heute darüber sprechen, war damals genauso wichtig. Kunden „mochten“ das Produkt einfach lieber. Sicherheit und Leistung waren also wichtig, aber die Benutzerfreundlichkeit der Check Point-Firewall-GUI sollte nicht abgetan werden. Ein damaliger Gauntlet-Vertriebsmitarbeiter formulierte es so: „Es spielte keine Rolle, wer der Interessent war – in jedem Kundengespräch musste ich gegen die Check Point-GUI antreten, und meist verlor ich.“ Check Point führte seine Firewall mit zentraler Verwaltung und einer sehr innovativen Benutzeroberfläche ein. Zu den zentralen Funktionen gehörten:

• ein grafischer Regeleditor
• ein zentrales Objekt-Repository, das von den Firewall-Richtlinien gemeinsam genutzt wird
• zentrale Protokollierung
• Multi-Domain-Management und OPSEC

Der Check Point Policy Editor

Das Konzept einer Firewall-Regel als 5-Tupel aus Quelle, Ziel, Protokoll, Port (Protokoll und Port wurden zu einem einzigen Objekt namens Service zusammengefasst) und Aktion existierte lange vor dem Check Point Policy Editor. Bereits frühe Access Control Lists unterstützten dieses Konzept in den 80er-Jahren. Check Point veränderte jedoch mit dem grafischen Regeleditor das Paradigma. Es war nicht länger nötig, die CLI-Syntax zu beherrschen, um eine Regel zu erstellen. Eine Maus und einige Klicks genügten. Darüber hinaus wurde die Regelbearbeitung um nützliche Funktionen wie Kopieren und Einfügen, benutzerdefinierte Kommentare und mehrere Objekte pro Spalte erweitert. Letzterer Punkt – mehrere Objekte pro Spalte – war revolutionär. Frühere Access Control Lists unterstützten in den jeweiligen Spalten nur eine einzige Quelle, ein einziges Ziel und einen einzigen Service. Die Unterstützung mehrerer Objekte machte jede Regel leistungsfähiger, und das Bearbeiten einer Richtlinie bestand häufig darin, eine bestehende Regel zu ändern, statt neue Regeln anzulegen. Ein Großteil dieses Policy Editors beruhte auf einer weiteren Neuerung: dem zentralen Objekt-Repository.

Das zentrale Objekt-Repository von Check Point

Historisch wurden Access Control Lists mit einem Verweis auf eine konkrete IP-Adresse für Quelle oder Ziel erstellt. Das funktionierte, doch wenn sich die IP eines Systems änderte, mussten sämtliche Regeln aktualisiert werden. Ähnlich wie bei wiederverwendbarem Quellcode erkannte Check Point, dass ein zentrales Objekt-Repository und die Verwendung dieser Objekte in den Regeln die bessere Strategie wären. Änderte ein Host nun seine IP, musste nur das Objekt aktualisiert werden, und die Richtlinie spiegelte diese Änderung automatisch korrekt wider, da sie einen Verweis auf das gespeicherte Objekt nutzte. Zudem war es möglich, Gruppen dieser Objekte (und Gruppen von Gruppen) zu bilden, um gängige Objektgruppen in der gesamten Richtlinie wiederzuverwenden. Das waren bedeutende Fortschritte für ein effektiveres Policy Management.

Zentrale Protokollierung

Ein außerordentlich häufiges Problem bei Firewalls ist das Blockieren des falschen Datenverkehrs. Das gilt besonders dann, wenn eine Firewall zwischen zwei zuvor nicht segmentierte Netzwerke gesetzt wird – was Ende der 90er-Jahre bei nahezu jeder neuen Firewall-Bereitstellung der Fall war. Die zentrale und zugleich leicht durchsuchbare Protokollierung sämtlicher Firewall-Logs machte die Diagnose von Richtlinienfehlern sehr offensichtlich und vergleichsweise einfach. Ein Benutzer konnte ein Problem melden und eine Kombination aus Quell-IP und Ziel-IP angeben; ein Administrator konnte im Log Viewer den „Drop“-Eintrag sowie die zugehörige Regel finden, die das Verwerfen verursacht hatte (oder alternativ einen „Accept“-Eintrag finden und dem Benutzer mitteilen, dass er sich irrte). Fehler waren und sind in der Firewall-Richtlinienverwaltung häufig, daher war eine einfache Fehlersuche ein zentraler Mehrwert jeder Firewall-Plattform.

Multi-Domain-Management und OPSEC

Anfang der 2000er-Jahre setzte Check Point mit der Einführung des Multi-Domain-Managements durch Provider-1 und der Integrations-APIs durch OPSEC noch stärker auf die Leistungsfähigkeit der Verwaltung. Beides war eine deutliche Wette darauf, dass sich Check Point über das Management von anderen Firewall-Wettbewerbern absetzen kann – und sie ging auf. Provider-1 richtete sich, wie der Name nahelegt, an die Provider-Gemeinschaft, an Telekommunikationsunternehmen und Managed Service Provider. Während Provider die Technologie früh einsetzten, fanden auch Unternehmen rasch Gründe, das Produkt zu nutzen. Zentrale Funktionen wie Berechtigungssteuerung, verbesserte Verwaltungs- und UI-Leistung durch die Aufteilung großer Richtlinien und Objektdatenbanken sowie globale Regeln, die global angewendet und durchgesetzt werden konnten, waren allesamt Funktionen, die große Unternehmen sich wünschten. Größtenteils handelte es sich dabei um Einschränkungen der Standard-Managementplattform. Man könnte argumentieren, dass Check Point die Managementplattform hätte verbessern sollen, statt von Kunden einen erheblichen Aufpreis für Provider-1 zu verlangen; die Kunden erkannten jedoch den Nutzen und waren bereit, für diese erweiterten Verwaltungsfunktionen zu zahlen. OPSEC war ein Partnerprogramm und eine Sammlung von APIs, die Check Point veröffentlichte, um die Integration von Drittanbieterprodukten zu fördern. Zu den frühen Erfolgen zählten Reporting-Produkte, die die Log Export API (LEA) nutzten, URL-Filter-Produkte, die das URL Filtering Protocol (UFP) verwendeten, sowie Management-Produkte wie FireMon, die auf das Check Point Management Interface (CPMI) zurückgriffen. Das Programm und die Integrationen waren ein großer Erfolg. Heute gibt es weit über 100 OPSEC-Partner, die eine Integrationsmöglichkeit in die Plattform anbieten. Dieses Ökosystem aus Sicherheitsprodukten verschafft Kunden zusätzlichen Nutzen und Vertrauen in ihre Investition. Heute nehmen wir API-Integrationen als selbstverständlich hin, doch 2001, zum Start von OPSEC, war das bei Weitem nicht so verbreitet.

Cisco und die CLI als dominierende Größe

Der Markt wurde nicht vollständig von Check Point und der GUI beherrscht. Während sich Check Point mit einer leistungsfähigen und einfach zu bedienenden GUI als führender Anbieter im Firewall-Markt etablierte, blieb Cisco mit einer Kommandozeile (CLI) in der Pix seinen Wurzeln treu. Die Pix war ein früherer Wettbewerber im Firewall-Markt, entstanden 1994 und 1995 von Cisco übernommen. Die Vertrautheit der Netzwerkadministratoren mit Cisco und der CLI machte die Pix zur bevorzugten Wahl, wenn das Netzwerkteam für die Sicherheit verantwortlich war. Check Point knabberte an diesem Vorteil mit seinen Sicherheitsfunktionen und der GUI – unterstützt durch einen langsamen Wandel der Organisationsstrukturen in Unternehmen, bei dem Sicherheit zu einer vom Netzwerkteam getrennten Einheit wurde. Mit diesem Wandel spielte die bestehende Beziehung von Cisco zum Netzwerkteam bei der Auswahl des Firewall-Anbieters eine immer geringere Rolle. Die erweiterten Verwaltungsfunktionen trugen dazu bei, die Marktposition von Check Point zu festigen, und untermauerten den Wert des Managements für Sicherheitsprodukte. Doch so wie die Leistung Check Point in den 90er-Jahren half, den Proxy zu schlagen, sollte die Leistung in den folgenden Jahren erneut ein zentrales Entscheidungskriterium werden – und diesmal geriet Check Point unter Druck. Teil 3: Die Leistung rückt in den Mittelpunkt