Das Thema Patch-Management ist in den letzten zwei Jahren immer mehr in den Mittelpunkt der Diskussionen über die Sicherheit von PCs und Servern gerückt. Trotzdem ist ein automatisiertes Verteilen von Software-Updates auch heute noch nicht in jedem Unternehmen selbstverständlich. Während schon seit Jahren in Softwareverteilung und weitere Desktop-Management-Werkzeuge investiert wird, erfolgt das Patchen oft noch in Handarbeit oder wird gar dem Endanwender überlassen.
Um Updates auf die entsprechenden Clients zu verteilen, bieten sich mehrere Möglichkeiten an. Der einfachste, aber wohl am wenigsten erfolgversprechende Weg ist die Nutzung der "Windows Update Services" durch die Endanwender selbst. Das Problem dabei: Dazu sind administrative Rechte auf dem lokalen Rechner erforderlich, außerdem ist keinerlei zentrale Steuerung und Überwachung möglich. Eine rasche Absicherung der PCs gegen Angriffe auf bekannte Schwachstellen lässt sich auf diese Weise weder umsetzen noch nachvollziehen. Auch die Aktualisierung der Server wird so zum riskanten Spiel mit der Sicherheit.
Umfassenden Schutz kann nur eine automatisierte Verteilung von Patches mit vorgeschalteten Benachrichtigungs- und Testverfahren bieten. Sind diese im Einsatz oder geplant, sollte der Entscheider auf einige Mindestvoraussetzungen achten. Das automatisierte Erkennen und Mitteilen von neuen Patches des Betriebssystem- oder Anwendungsherstellers kann beispielsweise überlebenswichtig sein, ist es doch die Voraussetzung für eine schnelle Reaktion. Ferner sollten Software-Updates ohne Zutun des Anwenders heruntergeladen, sofort getestet und anschließend auf die betroffenen Systeme verteilt werden. Zudem ist das Zusammenspiel mit der bereits vorhandenen Infrastruktur und dem womöglich vorhandenen System-Management sehr wichtig. Beispielsweise können nicht alle Lösungen gleich gut standortübergreifend arbeiten, oder sie setzen eine komplett eigene Infrastruktur und Administration voraus, was sehr zeitaufwändig und teuer ist.
Um ein automatisiertes Patch-Management im Unternehmen zu etablieren, bieten sich drei Softwaretypen an:
- Spezialisierte Patch-Management-Lösungen, etwa von Betriebssystem-Herstellern, im Windows-Umfeld Software Update Services (SUS) beziehungsweise WUS;
- spezielle Patch-Management-Funktionen einer Softwareverteilungslösung;
- einer vorhandene Softwareverteilungslösung.
Alle drei Verfahren ermöglichen es Unternehmen, ihre Endgeräte und Server auf einem relativ sicheren Stand zu halten. Bloß relativ deshalb, weil Patch-Management nur Abhilfe bei bereits bekannten und behobenen Sicherheitslecks schaffen kann. Das wahrscheinlich am häufigsten eingesetzte Werkzeug sind die Software Update Services, die Microsoft kostenfrei zur Verfügung stellt. Sie gehören zur Kategorie der Spezial-Tools, können aber im Funktionsumfang und der Plattformunterstützung nicht mit den Lösungen anderer Spezialanbieter wie Shavlik Technologies, Ecora, St. Bernards oder Patchlink mithalten. Insbesondere die Steuerbarkeit und Nachvollziehbarkeit sind bei den Produkten dieser Hersteller deutlich besser gelöst als bei SUS. Ob die neue Microsoft-Version Windows Update Services, die in Kürze auf den Markt kommt, diese Probleme beseitigt, muss noch erprobt werden.
Mit Agent oder ohne?
Bei der Auswahl einer Lösung sollten Unternehmen darauf achten, dass diese mit ihren Server- und Client-Betriebssystemen zusammenarbeitet. Einige Hersteller unterstützen neben den aktuellen Microsoft-Betriebssystemen und Anwendungen auch automatisiertes Patchen von Plattformen wie NT4 (wird von Microsoft nicht mehr mit Service versorgt), Linux/Unix oder Mac OS.
Die Speziallösungen lassen sich in zwei Gruppen teilen: diejenigen, die auf einem Softwareagenten basieren, und solche, die ohne lokal installierte Komponente auskommen. Die erste Kategorie arbeitet ähnlich den bekannten Softwareverteilungs-Tools, wobei ein Agent auf den Endgeräten installiert wird, der lokal Analyse- und Installationsaufgaben übernimmt. Systeme ohne Agenten verbinden sich über das Netzwerk direkt mit den Endgeräten und erledigen so die nötigen Arbeiten. Vor allem bei verteilten Standorten und größeren Umgebungen hat diese Vorgehensweise Vorteile. So erkennen diese Systeme über periodische Netz-Scans meist automatisch neue Geräte. Zudem lassen sie sich in der Regel schnell im Netzwerk installieren, da die Verteilung der Client-Komponente entfällt.
Beiden Lösungstypen können Endgeräte daraufhin analysieren, welcher der vorhandenen Patches auf welchem Gerät installiert werden soll. Diese Erkennungslogik basiert in den meisten Fällen auf Informationen von Anbietern wie Microsoft, Red Hat oder Novell/Suse. Nur einige Hersteller nutzen eigene Routinen mit erweiterten Möglichkeiten. Neben der Erkenntnis darüber, ob ein Patch installiert werden soll, liefern diese Analysen auch wichtige Informationen zur Angreifbarkeit der Endgeräte, indem sie diese auf Schwachstellen scannen. Diese bedeutende Funktion ist Teil eines häufig sehr umfassenden Reportings. Informationen zu nicht vollständig gepatchten Systemen, Patch-Rollouts sowie Fehlern bei den Installationen der Updates lassen sich so zentral bereitstellen.
Kein Patchen ohne Tests
Da Patches aufgrund von Inkompatibilitäten mit den installierten Anwendungen ein Fluch sein können, ist ein Test- und Freigabe-Workflow unabdingbar. Beispielsweise dürfen manche Patches nicht auf Citrix Server installiert werden, auch wenn alle anderen Systeme sie erhalten sollen. In der Praxis haben sich hier zwei Funktionen als wesentlich erwiesen: die flexible Zuordnung von Patches zu Test- oder Pilotsystemen und das Ausklammern ausgewählter Systeme von einer generellen Patch-Verteilung.
Software-Management-Tools mit einer integrierten Patch-Verwaltung liefern einen ähnlichen Funktionsumfang wie die beschriebenen Speziallösungen. Manche Hersteller bieten dies entweder als kostenfreie Erweiterung (zum Beispiel Matrix 42 mit "Empirum Pro") oder als kostenpflichtiges Add-on (zum Beispiele Landesk mit "Landesk Security Suite" oder Altiris mit "Altiris Patch Management Solution") ihrer Software-Management-Lösungen an. Leider sind die Erweiterungen bei einigen Herstellern nicht vollständig in das Gesamtkonzept integriert. Das liegt daran, dass es sich häufig um OEM-Versionen handelt, also von Drittherstellern entwickelte Produkte. Vollständig integrierte Lösungen sind unter anderem deswegen im Vorteil, weil die Bedienung dem IT-Administrator im Wesentlichen schon bekannt ist und die bestehende Infrastruktur verwendet werden kann.
Hinzu kommt ein weiterer Vorzug: Wurde die Systemlandschaft bereits in Verzeichnissen und Rollen abgebildet, lassen sich diese Informationen auch für das Patch-Management nutzen, was eine Doppeladministration vermeidet. Zudem arbeiten die integrierten Lösungen generell auf Basis der Agenten, die bereits für die Softwareverteilung im Einsatz sind. Funktionen wie bandbreitenabhängige Verteilung, ausgefeiltes Scheduling und robuste Mechanismen zur Verwaltung vieler Standorte sind bei den aktuellen Software-Management-Lösungen Stand der Technik. Auch die Skalierbarkeit und das Handling sehr großer Mengen von Endgeräten sind bei dieser Produktkategorie heute in der Regel gelöst.
Server pusht Patches
Bei der Auswahl einer speziellen Lösung ist neben der Integrationstiefe zu beachten, dass Besonderheiten des Patch-Managements auch in der Softwareverteilung berücksichtigt wurden. So sollte neben dem meist verwendeten Pull-Verfahren, bei dem die Clients in fest eingestellten Intervallen nach neuen Aufgaben fragen, auch eine Push-Funktion zur Verfügung stehen, bei der die Update-Aktion ohne Anfrage des Clients startet. Das ermöglicht im Falle eines Not-Rollouts eine sofortige Reaktion, ohne auf das nächste Intervall warten zu müssen.
Ein weiterer Ansatz, um Patches auf Clients und Server zentral zu verteilen, ist die Nutzung der klassischen Softwareverteilungs-Tools. Dabei bezieht der Administrator die Patches direkt von den Herstellern per Internet und bettet sie in reguläre Verteilungspakete ein. Je nach Produkt lassen sich so Updates ebenfalls gezielt auf die Endgeräte verteilen, ohne dafür eine neue Infrastruktur aufbauen und ein neues Bedienungskonzept kennen lernen zu müssen.
Die potenziellen Ersparnisse dieses Verfahrens werden aber in der Regel schnell durch die Nachteile im Betrieb wieder aufgehoben. Denn es entsteht nicht nur manueller Aufwand bei der Ermittlung, ob es neue Patches gibt. Auch das Umpaketieren ist zeitaufwändig. Zudem stellt die Erkennungslogik dieser Tools meist nur rudimentär nach, ob ein Patch für das Zielsystem relevant ist. Dies geschieht durch eingestellte Abhängigkeiten von anderen Softwarepaketen oder Patches. Sind die neuen Patches zu vorhandenen inkompatibel oder nicht mehr nötig - etwa weil ein Service Pack diese Aufgabe bereits löst - , wird dies in der Regel nicht erkannt. Weitere Probleme: Reporting und Statusermittlung sind nicht auf die speziellen Bedürfnisse des Patch-Managements ausgelegt. Eine Aussage über den aktuellen Sicherheitsstand liefern diese Lösungen ebenfalls nicht. (ave)