Strategie statt Taktik beim Patchen

Ohne Zweifel ist ein kontinu­-ie­r­liches Patch-Management heute eine zwingende Anforderung für jedes Unternehmen. Die Probleme, die durch nicht gepatchte Systeme entstehen können, sind sonst einfach zu gross. Patch-Management wird allerdings zumeist nur als ein operatives Problem betrachtet. Dabei geht es vor allem darum, wie man Patches testet, freigibt und möglichst effizient auf die Systeme bekommt. Schon bei der Frage danach, wann welche Patches eingespielt werden, wird man aber auch mit weitergehenden Fragen konfrontiert. Denn das Einspielen von Patches kann eine Downtime für ein System bedeuten oder dessen Stabilität beeinflussen.

Das führt zu zwei Herausforderungen: Die eine ist die Festlegung von Regeln und Strukturen, die eine schnelle und fundierte Entscheidung zur Freigabe von Patches sicherstellen. Die andere ist der offensichtliche Spagat zwischen den Sicherheitsrisiken auf der einen und Verfügbarkeitsrisiken auf der anderen Seite. Dabei kann ein Sicherheitsrisiko durchaus zu Downtimes führen und auf der anderen Seite ein Patch nicht zwingend Sicherheitsprobleme, sondern auch Stabilitätsprobleme mit entsprechenden Auswirkungen auf die Verfügbarkeit verursachen.

Regeln für das Patch-Management

Die grösste Schwierigkeit beim Patch-Management ist nicht die technische Verteilung von Patches. Dafür gibt es ausreichend mehr oder weniger gut geeignete Werkzeuge, wobei die Eignung in hohem Masse davon bestimmt wird, wie gut sich differenzierte Prozesse und Regeln für das Patch-Management umsetzen lassen. Der Challenge dabei ist vielmehr, die Regeln dafür festzulegen, wann welche Patches angewendet werden sollen.



Das setzt im ersten Schritt eine Klassifizierung von Patches voraus. Bei Microsoft-Patches bieten beispielsweise die dort definierten Gruppen von Patches – es gibt ja nicht nur Sicherheits-Patches – und die Risikogruppen von Sicherheits-Patches eine gute Grundlage. Miteinfliessen können auch Charakteristika der Patches wie die Art der Bedrohung, also beispielsweise eine Einteilung in Kategorien wie etwa Pufferüberläufe, Cross Site Scripting und andere klassische Gefahren. Eine solche Klassifizierung ist die Grundlage für schnelle Entscheidungen, weil man für unterschiedliche Klassen von Patches eine fest vorgegebene Vorgehensweise für das Patch-Management definieren kann.

Da die Zuordnung von Patches zu genau beschriebenen Klassen aber einfach ist, lässt sich eine der grössten Herausforderungen für IT-Administratoren beim Patch-Management adressieren: Wer übernimmt die Verantwortung für nicht gepatchte Systeme respektive Schäden, weil ein Patch eben nicht eingespielt wurde?



Diese Klassifizierung muss natürlich nicht nur für die Sicherheits-Patches von Microsoft, sondern für alle Patches und Service Packs vorgenommen werden. Denn letztlich ist das Einspielen eines Service Pack, Support Pack oder wie auch immer die Bezeichnung des Herstellers lautet nichts anderes als eine Anwendung kumulierter Patches.

Risikomanagement

Der nächste Schritt ist eine Risikobewertung von Patches. Grundsätzlich lassen sich dabei drei grosse Gruppen von Risiken unterscheiden:


- Risiken für die Sicherheit, falls ein Patch nicht installiert wird

- Risiken für die Verfügbarkeit, falls ein Patch nicht installiert wird

- Risiken für die Verfügbarkeit, falls ein Patch installiert wird



Hier muss man die angesprochene Klassifizierung verfeinern, weil bei dieser Bewertung verschiedene Systemklassen und Applikationen ein grösseres Gewicht erhalten. Eine Strukturierung nach Systemgruppen ist ein guter Ansatz. Neben der generellen Unterscheidung zwischen Clients und Servern muss weiter beispielsweise nach Betriebssystemen, nach Desktop- und Notebook-Systemen und insbesondere nach Server-Applikationen und deren spezifischen Abhängigkeiten unterschieden werden. Die typischerweise geringere Gefährdung von Servern, die durch Firewalls und andere Sicherheitsverfahren besser geschützt sind, beeinflusst diese Bewertungen.



Damit ergibt sich ein klares Bild, für welche Systeme und Klassen von Patches welche Risiken bestehen. Das ist die Grundlage für die Entscheidung, in welcher Geschwindigkeit und unter welchen Voraussetzungen Patches eingespielt werden können. Dabei wird bei Serversystemen in der Tendenz das Risiko durch Probleme nach dem Einspielen von Patches höher sein, während dort die Sicherheitsrisiken oft niedriger zu bewerten sind als bei Clients, weil eben beispielsweise (hoffentlich) nicht über den Browser auf das Internet zugegriffen wird.



Verfügbarkeit versus Sicherheit

Recovery und Risikovermeidung

Auf der Basis klar definierter Risiken lassen sich nun auch Schritte einleiten, um diese Risiken zu minimieren. Dazu können Sicherheitsmassnahmen gehören, die die Angriffsflächen bei Clients oder Servern reduzieren. Bei Clients können das spezielle sich ergänzende Lösungen für die Endpoint-Security wie etwa lokale Firewalls oder USB- und WLAN-Schutzmechanismen sein.



Da es aber in vielen Fällen dennoch unerlässlich ist, aus Sicherheitsgründen bestimmte Patches schnell einzuspielen, muss man vor allem auch die Risiken der Nichtverfügbarkeit verringern. Hier gibt es inzwischen eine Fülle von Ansätzen, die die IT bietet. Virtuelle Maschinen bieten beispielsweise Snapshot-Mechanismen, die einen schnellen Rollback auf einen definierten Stand vor dem Einspielen des Patch ermöglichen. Anwendungen können über Anwendungsvirtualisierung bereitgestellt werden, um die Ausführungsumgebung und die Applika­tionen stärker zu entkoppeln und nach der Wiederherstellung der Systemumgebung von einem Image nach einem Fehler schnell wieder starten zu können.

Wichtig ist dabei auch der Blick auf die Änderungen, die zwischen dem Einspielen eines Patch und der Erkennung von Problemen wie einem nicht mehr korrekten Verhalten von Anwendungen auftreten. Das ist eine der grössten Schwierigkeiten, weil es oft nur schwer möglich ist, diese Änderungen isoliert zu erfassen und auf einem wiederhergestellten System erneut und ohne aufwendige manuelle Nacharbeit wieder durchzuführen.



Die Risiken lassen sich aber auch durch die heute oft schon genutzten standardisierten Testverfahren für Patches verringern. Dabei stellen heterogene Infrastrukturen oft eine Herausforderung dar. Standardisierte, versionierte Stacks von Komponenten auf Serversystemen sind hier ein wichtiger Ansatz, um die Komplexität zu reduzieren. Wenn Anwendungsserver, Datenbanken, Betriebssysteme, Webserver und andere Applikationen nur in einer sehr geringen Anzahl von Kombinationsmöglichkeiten eingesetzt werden, sinkt auch das Risiko von Problemen, das durch Patches entstehen kann.



Letztlich geht es bei der Vorgehensweise darum, für die identifizierten Risiken zu überlegen, wie man diese reduzieren kann. Und dabei gibt es viele Ansatzpunkte, die man nutzen kann. Besonders wichtig ist dabei, die Zeit für die Wiederherstellung von Systemen zu verringern.

Kernprozesse festlegen

Die daraus entstehenden Vorgehensweisen für das Patch-Management und die bedarfsweise Wiederherstellung von Systemen auf einen stabilen Zustand müssen beschrieben werden. Dazu gehört eine Reihe von Teilprozessen:



- Klassifizierung von Patches: Die Vorgehensweise für die Klassifizierung von Patches muss festgelegt werden, um die Entscheidungssi­tuationen soweit wie möglich zu minimieren. Es sollte nur in Ausnahmesituationen Patches geben, die nicht eindeutig einer Klasse zugeordnet werden können. Für solche Situationen müssen Eskalationsprozeduren definiert werden, die eine schnelle Bewertung der Risiken des Patch und der Entscheidung über die Systeme und den Zeitpunkt der Installation sicherstellen. Das muss in strukturierter Weise erfolgen, weil das grösste Risiko im gesamten Prozess nicht durchdachte Entscheidungen über die Patch-Installation sind.




- Patch- und Test-Prozeduren: Die Patch-Prozesse einschliesslich der erforderlichen Test-Prozeduren müssen ebenfalls beschrieben werden. Gerade bei den Tests bringt die Virtualisierung ebenfalls wesentliche Vorteile, da man sehr viel einfacher unterschiedliche Systemkonfigurationen testen kann, wenn diese als virtuelle Maschine zur Verfügung stehen – und wenn dazu mit Clones von virtuellen Maschinen besonders wichtiger Systeme gearbeitet wird.



- Wiederherstellung: Wichtig sind auch klare Vorgaben, wie eine allfällige Wiederherstellung zu erfolgen hat. Dazu gehört auch die Definition von Massnahmen, mit denen für eine möglichst frühzeitige Erkennung möglicher Probleme gesorgt wird, also beispielsweise Performance-Metriken oder definierte Tests für das Verhalten von sensitiven Anwendungen. Auch hier müssen natürlich Eskalationsprozeduren vorbereitet werden.



Prozesse fürs Patchmanagement

Patch-Management mit Methode

Definierte Prozesse und eine strukturierte Methodik für die Risikobewertung von Patches helfen dabei, das Patch-Management mit einem höheren Mass an Sicherheit – und eben geringeren Risiken – durchzuführen. Sie führen auch zu einem differenzierteren Umgang mit Patches, so dass vielleicht auf Clients manche Patches nicht gleich installiert werden, während bei Servern kritische Patches schneller eingespielt werden, als das sonst oft der Fall wäre.



Eine solche Vorgehensweise erleichtert aber auch eine Beurteilung darüber, wo man Änderungen an der IT-Infrastruktur vornehmen muss, um Risiken zu verringern – sei es durch zusätzliche Schutzmechanismen oder durch die Nutzung beispielsweise von Snapshots oder der inzwischen sehr vielfältigen Technologien für die Client-Virtualisierung.
Richtig gemacht, lassen sich die Risiken des Patch-Managements verringern. Durch eine strukturierte Risikobewertung erhalten zudem Investitionsentscheidungen eine klare Grundlage, weil man den Einfluss von Investitionen in Patch-Management-Lösungen, in die Virtualisierung, in Sicherheitsfunktionen und andere Technologien in einen Zusammenhang zur Verringerung von Risiken stellen kann.




Die heute oft anzutreffende Problematik, dass Administratoren sich aus Angst vor Fehlern in Anwendungen nicht trauen, Patches einzuspielen, lässt sich durch eine solche Vorgehensweise vermeiden. Denn wenn es für jeden Patch eine klar definierte, vorab durchdachte Vorgehensweise gibt, werden die Ad-hoc-Entscheidungen über Installation oder Nichtinstallation, die in der Praxis zu den meisten Fehlern führen, vermieden.