Auch ich hasse Patches...

Jesper M. Johansson, Ph.D., CISSP, MCSE, MCP+I, Security Program Manager, Microsoft Corporation

Willkommen bei unserer Artikelserie zum Thema IT-Sicherheitsmanagement. In diesem Artikel werden wir uns mit Patches beschäftigen, einige „Geheimnisse“ in diesem Zusammenhang lüften und untersuchen, welche Auswirkungen sie auf die Sicherheit einer IT-Infrastruktur haben. Als ich anfing, diese Artikelserie zu schreiben, hatte ich nicht vor, mich mit Patches zu befassen. In allen Gesprächen rund um das Thema stellte sich jedoch heraus, dass ein entsprechender Bedarf besteht. Das Thema ist so wichtig, dass ich es nicht ignorieren kann. Daher also der vorliegende Artikel zu Patches. Er ist ein wenig länger als gewöhnlich, weil ich hoffe, keinen weiteren derartigen Artikel schreiben zu müssen. Das ist zumindest mein Plan! Es sei denn, bei der Patchverwaltung treten erhebliche Änderungen auf. Zukünftige Beiträge werden sehr wahrscheinlich wieder kürzer sein. Wie immer richtet sich dieser Artikel jedoch nach Ihren Wünschen. Wenn Sie sich für ein Thema interessieren, klicken Sie auf den Link „Feedback“, und teilen Sie mir Ihre Wünsche mit.

Auf dieser Seite

	Einleitung
	Was ist ein Patch?
	Testen von Sicherheitsupdatetests
	Tools zum Verwalten von Sicherheitsupdates
	Technische Detailtipps
	Schlussfolgerung

Einleitung

Das, was Sicherheitsadministratoren oft am meisten hassen, sind sicherlich kriminelle Hacker. Gleich danach kommen jedoch Patches. (Wenn ich im Folgenden von „Patch“ spreche, beziehe ich mich im Wesentlichen auf Sicherheitspatches.) Patches sind ein ewiges Reizthema. Jeder hasst sie – Entwickler, die sie erstellen müssen, Softwarehersteller, die sie vertreiben müssen und Administratoren, die sie implementieren müssen. Wahrscheinlich gibt es nur drei Gruppen, die Patches mögen: Softwarehersteller, die Patchverwaltungs-Lösungen verkaufen, Berater, die sie bereitstellen, und Sicherheitsexperten, die die Offenlegung von Schwachstellen als Marketinginstrument nutzen. Auch ich hasse Patches. Patches unterbrechen den normalen Arbeitsablauf und zwingen uns zu Wartungsarbeiten. Niemand mag Reparaturmaßnahmen, schon gar nicht, wenn nicht ersichtlich ist, ob überhaupt ein Schaden vorliegt. Das ganze Ausmaß des Schadens wird jedoch häufig erst deutlich, wenn wir unsere Netzwerke nicht sofort durch Patches schützen.

Ein perfekter Patch würde sich dadurch auszeichnen, dass er völlig unbemerkt installiert wird, keine Sekunde Ausfallzeit verursacht und keinerlei Auswirkungen auf die verwendeten Anwendungen hat. Zurzeit lässt sich davon jedoch nur träumen. Patches werden veröffentlicht, um bestimmte Sicherheitsanfälligkeiten zu beheben, die Angreifer ausnutzen könnten. Aus diesem Grund werden sie normalerweise in einem viel engeren Zeitrahmen als übliche Produktversionen veröffentlicht. Für ein Betaprogramm oder umfassende Kompatibilitätstests steht häufig nicht genügend Zeit zur Verfügung. Deswegen können Patches nicht so ausgiebig getestet werden wie eine vollständige Produktversion. Dies bedeutet, dass Patches gelegentlich Probleme verursachen können. Nichts ist komplexer als Software. Nichts ist mit so vielen Interdependenzen und weit reichenden Konsequenzen verbunden. Eine kleine und scheinbar belanglose Änderung in einer Komponente kann problemlos ein anderes Softwaremodul beeinträchtigen. Dies ist wie bei anderen Softwareaktualisierungen auch bei Patches manchmal der Fall. Ein unglücklicher Umstand, aber leider die Wahrheit. Die einzige Lösung besteht darin, die Notwendigkeit von Patches zu vermeiden. Dies gilt sowohl für Sie als Sicherheitsadministrator als auch für Ihren Softwarehersteller. In zukünftigen Artikeln werden wir zeigen, was Sie zum Schutz Ihres Netzwerks unternehmen können, damit sie hoffentlich eine geringere Anzahl von Patches installieren müssen. Wir als Hersteller müssen gemäß der Microsoft-Initiative „Trustworthy Computing“ unser Hauptaugenmerk auf eine verbesserte Softwarequalität richten und einfache, sichere Software-Updates ermöglichen. Diese Anstrengungen zahlen sich in der Tat aus. Für Windows Server 2003 sind weniger Patches als für Windows 2000 erforderlich. Außerdem ist der Schweregrad der Sicherheitsanfälligkeiten geringer. In den ersten 180 Tagen nach der Veröffentlichung von Windows 2000 wurden 32 Patches veröffentlicht, von denen fünf den Schweregrad „Kritisch“ aufwiesen. Für Windows Server 2003 waren im gleichen Zeitraum 13 Patches erforderlich, von denen nur zwei kritisch waren. Dies hilft Ihnen jedoch wenig, wenn Sie Windows Server 2003 aus bestimmten Gründen noch nicht implementieren können. Und außerdem ist jeder Patch ein Patch zuviel. Schon ein einziger Patch kann zu Instabilität führen und Ihre Arbeitsabläufe unterbrechen.

Da Patches Probleme verursachen können, höre ich häufig von Benutzern, dass sie Patches aufgrund von Instabilitäten nicht installieren werden. Aber bedenken Sie dabei, warum Patches überhaupt veröffentlicht werden – um die Ausnutzung einer Sicherheitsanfälligkeit zu verhindern. Wenn Sie denken, dass die Installation von Patches ein System instabil macht, was glauben Sie dann, wird bei einem Angriff auf das System geschehen? Wenn die Stabilität Ihrer Systeme auf der Hoffnung beruht, dass Sie schon nicht angegriffen werden, stehen sie ohne Zweifel auf der Verliererseite. Vergessen Sie auch nicht den Aufwand, den Sie betreiben müssen, um das System zu bereinigen: Vorsorge ist in der Regel mit weniger Aufwand verbunden als „den Karren aus dem Dreck ziehen“ zu müssen. Wir werden aber im nächsten Artikel auch zeigen, wie Sie nach einem erfolgten Hackerangriff vorgehen können.

Zum Seitenanfang

Was ist ein Patch?

Nun, dieser Begriff kann mehrere Bedeutungen haben. Microsoft verwendet sehr spezielle Bezeichnungen im Zusammenhang mit Patches. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 824684. Wenn Sicherheitsadministratoren den Begriff „Patch“ verwenden, meinen sie normalerweise eigentlich ein „Sicherheitsupdate“. Es gibt auch andere Patchtypen, die nichts mit Sicherheit zu tun haben. Da sich diese Artikelserie jedoch mit dem Thema Sicherheit beschäftigt, interessieren uns hauptsächlich Sicherheitsupdates.

Nach der offiziellen Definition ist ein Sicherheitsupdate eine in breitem Umfang veröffentlichte Behebung eines Sicherheitsproblems, das für den Angriff auf ein System ausgenutzt werden kann: ein Sicherheitsproblem, das bereits ausgenutzt wurde, öffentlich bekannt gegeben wurde oder in Kürze bekannt gegeben wird. Die erste Kategorie von Sicherheitsupdates ist die schlimmste. Dabei handelt es sich um so genannte „Zero-Day-Sicherheitsanfälligkeiten“ (Tag Null). Bei dieser Art von Sicherheitsanfälligkeit wird der Hersteller nicht informiert, bevor das Problem durch einen Angreifer ausgenutzt wird. Glücklicherweise sind diese Fälle selten – bei Windows sogar seltener als bei Unix/Linux. Meines Wissens gab es weniger als eine Handvoll solcher Vorkommnisse auf der Windows-Plattform. Die zweite Kategorie betrifft Probleme, die in einem öffentlichen Forum bekannt gegeben werden, ohne zunächst den Hersteller zu benachrichtigen. In wenigen Fällen wurden solche Probleme auf kriminelle Weise ausgenutzt, bevor der Hersteller Maßnahmen zu deren Beseitigung ergreifen konnte. Dies führte zu dem Ruf nach „verantwortungsvoller Offenlegung“ (responsible disclosure), damit der Hersteller Maßnahmen zur Beseitigung des Problems ergreifen kann, bevor der Entdecker der Schwachstelle sein Wissen bekannt gibt. Unglücklicherweise missachten einige Sicherheitsanalysten aus unerfindlichen Gründen diese sozialen Verhaltensregeln. Sie nehmen das Risiko für Benutzer und Firmen in Kauf und veranlassen Hersteller, unter Zeitdruck Sicherheitsupdates zu veröffentlichen, die möglicherweise nicht die gleiche Qualität wie ein sorgfältig entwickeltes und getestetes Service Pack aufweisen. Die meisten der Sicherheitsupdates, die zurückgerufen und erneut freigegeben wurden, fielen in diese Kategorie. Im Gegensatz dazu meldet der Entdecker der Schwachstelle bei der dritten Kategorie das Problem an den Hersteller und gibt diesem vor der Bekanntmachung ausreichend Zeit, das Problem zu beheben. Eine Variante, die in dieser Liste augenscheinlich fehlt, sind Fehlerbehebungen für Sicherheitsanfälligkeiten, die der Hersteller gefunden hat. In seltenen Fällen (wenn davon ausgegangen wird, dass ein solches Problem extern bekannt ist oder die Wahrscheinlichkeit der Entdeckung hoch ist), kann ein Hersteller ein Sicherheitsupdate für ein intern entdecktes Sicherheitsproblem veröffentlichen. Diese intern gefundenen Sicherheitsanfälligkeiten werden häufig während der Entwicklung eines Sicherheitsupdates für ein extern erkanntes Sicherheitsproblem in der gleichen Komponente entdeckt. In diesen Fällen behebt das Sicherheitsupdate dann normalerweise alle Probleme. Bei einigen intern entdeckten Sicherheitsanfälligkeiten wird die Fehlerbehebung erst später in ein Service Pack aufgenommen. Service Packs werden im Allgemeinen viel umfassender getestet als Sicherheitsupdates; sie führen mit wesentlich geringerer Wahrscheinlichkeit zu Stabilitätsproblemen. Außerdem erreichen Service Packs eine breitere Masse als Sicherheitsupdates, da viele Benutzer ausschließlich Service Packs installieren. Solange das Risiko für Benutzer als gering eingeschätzt wird, ist es normalerweise wünschenswert, die Fehlerbehebung bis zur Freigabe eines Service Packs zurückzuhalten. Es wurde schon häufig der Wunsch geäußert, dass Hersteller sämtliche Informationen zu einem Sicherheitsupdate öffentlich zur Verfügung stellen und den Benutzern die Entscheidung überlassen sollten, ob sie das Update zur Fehlerbehebung installieren möchten. Um zu beurteilen, ob dieser Wunsch sinnvoll ist, kann man die Heisenbergsche Unschärferelation zu Rate ziehen: Indem eine Größe gemessen wird (in diesem Fall das Risiko), wird diese auch verändert. Wie lässt sich Risiko definieren? Risiko ist eine abhängige Größe:

Eine Variante, die in dieser Liste augenscheinlich fehlt, sind Fehlerbehebungen für Sicherheitsanfälligkeiten, die der Hersteller gefunden hat. In seltenen Fällen (wenn davon ausgegangen wird, dass ein solches Problem extern bekannt ist oder die Wahrscheinlichkeit der Entdeckung hoch ist), kann ein Hersteller ein Sicherheitsupdate für ein intern entdecktes Sicherheitsproblem veröffentlichen. Diese intern gefundenen Sicherheitsanfälligkeiten werden häufig während der Entwicklung eines Sicherheitsupdates für ein extern erkanntes Sicherheitsproblem in der gleichen Komponente entdeckt. In diesen Fällen behebt das Sicherheitsupdate dann normalerweise alle Probleme. Bei einigen intern entdeckten Sicherheitsanfälligkeiten wird die Fehlerbehebung erst später in ein Service Pack aufgenommen. Service Packs werden im Allgemeinen viel umfassender getestet als Sicherheitsupdates; sie führen mit wesentlich geringerer Wahrscheinlichkeit zu Stabilitätsproblemen. Außerdem erreichen Service Packs eine breitere Masse als Sicherheitsupdates, da viele Benutzer ausschließlich Service Packs installieren. Solange das Risiko für Benutzer als gering eingeschätzt wird, ist es normalerweise wünschenswert, die Fehlerbehebung bis zur Freigabe eines Service Packs zurückzuhalten. Es wurde schon häufig der Wunsch geäußert, dass Hersteller sämtliche Informationen zu einem Sicherheitsupdate öffentlich zur Verfügung stellen und den Benutzern die Entscheidung überlassen sollten, ob sie die Fehlerbehebung installieren möchten. Dabei ist jedoch die Heisenbergsche Unschärferelation zu beachten: Indem eine Größe gemessen wird (in diesem Fall das Risiko), wird diese auch verändert. Wie lässt sich Risiko definieren? Risiko ist eine abhängige Größe:

Risiko = Schadenspotenzial * Wahrscheinlichkeit des Eintrittes des Schadens

Damit Benutzer das Risiko überhaupt einschätzen können, muss der Hersteller Informationen zu dem jeweiligen Problem veröffentlichen. Die Informationen sind somit auch Personen zugänglich, die daran interessiert sind, die Sicherheitsanfälligkeit für einen Angriff auszunutzen. Da Angreifer auf diese Weise genau herausfinden können, wie das Problem ausgenutzt wird, steigt das Risiko in erheblichem Maße. Wie bereits erwähnt, wurde bis heute nur ein extrem kleiner Prozentsatz von Sicherheitsanfälligkeiten auf der Windows-Plattform ausgenutzt, bevor der Hersteller ein Sicherheitsupdate veröffentlicht hat. Diese Tatsache zeigt deutlich, dass Angreifer durch die Veröffentlichung ausführlicher Informationen zu einem Sicherheitsproblem die Schwachstelle leichter ausnutzen können. Dies mag sich in Zukunft ändern, ist jedoch heute noch der Fall.

Bedenken Sie bitte, dass Hersteller Sicherheitsupdates nicht veröffentlichen, um Ihnen das Leben schwer zu machen. Benutzer und Administratoren müssen zwar erhebliche finanzielle Mittel in die Verwaltung von Sicherheitsupdates investieren, aber auch für den Hersteller sind die Auswirkungen enorm, sowohl in finanzieller Hinsicht als auch in Bezug auf Glaubwürdigkeit und Vertrauen. Deshalb wird auch mit Nichten die Veröffentlichung eines Sicherheitsupdate auf die leichte Schulter genommen.

Bei jeder Veröffentlichung eines Sicherheitsupdates müssen Sie unverzüglich klären, ob und wann es installiert werden soll. Dies ist einfach Teil des täglichen Jobs. Wenn dafür nicht genügend Ressourcen zur Verfügung stehen, müssen Sie die Geschäftsleitung davon überzeugen, dass es sich um einen wichtigen Bestandteil des Sicherheitsmanagement handelt. In einem zukünftigen Artikel wird es darum gehen, wie die Geschäftsführung von Sicherheitsmaßnahmen überzeugt werden kann. Wenn Sie ebenfalls Ideen zu diesem Thema haben, würde ich mich über Ihren Beitrag freuen. Sie können mir Feedback schicken, indem Sie unten auf der Seite auf den Link „Kontakt“ klicken und Ihre Nachricht mit einem Link zu dieser Seite an TechNet senden. Insgesamt fällt es uns schwer, der Geschäftsführung das Thema Sicherheit näher zu bringen.

Einige Hersteller, einschließlich Microsoft, versehen einzelne Sicherheitsanfälligkeiten in einem Sicherheitsupdate mit einer Risikobewertung, um Ihnen bei der Beurteilung zu helfen, wie schnell ein Sicherheitsupdate bereitgestellt bzw. eingespielt werden sollte. Die Bewertungen des Schweregrads durch Microsoft sowie die zugehörigen Empfehlungen, wie schnell die Updates bereitgestellt werden sollten, sind in der folgenden Tabelle aufgeführt.

Sicherheitsupdates können auf drei Arten zur Verfügung gestellt werden. Das Update kann beispielsweise in einem Security Bulletin bereitgestellt werden und als Fehlerbehebung für eine oder mehrere Sicherheitsanfälligkeiten in einer Einzelkomponente dienen. Security Bulletins werden unter http://www.microsoft.com/germany/technet/sicherheit/bulletins/default.mspx bereitgestellt. bereitgestellt. Sie haben die Bulletins von uns noch nicht abonniert? Dann sollten Sie sich unter /germany/technet/datenbank/articles/430926.mspx registrieren.

Außerdem sind Sicherheitsupdates über Update Rollups erhältlich. Ein Update Rollup ist eine Sammlung von Sicherheitsupdates, in der auch andere Updates enthalten sein können. Häufig ist das mit einem Security Bulletin veröffentlichte Update in Wirklichkeit ein Update Rollup. Alle Sicherheitsupdates für Internetinformationsdienste (IIS) sind zum Beispiel jetzt Rollups, die auch die Fehlerbehebungen für alle früheren Probleme enthalten.

Die dritte Möglichkeit, Sicherheitsupdates zu erhalten, besteht in der Installation von Service Packs. Ein Service Pack ist eine getestete, kumulative Sammlung aller Hotfixes, Sicherheitsupdates, wichtiger Updates und anderer Fehlerbehebungen. Ein Service Pack kann auch Sicherheitsupdates für Probleme enthalten, die intern bei Microsoft während der Entwicklung des Service Packs entdeckt wurden. Wenn ein Service Pack veröffentlicht wird, werden alle enthaltenen Fehlerbehebungen – einschließlich der intern bei Microsoft gefundenen Probleme – in einem Knowledge Base-Artikel dokumentiert. Auch wenn der Inhalt identisch ist, sind Service Packs Sicherheitsupdates vorzuziehen, da diese länger getestet wurden und ein umfassendes Betaprogramm durchlaufen haben.

Zum Seitenanfang

Testen von Sicherheitsupdatetests

Wenn zur Installation von Sicherheitsupdates aufgefordert wird, folgt immer die dringende Empfehlung, diese vor der Installation in der Produktionsumgebung zu testen. Sicherheitsupdates haben den schlechten Ruf, die Stabilität zu beeinträchtigen. Tatsache ist aber, dass weitaus die meisten Sicherheitsupdates keine Stabilitätsprobleme zur Folge haben. In den wenigen Fällen, in denen die Stabilität beeinträchtigt wird, kann dies jedoch auch relativ weit reichende Ausmaße annehmen. Ein Beispiel: Wenn ein Update auf 20 Millionen Computern installiert wird (keine sehr große Zahl bei einer weit verbreiteten Plattform wie Windows), und 0,01 % dieser Computer haben Probleme mit dem Update, entspricht dies einer Anzahl von 2.000 Computern. Diese Zahl macht deutlich, warum wir häufig von Problemen mit Sicherheitsupdates hören. Selbst wenn ein Problem nur eine sehr geringe Prozentzahl der Systeme betrifft und nur in speziellen Konstellationen auftritt, reicht dies unter Umständen aus, um die Aufmerksamkeit der Medien zu erlangen.

In seltenen Fällen liegen systeminterne Probleme in Sicherheitsupdates vor. Der Großteil der Probleme mit Sicherheitsupdates ist jedoch auf Anwendungen oder Änderungen an Standardkonfigurationen zurückzuführen. Dieses sind Gründe für die Empfehlung, das Update in der eigenen Umgebung zu testen. In Anbetracht der äußerst heterogenen Umgebungen, in denen Computersoftware eingesetzt wird, ist es unmöglich, alle Eventualitäten in einem Testdurchlauf zu berücksichtigen. Nur weil ein Sicherheitsupdate beispielsweise beim Testen keine Probleme verursacht hat, muss dies nicht bedeuten, dass auch dann keine Probleme auftreten, wenn es für eine Gaspumpe installiert wird, die unter Windows NT 4.0 Workstation gesteuert wird. Und wie sieht es mit einer Registrierkasse unter Windows XP Professional aus? Dies lässt sich nicht vorhersagen. Es gibt jedoch einige allgemeine Faustregeln, mit denen Sie den Umfang Ihrer Testdurchläufe verringern können.

Denn alle Sicherheitsupdates werden unter gängigen Konfigurationen getestet. Normalerweise können Sie davon ausgehen, dass Sicherheitsupdates, und insbesondere Service Packs, für das Windows-Betriebssystem mit unterstützten Versionen von Microsoft Office getestet wurden und umgekehrt. Bei Sicherheitsupdates für Anwendungen können Sie davon ausgehen, dass diese auf allen Plattformen getestet wurden, auf denen die Anwendung unterstützt ist. Außerdem werden Updates mit Hardware getestet, die in der Windows-Hardwarekompatibilitätsliste enthalten sind. Diese Hardware verfügt über das Windows-Logo des Betriebssystems, für das das jeweilige Update vorgesehen ist.

Was ist aber mit anderen, weniger weit verbreitetem Anwendungen von Drittanbietern? Werden SQL Server-Sicherheitsupdates auch auf einem System getestet, das auch SAP, PeopleSoft oder Siebel ausführt? Im Allgemeinen ist es Aufgabe des Drittanbieters (ISV), Sicherheitsupdates mit den eigenen Produkten zu testen. In einigen Fällen verfügt der Hersteller über eine bestimmte „Patchrichtlinie“ mit dem Hinweis, dass das jeweilige Produkt Patches nur dann unterstützt, wenn es auf einer speziell konfigurierten Plattform (einschließlich Service Packs) ausgeführt wird. In diesem letzteren Fall riskieren Sie, dass der Supportvertrag durch die Installation des Patches seine Gültigkeit verliert. Was also tun? Die Vorgehensweise hängt vom jeweiligen Sicherheitsupdate ab. Bei einem wichtigen Sicherheitsupdate haben Sie vier Möglichkeiten:

Wie Sie sehen können, ist die Antwort nicht so einfach. Befolgen Sie Schritt 1, ist die Wahrscheinlichkeit gegeben, dass Sie selbst Opfer eines Hackerangriffs werden. Die Möglichkeit 2 ist etwas riskant, wenn Sie beim Testen etwas vergessen. Es handelt sich jedoch um die beste Möglichkeit, insbesondere in Kombination mit Möglichkeit 4. Viele Drittanbieter sind hinsichtlich Sicherheitsupdates erheblich in Verzug. Wenn Sie nur einige Produkte nur auf den Plattformen ausführen, für die sie vorgesehen sind, das heißt also in der Regel ohne aktuelle Sicherheitsupdates, wird Ihr IT-Betrieb unter Umständen in Kürze durch Hacker lahm gelegt.

Es gibt ein sinnvolles neues Verfahren für den Erhalt eines beinahe perfekten Replikats eines Produktionssystems, das Sie zum Testen verwenden können. Microsoft Virtual PC 2004 enthält eine Funktion zum Erstellen eines neuen virtuellen Datenträgers auf der Basis einer vorhandenen Festplatte. Mit dieser Funktion können Sie Virtual PC auf einem Produktionssystem installieren (vielleicht nicht gerade auf einem System, das zurzeit Anwendungen für Clients zur Verfügung stellt) und dann ein Replikat seiner Festplatte erstellen. Anschließend können Sie dieses Datenträgerabbild auf einen anderen Computer kopieren. Nun installieren Sie Virtual PC auf dem anderen Computer und generieren eine neue VM (Virtual Machine oder virtueller Computer), die auf das soeben erstellte Datenträgerabbild verweist. Beim ersten Startvorgang der VM sind möglicherweise einige Treiber neu zu installieren. Sie können die VM dann jedoch in einem rückgängig zu machenden Modus einrichten und verfügen über eine Kopie eines Produktionssystems, mit der Sie neue Sicherheitsupdates testen können. Natürlich funktioniert diese Vorgehensweise nicht bei jeder Art von Test, zum Beispiel Tests mit bestimmter Hardware, die nicht von Virtual PC emuliert wird. Sie funktioniert jedoch recht gut, wenn die Interoperabilität mit Software getestet werden soll. In finanzieller Hinsicht ist dieses Verfahren wesentlich günstiger als der Erwerb und die Verwaltung zusätzlicher Hardware, da Virtual PC vergleichsweise sehr günstig ist.

Zum Seitenanfang

Tools zum Verwalten von Sicherheitsupdates

Ich kann keinen Artikel zur Patchverwaltung schreiben, ohne auf die Tools zu verweisen, die Ihnen bei der Patchverwaltung helfen können. Im Allgemeinen sind die Patchverwaltungstools von Microsoft kostenlos. Dies gilt für alle hier genannten Produkte, wenn nichts anderes vermerkt wird.

MBSA

Microsoft Baseline Security Analyzer (MBSA) ist ein kostenloses Tool von Microsoft für die Überprüfung von Systemen bezüglich fehlender Sicherheitsupdates und vieler anderer potenziell gefährlicher Konfigurationen und Einstellungen. Dieses Tool ist unter http://www.microsoft.com/mbsa (englischsprachig) oder http://download.microsoft.com/download/0/3/1/0313a008-9dbd-4cb1-ac4d-47bec92bbebd/MBSASetup-DE.msi deutschsprachig verfügbar.

MBSA ist streng genommen ein Patchscanner und kein Sicherheitsanfälligkeitenscanner. Der Unterschied zwischen beiden besteht darin, dass ein Patchscanner hauptsächlich untersucht, ob ein Sicherheitsupdate installiert ist, und nicht notwendigerweise darüber informiert, ob ein fehlendes Sicherheitsupdate ein tatsächliches Sicherheitsproblem darstellt. Wenn Sie beispielsweise einen Webserver unter Windows Server 2003 ausführen, erhalten Sie möglicherweise die Information, dass ein Sicherheitsupdate für ein Sicherheitsproblem in NetBIOS fehlt, das zur Offenlegung von Daten führen kann. Da der Webserver jedoch hinter einer Firewall geschützt ist oder NetBIOS deaktiviert ist, ist das Fehlen dieses Sicherheitsupdates vertretbar. Abgesehen von dieser Unterscheidung müssen Sie zum Ausführen des Patchscanners außerdem über administrative Rechte verfügen und es müssen bestimmte Dienste auf dem Zielcomputer, der überprüft wird, vorhanden sein. MBSA erfordert zum Beispiel, dass der Server-Dienst auf dem zu überprüfenden Computer ausgeführt wird. Ein „echter“ Sicherheitsanfälligkeitsscanner wie der ISS Internet Scanner, legt das Hauptaugenmerk auf tatsächliche Sicherheitsprobleme, die ein Angreifer ausnutzen könnte, um einem System Schaden zuzufügen. Aus diesem Grund benötigt ein Sicherheitsanfälligkeitsscanner normalerweise keine Rechte auf dem Zielsystem. Er untersucht das System einfach vom Standpunkt eines Angreifers aus.

Die MBSA-Software, Version 1.2, wurde Anfang 2004 veröffentlicht und weist im Vergleich zur Vorgängerversion folgende neue Funktionen auf:

Lösung für Endbenutzer bzw. Privatanwender: Automatische Updates

Für Endbenutzer zeichnet sich ein optimales Sicherheitsupdate dadurch aus, dass sie sich keine weiteren Gedanken darüber machen müssen. Der Dienst für automatische Updates, „Windows Update“ (WU), wurde dafür konzipiert. Er benachrichtigt Benutzer nicht nur über neue verfügbare Windows-Sicherheitsupdates, sondern kann auch so konfiguriert werden, dass die Aktualisierungen automatisch downloadet und installiert werden. Dies ist die bevorzugte Lösung, weil sie auch dann funktioniert, wenn keine Administratoren angemeldet sind. Denken Sie jedoch daran, dass der Dienst für automatische Updates das System dann automatisch neu startet, wenn ein Sicherheitsupdate einen Neustart erfordert. Dadurch ist der Dienst für automatische Updates für Server ungeeignet.

Lösung für kleine und mittelgroße Netzwerke: Software Update Services und Dienst für automatische Updates

In kleinen Netzwerken besteht die beste Lösung in der Regel einfach im Konfigurieren des Dienstes für automatische Updates auf allen Clients und anschließenden manuellen Aktualisieren des oder der Server(s). Und wie sollten Sie vorgehen, wenn Sie mit benutzerdefinierten oder seltenen Anwendungen arbeiten, mit denen die Updates getestet werden sollen, bevor diese im gesamten Netzwerk bereitgestellt werden? Dann sind die Software Update Services (SUS) die richtige Wahl für Sie. SUS ist ebenfalls ein kostenloses Tool von Microsoft, das Ihnen einen eigenen WU-Server zur Verfügung stellt. WU stellt Ihren Benutzern alle verfügbaren Sicherheitsupdates zur Verfügung; SUS verteilt sie jedoch nur an den von Ihnen ausgewählten Personenkreis. Der Dienst für automatische Updates durchsucht ein System normalerweise im Vergleich zur Basis des Sicherheitsupdatekataloges, der durch WU veröffentlicht wurde. Wenn Sie jedoch über einen SUS-Server verfügen, können Sie den Dienst für automatische Updates so konfigurieren, dass er die Suche im Vergleich zum Katalog dieses Server durchführt. Auf diese Weise stellen Sie sicher, dass alle Clients über genau die von Ihnen gewünschten Betriebssystemupdates verfügen.

Lösung für größere Unternehmen: Systems Management Server

Wenn Sie bereits über ein Enterprise Management System (EMS) wie Microsoft Systems Management Server (SMS), Tivoli, CA Unicenter usw. verfügen, können Sie auch dieses zum Verteilen der Sicherheitsupdates einsetzen. SMS 3.0 und ein Feature Pack für SMS 2.0 verleiht SMS die gleiche Flexibilität, die auch SUS besitzt – mit den zusätzlichen Funktionen eines professionellen EMS. SMS ist nicht kostenlos. Sobald Sie jedoch über diese Infrastruktur verfügen, vereinfacht das Feature Pack deren Einsatz zum Verteilen von Sicherheitsupdates erheblich.

Für welches Produkt soll ich mich entscheiden?

Wenn keine andere Verwaltungslösung eingesetzt wird und Sie weniger als ca. 500 Clients aktualisieren müssen, ist im Allgemeinen SUS und der Dienst für automatische Updates die beste Lösung. Wenn mehr als 500 Clients aktualisiert werden müssen, sollten Sie eine Verwaltungslösung für Unternehmen wie SMS in Betracht ziehen, weil ein solches Produkt ein breiteres Aufgabenspektrum als nur Updates erledigen kann. Wenn Sie bereits EMS einsetzen, sollten Sie prüfen, ob Sie die Software nicht auch zum Installieren von Updates verwenden können. Wenn ein sehr kleines Netzwerk betrieben wird und kein Bedarf hinsichtlich einer zentralisierten Verwaltung besteht, können Sie den Dienst für automatische Updates nutzen und diesen so konfigurieren, dass Windows Update abgefragt wird (dies ist die Standardeinstellung). Weitere Informationen zum Auswählen einer Patchverwaltungslösung finden Sie auf der Microsoft-Website (in Englisch). Wenn Sie technische und ausführlichere Anleitungen benötigen, evaluieren Sie die Lösung für die Patchverwaltung von Microsoft.

Vergessen Sie Ihre Anwendungen nicht!

SUS, der Dienst für automatische Updates und Windows Update verteilen zurzeit Betriebssystem-Sicherheitsupdates. Und wie sieht es mit Ihren Anwendungen aus? Microsoft arbeitet intensiv an der Integration der Updateverteilungslösungen; zurzeit werden Updates für Anwendungen jedoch noch separat verteilt. Nutzen Sie die folgenden Adressen:

Zum Seitenanfang

Technische Detailtipps

Und wie sieht es mit Ihren Servern aus? Alle oben beschriebenen Lösungen beziehen sich im Grunde nur auf Clients. Wie können Sie die Server aktualisieren? Der erste Schritt besteht im Suchen nach den Updates. Alle Microsoft-Sicherheitsupdates finden Sie auf der TechNet-Website. Im zweiten Schritt müssen Sie die Updates natürlich installieren. Zu diesem Zweck können Sie mehrere Techniken anwenden. Bitte denken Sie unbedingt daran, dass es sich hierbei um fortgeschrittene Techniken handelt. Sie sollten nur von Spezialisten angewandt werden, und auch dann nur nach sorgfältiger Untersuchung und Erfahrung mit der betreffenden Technik, der Zielapplikation und dem Update. Diese Techniken sind nicht für die Verwendung durch Endbenutzer geeignet.

Microsoft arbeitet daran, noch bessere Updateinstallationsprogramme zu entwickeln. Eine (für Microsoft) neue Technik sind Hot-Patches, durch die Code im Speicher aktualisiert werden kann, während dieser ausgeführt wird. Durch Hot-Patching wird die tatsächlich ausführbare Datei auf der Festplatte erst ersetzt, nachdem der Dienst oder die Anwendung heruntergefahren wurde. Dies geschieht normalerweise beim nächsten Neustart. Denken Sie daran, dass der Benutzer, der das Update installiert, für diese Technik die Berechtigung „Debug Programs“ besitzen muss. Wenn Sie diese Berechtigung aus der Gruppe Administratoren entfernt haben, müssen Sie sie zumindest den Konten erneut erteilen, die Updates installieren. Leider besitzt Hot-Patching auch Nachteile – Hot-Patches können nicht durch Slip-Streaming in einen Installationspunkt integriert werden.

Eine weitere Technik, die in die neuen Installationsprogramme integriert wurde, ist Warm-Patching. In diesem Fall versucht der Update Installer, die Anwendung(en), die die Dateien im Update verwendet, vor der Installation zu schließen. Dies ist ein wichtiger Aspekt, weil ein System nach der Patchinstallation häufig neu gestartet werden muss, da das Update gerade verwendete Dateien aktualisiert. Durch das Herunterfahren des Dienstes vor der Patchinstallation können Sie den Neustart des Systems nach der Installation des Updates vermeiden. Diese Vorgehensweise ist unter allen Umständen schneller als ein vollständiger Neustart des Systems. Warm- und Hot-Patching funktioniert systembedingt jedoch nicht für alle Sicherheitsupdates. Möglicherweise können Sie den gleichen Effekt jedoch auch manuell erzielen.

Minimieren von Neustarts durch sorgfältige Prüfung

Eine Möglichkeit, den Effekt von Warm-Patching manuell zu erzielen, besteht in einer sorgfältigen Prüfung des Sicherheitsupdates und anschließenden Deaktivieren der Objekte, die die zu aktualisierenden Dateien verwenden. Beispielsweise beim Bereitstellen eines IIS-Sicherheitsupdates in einer großen Serverfarm: Der erste Schritt besteht im Entpacken des Updates selbst und Abrufen einer Liste der darin enthaltenen Dateien. Sie können zu diesem Zweck die ausführbare Updatedatei mit der Option /x ausführen oder ein Tool wie WinZip verwenden. Nun verfügen Sie über ein Verzeichnis mit den im Update enthaltenen Dateien. Abhängig von Updatetyp können Sie update.exe, update.inf und die meisten restlichen Dateien im Stammverzeichnis des Updates ignorieren. Sie gehören zum Update Installer und werden nicht tatsächlich installiert. Im nächsten Schritt müssen Sie herausfinden, welche Anwendungen diese Dateien geöffnet halten. Beginnen Sie mit dem Erstellen einer Dateiliste. Downloaden Sie dann eine Kopie des empfehlenswerten Tools Process Explorer von System Internals (http://www.sysinternals.com; in Englisch). Process Explorer ist Windows Task-Manager sehr ähnlich, weist jedoch leistungsstärkere Funktionen auf. Process Explorer zeigt nicht nur die ausführbaren Dateien an, die aktuell ausgeführt werden. Das Tool zeigt außerdem die Handles an, die diese Dateien geöffnet haben. „Handle“ bedeutet in diesem Zusammenhang, dass das Programm ein bestimmtes Objekt geöffnet hält. Ein IIS-Sicherheitsupdate kann zum Beispiel die Datei w3svc.dll betreffen. Klicken Sie auf Find:Find DLL…, geben Sie w3svc.dll ein, und drücken Sie dann die Eingabetaste. Sie werden sehen, dass inetinfo.exe in der Liste enthalten ist. Doppelklicken Sie nun im Ergebnisfenster auf inetinfo.exe. Dieser Vorgang schaltet das Hauptfenster in die DLL-Ansicht um (Sie können auch manuell in die DLL-Ansicht wechseln, indem Sie STRG+D drücken) und zeigt nicht nur w3svc.dll, sondern auch alle anderen DLL-Dateien an, die in den Prozess inetinfo.exe geladen werden. Doppelklicken Sie auf eine der DLL-Dateien, dann erhalten Sie ein Dialogfeld mit erweiterten Eigenschaften für diese DLL. Es werden Ihnen umfangreiche Informationen zu der betreffenden Datei zur Verfügung stellt. Nachdem Sie die Arbeit in Process Explorer beendet haben, notieren Sie sich alle Prozesse, die die Binärdateien im Update geöffnet halten.

Nun müssen Sie entscheiden, ob ein Neustart vermieden werden kann. Auf diese Frage gibt es keine einfache Antwort. Wenn jedoch viele Server mit einem Patch versehen werden müssen, lohnen sich einige Tests durchaus. In der Regel können Sie einen Neustart vermeiden, wenn Sie die Prozesse beenden können, die die Dateien im Update verwenden. Denken Sie jedoch daran, dass einige Dienste wie WMI (Windows Management Instrumentation) automatisch neu gestartet werden, wenn Sie versuchen, diese lediglich zu beenden. Alle benutzerdefinierten Skripts, die Sie zum Installieren der Updates verwenden, müssen daher entweder ein ordnungsgemäßes Herunterfahren des Systems gewährleisten (was der Dienst möglicherweise verhindert) oder den betreffenden Dienst zuerst deaktivieren und dann beenden. Sie können das Befehlszeilenprogramm sc.exe zum Verwalten von Diensten in einem Skript verwenden. Nachdem Sie herausgefunden haben, welche Dienste beendet werden müssen und wie dies geschehen kann, können Sie ein Skript schreiben, das alle im Folgenden genannten Aufgaben oder einen Teil davon durchführt:

Diese Vorgehensweise führt zwar noch immer zu Ausfallzeiten, ist einem vollständigen Neustart jedoch unbedingt vorzuziehen.

In Umgebungen mit Lastenausgleich können Sie Computer normalerweise außerhalb der Spitzenzeiten nacheinander einzeln offline schalten, den Patch installieren und den Betrieb anschließend erneut aufnehmen. In einer Clusterumgebung können Sie das gleiche Ergebnis erzielen, indem Sie Dienste vorübergehend mittels Failover auf andere Systeme im Cluster übertragen. Wenn diese Vorgehensweise aus bestimmten Gründen nicht möglich ist, unterstützt Sie die oben beschriebene Technik dennoch Zeit einzusparen, in dem Sie den Betrieb lediglich mit einer eingeschränkten Anzahl von Systemen aufrechterhalten müssen. Beachten Sie jedoch, dass der Einsatz von Clustern und Lastenausgleich zum Minimieren von Ausfallzeiten relativ komplex ist und im Vorfeld sorgfältig geplant werden muss. Sie können auch eine Batch-Updateinstallation durchführen, um mehrere Updates gleichzeitig zu installieren. So verhindern Sie mehrere Neustarts und können die Ausfallzeiten verringern. Die meisten Windows-Sicherheitsupdates sowie einige andere Updates unterstützen verschiedene Befehlszeilenoptionen, die Sie in Batchdateien verwenden können. Die Option /z eines typischen Windows-Sicherheitsupdates bedeutet beispielsweise „kein Neustart des Systems nach der Patchinstallation“. Dies bedeutet, dass Sie eine Batchdatei generieren können, die mehrere Sicherheitsupdates installiert (alle mit der Option /z). Der Neustart kann anschließend erfolgen. Folgende Optionen werden vom Tool update.exe für Windows-Sicherheitsupdates unterstützt:

Beachten Sie, dass nicht alle Updates dieses Installationsprogramm verwenden. Windows Media-Sicherheitsupdates sowie einige Internet Explorer-Sicherheitsupdates verwenden eine andere Syntax, ohne einer Entsprechung der Option /z. Wenn Sie nicht sicher sind, führen Sie zum Überprüfen die Syntax das Update mit der Option /? aus.

In einigen Fällen aktualisieren mehrere Sicherheitsupdates die gleichen Dateien. Dann muss die richtige Installationsreihenfolge unbedingt sichergestellt werden. Nutzen Sie dafür das Tool qchain. Eine Beschreibung dieses Tools finden Sie im Knowledge Base-Artikel 296861. Im Allgemeinen ist qchain jedoch nicht für Fehlerbehebungen erforderlich, die nach Dezember 2002 veröffentlicht wurden, da diese die in qchain enthaltenen Funktionen bereits aufweisen. Lesen Sie den Knowledge Base-Artikel, um weitere Informationen zu erhalten.

Schließlich können Sie benutzerdefinierte Installationen generieren, die die Sicherheitsupdates und Service Packs bereits enthalten. Dieser Vorgang, der als „Slip-Streaming“ bezeichnet wird, sprengt den Rahmen dieses schon jetzt sehr langen Artikels. Weitere Einzelheiten hierzu finden Sie jedoch in mehreren Knowledge Base-Artikeln sowie im Resource Kit.

Zum Seitenanfang

Schlussfolgerung

Patches sind für Systemadministratoren ein notwendiges Übel. Alle Systeme benötigen in einem gewissen Umfang Sicherheitsupdates, und die Verwaltung von Sicherheitsupdates erfordert ein Konzept mit optimalen Tools. Aber auch dann sind Patches nicht immer einfach und angenehm zu verwalten. In diesem Artikel wurden die Grundlagen der Patchverwaltung sowie einige fortgeschrittene Techniken zum Minimieren der Ausfallzeiten in einer Datacenter-Umgebung behandelt. Die zum Verwalten von Sicherheitsupdates zu verwendenden optimalen Techniken sind von der jeweiligen Umgebung abhängig und Sie müssen für sich entscheiden, wie diese Verwaltung erfolgen soll.

Mit zwei letzten Gedanken möchte ich mich von Ihnen verabschieden: Alles in diesem Artikel Gesagte ist abhängig von der Sicherheitsrichtlinie Ihrer Organisation. Sie können keine Patchverwaltungsstrategie entwerfen, ohne über eine Informationssicherheitsrichtlinie zu verfügen, die das Fundament aller Zielsetzungen für den sicheren Betrieb Ihrer IT-Umgebung ist. Dies ist insbesondere wichtig, wenn Sie sich schützen müssen, nachdem Sie die Server für die Patchinstallation offline schalten mussten oder etwas anderes schiefgegangen ist. Wenn in diesem Fall eine von der Geschäftsführung genehmigte Informationssicherheitsrichtlinie vorhanden ist, auf die verwiesen werden kann, kann das einen entscheidenden Unterschied machen – nämlich ob Sie nur zusätzliche Arbeit erledigen müssen oder sich der Jobsuche zuwenden dürfen.

Berücksichtigen Sie schließlich die Auswirkungen der Patchverwaltung auf die IT-Sicherheit. Macht das Vorhandensein aller Sicherheitsupdates Ihre Umgebung wirklich sicher? Nein. Sicherheit ist ein kontinuierlicher Prozess. Wenn Sie Sicherheitsupdates nicht installieren, steigt die Chance erheblich, von einem Hackerangriff betroffen zu sein. Wenn Sie Ihre Systeme bezüglich Sicherheitsupdates jedoch aktuell halten, können Sie sich ausführlicher mit den Sicherheitsproblemen befassen, die nicht auf Sicherheitsanfälligkeiten in den verwendeten Produkten zurückzuführen sind. Denken Sie einfach folgendermaßen darüber: Sobald Sie die Sicherheitsupdates installiert haben, können Sie sich mit den interessanten und komplexen Problemen der Betriebssicherheit eines Netzwerks beschäftigen. Die kommenden Artikel werden sich mit den verschiedenen Aspekten dieses Vorgangs befassen.

Zum Seitenanfang