Patch-Management ist keine Flickschusterei

In vernetzten Umgebungen ist jedes Gerät eine potenzielle Schwachstelle, nicht jede Sicherheitslücke führt indes zu Schäden und manches Heilmittel (»Patch«) ist schlimmer als die Krankheit, sprich: bringt ein potenziell gefährdetes System dann real zum Absturz. Nichts signalisiert die Problematik besser als das »Toolkit to Temporarily Block Delivery of Windows XP SP2 To a PC? «, ein von Microsoft bis vor kurzem bereit gestelltes Werkzeug, um die automatische Installation des Service Pack2 von Windows XP zu blockieren, falls die Gefahr besteht, dass das solcherart korrigierte System nach dem SP2-Patch abstürzt.  
Eine leistungsfähige Schwachstellen-Analyse für die Rundum-Sicherheit ­einer Konfiguration ist unabdingbar (siehe »Angriffs-Prophylaxe durch Schwachstellen-Management«, Information Week, 5/6, Seite 24 ff), darauf folgende Fehlerkorrekturen (»Patches«) sind indes gut zu überlegen und vorzubereiten. »Die Hersteller schicken ihre Patches zwar vor der Veröffentlichung zu Tests ins Labor«, sagt Nicolas Boudot, Vertriebsbeauftragter beim Patch-Spezialisten St. Bernard Software, aber »Untersuchungen in einer Test-Umgebung können die realen Bedingungen in einem Unternehmen mit maßgeschneiderten Applikationen und Legacy-Infrastrukturen nur unzureichend abbilden«. Für Boudot ergibt sich daraus die Konsequenz, das man nach einer Lösung suchen sollte, die einen Patch-Test im eigenen Netzwerk ermöglicht, bevor die »Flicken flächendeckend implementiert werden«. Die Gefahr einer »Verschlimmbesserung« ist derart gravierend, dass viele lebenskritische Systeme, so etwa in der Pharma-Produktion oder in Kraftwerken, überhaupt nicht gepatcht werden dürfen. »Es handelt  sich dabei um so genannte validierte Systeme, bei denen jede Änderung des Codes verboten ist beziehungsweise einen sehr großen organisatorischen Aufwand nach sich zöge«, sagt dazu Stefan Strobel, Geschäftsführer des Sicherheitsspezialisten Cirosec in Heilbronn.