Operative Netzsicherheit ist zu einem wesentlichen Teil eine Sache von Abläufen. Zu diesen gehören zum Beispiel Update- und Patch-Prozesse. Angesichts der zunehmenden Sicherheitsvorfälle ist pro Objekt (Netzkomponente, Betriebssystem, Hypervisor etc.) von einer Update- bzw. Patch-Häufigkeit von mindestens zweimal im Jahr auszugehen. Leider sind viele Umgebungen darauf nicht vorbereitet. Was ist zu tun, damit sowohl die Anforderungen an die Verfügbarkeit des Netzes als auch das rechtzeitige Schließen von Sicherheitslücken sichergestellt sind?

Früher war alles besser

Viele haben nur ein Lächeln für einen älteren Menschen übrig, der befindet, früher sei alles besser gewesen. Ich sehe jetzt über Ihr mögliches Lächeln hinweg und will begründen, warum früher alles im Zusammenhang mit dem sicheren Netzbetrieb besser war:

• Erstens waren die internen Unternehmensnetze kaum exponiert. Es gab interne Netze und die Welt draußen. Dazwischen war kaum Kommunikation. Die Firmennetze waren Bastionen, getrennt von der Außenwelt, in der sich die meisten potenziellen Angreifer bewegten.
• Es gab kaum Angriffsvektoren für interne Unternehmensnetze. Die Netzkomponenten waren einfach aufgebaut. Es gab Hubs, Switches und Router, die alle sehr einfache Funktionen wahrnahmen. Sie boten wenig Angriffsfläche.
• Jede Netzkomponente war autark. Ihre Funktion war nicht von der Funktion anderer Komponenten abhängig. Ein Router war auch für sich allein funktionsfähig. Fiel der Nachbarrouter aus, hat der Router einfach die Routen aus der eigenen Tabelle entfernt, die über den nicht mehr präsenten Nachbarn erreichbar waren. Aber ansonsten hat der Router weiter funktioniert. Und Ziele, die über redundante Wege erreichbar waren, blieben selbst beim Ausfall eines der Wege erreichbar.
• Die Schnittstellen zwischen den Netzkomponenten basierten strikt auf Standards.
• Die oben genannten Umstände waren vom Vorteil für den Netzbetrieb:
  Es lohnte sich für äußere Angreifer kaum, im innersten Kern der Unternehmensnetze nach potentiellen Einfallstoren zu suchen, denn diese Netze waren per se nicht erreichbar.
• Die einfache Funktion der Netzkomponenten reduzierte die Wahrscheinlichkeit von Sicherheitslücken.
• Man konnte einfach Netzkomponenten aus dem Betrieb nehmen, zum Beispiel für die seltenen Fälle von Software Updates. Das restliche Netz arbeitete weiter.
• Ein Software Update auf einer Komponente änderte nichts daran, dass diese Komponente in der Kooperation mit anderen Komponenten sehr genau definierte und standardisierte Schnittstellen einhalten musste.

Nun ist alles komplizierter

Die einfache Welt von einst ist nicht mehr da:

• Es gibt vielfältige Wege in das Herz von Unternehmensnetzen. Das größte Einfallstor ist der mit einem Endgerät und einem Browser ausgestattete interne User, der auf das Internet zugreift. Für Angreifer lohnt es sich, diesen Menschen Fallen zu stellen, um mit ihrer Hilfe in das Innere der IT-Bastionen von Firmen zu gelangen.
• Die Netzkomponenten sind in ihrer Funktion viel komplexer geworden. Sie haben auch Sicherheitsfunktionen. Sie können den durch sie vermittelten Verkehr aufzeichnen und kopieren. Sie können selbst mit anderen Maschinen in Interaktion treten usw. Mehr Funktion bedeutet mehr Komplexität. Mehr Komplexität bedeutet höhere Wahrscheinlichkeit von Bugs, die auch zu Sicherheitslücken werden können.
• In einigen Umgebungen sind die Netzkomponenten so eng miteinander verknüpft, dass ein Software Update bzw. ein Patch immer gleichzeitig auf allen Komponenten durchgeführt werden muss. Es ist nicht mehr sichergestellt, dass eine Mischung der Software-Stände x und y im Netz ein funktionierendes Ganzes ergibt. Es ist eher davon auszugehen, dass es zwischen dem Beginn und dem vollständigen Abschluss des Update- bzw. Patch-Vorgangs Netzstörungen geben wird.
• Proprietäre Schnittstellen haben in einigen Umgebungen standardisierte Interfaces ersetzt. Dadurch ist die Auswirkung eines Updates des Systems A auf dessen Interaktion mit System B unberechenbar geworden.

Häufigere Updates bei gleichzeitig steigenden Verfügbarkeitsanforderungen

In der neuen komplizierten Welt braucht man also erstens häufigere Updates und Patches und zweitens immer Wartungsfenster, um sie durchzuführen. Wie erwähnt geht der Trend in Richtung von mindestens zwei Updates pro Jahr. Die zwei Wartungsfenster, die der Netzbetreiber bekommen muss, müssen lang genug sein, um den gesamten Prozess der Aktualisierung auf allen miteinander verschränkten Systemen abzudecken. Je nach Größe und Komplexität des Netzes braucht man Wartungsfenster, die eine ein- bis zweistellige Anzahl von Stunden dauern. Nach jedem Wartungsfenster gilt es, die Funktion des Netzes zu testen, wahrscheinlich anhand der typischen Abläufe der wichtigsten Anwendungen. Dafür braucht man auch einige Stunden. Und falls die Tests nicht erfolgreich verlaufen, muss der Update- bzw. Patch-Prozess rückgängig gemacht werden, wie in der Abbildung 1 dargestellt. Nicht zu vergessen ist auch, dass eingeschränkte Netzfunktion einigen Server- oder Speicher-Clustermechanismen nicht gut bekommt. Daher tendieren viele Cluster-Administratoren dazu, vor jeder Netzwartung ihre Cluster aufzulösen und erst nach der Erfolgsmeldung ihrer Netzkollegen die Cluster wiederherzustellen.

Zusammen kommen wir also möglicherweise auf ein ganzes Wochenende, das pro Netzupdate einzukalkulieren ist. Verschiedene Abteilungen müssen dabei involviert werden, von den Netz- über die System- bis zu den Anwendungsverantwortlichen. Nicht zu vergessen die Firmen, mit denen Wartungs- und Betriebsverträge abgeschlossen sind.

Dabei sind die Netze nicht die einzigen Umgebungen, die solche Wartungsfenster benötigen. Wenn man sämtliche gemeinsam von allen Anwendungen genutzte Ressourcen berücksichtigt, braucht man für das Netz, die Sicherheitskomponenten, die Speicherumgebung und die Server mindestens eine hohe einstellige, wenn nicht sogar eine zweistellige Zahl von Wartungswochenenden pro Jahr. Hinzu kommen die anwendungsspezifischen Wartungsfenster.

Die Zeiten, in denen jedes beliebige Wochenende für Wartung genutzt werden konnte, sind jedoch für viele Unternehmen endgültig vorbei. Viele IT-Infrastrukturen müssen rund um die Uhr verfügbar sein. Auch über das Wochenende greifen eigene Mitarbeiter, Kunden und Partner auf die Anwendungen und damit die IT-Infrastrukturen eines Unternehmens zu. Wartungsfenster müssen mit so vielen Instanzen abgestimmt werden, dass sie realistisch nur wenige Male im Jahr geplant werden können. In vielen Fällen kann für das Netz, wenn überhaupt, höchstens einmal im Jahr ein stundenlanges Wartungsfenster genutzt werden.

Der einzig vernünftige Weg

An den vielfältigen Kommunikationsbeziehungen, die die Angriffsflächen erhöhen, können wir kaum etwas ändern. Die Welt ist nun mal wesentlich vernetzter als vor 20 Jahren. Aber wir können einiges tun, um mit mehr Updates bei mehr Verfügbarkeit die Quadratur des Kreises hinzubekommen:

• Wir können jeden Faktor, der zur Komplexität des Netzes beiträgt, auf den Prüfstand stellen. Brauche ich QoS? Kann ich QoS nicht durch Überangebot an Netzkapazität ersetzen? Muss ich jeden Switch anders konfigurieren als andere Switches? Kann ich die Konfiguration meines Netzes nicht weitgehend vereinheitlichen? Man merke: Die Entropie eines Netzes steigt mit der Zeit automatisch, wenn man nichts dagegen unternimmt. Der Kampf gegen die Komplexität ist ein ständiger Prozess.
• Die regelmäßigen Leser dieser Kolumne wissen, dass der Autor ein Verfechter des Internet-Modells ist, in dem möglichst jede Netzkomponente ohne andere Komponenten lebensfähig ist. Dahin müssen wir wieder zurück, wenn wir keine Monster-Update-Wochenenden mehr wollen.
• Standards sind gut dokumentiert und deren Einhaltung von jedem überprüfbar. Ich kann mit Traces jedem Hersteller nachweisen, ob sich seine Komponenten an Standards halten. Insofern tragen Standards auch zu mehr Verfügbarkeit bei und vereinfachen die Verifizierung der Netzfunktion nach jedem Update.

Abbildung 1: Update, Test und (bei negativem Testergebnis) Fall-Back

In diesem Beitrag konnte ich nur auf einen Teilaspekt der operativen Netzsicherheit eingehen. Meine Kollegen werden auf dem Zusatztag zum ComConsult Netzwerk Forum, nämlich am 26. März 2020, noch vieles mehr dazu berichten und auch live demonstrieren. Ferner wird mein Kollege Dr. Hoff am 23. März zur Eröffnung des Forums die Keynote halten, in der er auch auf operative Sicherheit eingehen wird. Das Programm des Forums ist eine reichhaltige Zusammensetzung aller höchst aktuellen Netzthemen, einschließlich mandantenfähiger Campusnetze, Verkabelung, Wireless, RZ-Netze, Cloud-Zugang und Netzmanagement. Wir freuen uns auf Ihren Besuch!