<b>Zeit zum Einkaufen </b>
Patch-Management-Werkzeuge sind oft Bestandteil von Software-Distributions-, -Provisioning- und -Konfigurationsmanagement-Suites. Diese Suites sind anfänglich teurer, wachsen aber mit den steigenden Anforderungen der Organisation. Sind sie ihr Geld wert? Das hängt davon ab, welche Typen von Patches zu verteilen sind. Wer nicht nur für Server und Desktops, sondern auch für Netzwerkgeräte verantwortlich ist, für den ist ein Werkzeug, das mit all diesen Dingen umgehen kann, es vielleicht wert. Ein Beispiel für eine solche Suite ist HPs Opsware. Sind lediglich Desktops zu bedienen, empfiehlt es sich, schlankere Produkte zu berücksichtigen, beispielsweise CAs Patch-Management. Wer Server-Patching benötigt, muss sich fragen, ob er nur Windows-Systeme oder auch Unix-, Linux- oder virtualisierte Systeme hat.
Die Automation zu maximieren ist wichtig. Manuelles Patching ist ein nicht akzeptabler, arbeitsintensiver Prozess. Ein guter Gedanke ist es, eine detaillierte Liste zu erstellen, die jeden Schritt des Patch-Prozesses enthält: vom Sammeln der Patch-Informationen bis zur Bestimmung des Schweregrades und der Priorität, bis zum detaillierten Staging und bis zur Entscheidung, welche Endpunkte aktualisiert werden. Kann die in die Wahl genommene Software alle diese Schritte automatisieren?
Die Änderungskontrolle ist ebenfalls wichtig. Wie oft und wann werden Patches verteilt? Wer verteilt und/oder autorisiert Updates? Wie werden Patches vor dem Rollout getestet? Welche Probleme löst ein Rollback aus? Alle diese kritischen Fragen definieren einen Gesamtprozess. Network Computing sind Organisationen bekannt, die mit dem Patching von Applikationen mehr als einen Monat hinterher hinken und damit für Viren und Sicherheitsverletzungen offen sind.
Natürlich sollte die IT wissen, wie viele verwaltete Geräte sie hat und in naher Zukunft haben wird. Die Hersteller offerieren Software für das Management von 50 bis zu mehreren 100000 Geräten. Größere Unternehmen, die an auf die Konfiguration bezogene Produkte denken, beispielsweise Software-Distribution oder CMDB, sollten darauf achten, dass robuste Patch-Management-Fähigkeiten enthalten sind. Organisationen, die ein Asset- und Inventar-Management-System haben, sollten prüfen, ob sich die Patch-Management-Funktion integrieren lässt, um keine Discovery durchführen zu müssen.
Nicht durchdachtes Patching kann sich negativ auf Endbenutzer und das Netzwerk auswirken. Darum ist zu untersuchen, wie Produkte umgehen mit der Utilization und mit Geräten, die zum Patch-Zeitpunkt nicht verbunden sind. Nutzt das Produkt die Netzwerkbandbreite effizient, beispielsweise durch Multicast-Distribution, erweiterte Komprimierung, Checkpoint- und Restart-Fähigkeiten? Was passiert, wenn die Verbindung abbricht, das Endgerät offline ist oder die Patch-Installation aus irgendeinem Grund fehlschlägt? Idealerweise nutzt die Software eine Methode, die versucht, die Applikation erneut zu patchen. Erst wenn das Patching wiederholt keinen Erfolg hat, sendet sie eine Benachrichtigung.
Das Produkt sollte Auditing unterstützen und Benachrichtigungen senden. Damit bietet es einen tieferen Einblick in die Arbeit der Patch-Management-Applikation. Für viele Organisationen ist dies eine strikte Forderung.