Anleitung zur Verringerung von Sicherheitsbedrohungen unter Windows NT und Windows 98

Eine der Hauptmethoden zum Schutz vor Angriffen besteht darin, sicherzustellen, dass Ihre Umgebung stets mit allen erforderlichen Sicherheitspatches auf dem aktuellen Stand gehalten wird. Patches sind sowohl für Server als auch für Clients erforderlich. In diesem Kapitel wird gezeigt, wie Sie rechtzeitig auf neue Patches aufmerksam werden, diese schnell und zuverlässig im gesamten Unternehmen implementieren und wie Sie Systeme so überwachen, dass die Patches überall bereitgestellt werden. Es werden die Probleme bei der Implementierung der Patchverwaltung erläutert, und abschließend wird das Patchverwaltungssystem von Trey Research ausführlich beschrieben.

Auf dieser Seite

	Hintergrund
	Lösungsentwurf
	Implementierung
	Zusammenfassung

Hintergrund

Patchverwaltung ist ein entscheidender Bestandteil der Sicherheit von Informationen. Wenn in vorhandenem Programmcode neue Sicherheitslücken entdeckt werden oder neue Bedrohungen auftreten, veröffentlichen die Anbieter der Software Patches, die die Sicherheitslücken schließen oder neue Sicherheitsfunktionen bereitstellen sollen. Unternehmen wie Trey Research müssen rasch ermitteln können, für welche Computer welche Patches erforderlich sind, und diese dann entsprechend implementieren. Dies muss in einer einheitlichen und wiederholbaren Weise erfolgen, da in dem Fall, dass auch nur bei wenigen Computern kein Patch vorhanden ist, das gesamte Netzwerk angreifbar ist.

Zum Seitenanfang

Lösungsentwurf

Wie Sie die Patchverwaltung genau umsetzen, hängt von der Größe und Komplexität Ihres Unternehmens ab. Es ist jedoch entscheidend, dass Ihnen die Bedeutung der Patchverwaltung und wie sie sich in die Gesamtstrategie zum Risikomanagement Ihres Unternehmens einfügt, bewusst ist.

Wenn Sie zum Beispiel entscheiden, dass das Risiko ohne Rücksicht auf anfallende Kosten so gering wie möglich gehalten werden muss, kann Ihre Strategie darin bestehen, sämtliche Produktionssysteme herunterzufahren, sobald in Ihrer Software eine neue Sicherheitslücke auftritt. Sie können festlegen, dass die Systeme erst dann wieder gestartet werden, wenn Sie den Sicherheitspatch ausgiebig getestet und in Ihrem ganzen Unternehmen bereitgestellt haben. Dies ist ein sehr zeitaufwendiges und teures Verfahren und wäre in den meisten Unternehmen nicht anwendbar.

Während der Patchverwaltung müssen Sie stets die Risiken gegen die Kosten abwägen, die beim Bereitstellen der entsprechenden Gegenmaßnahmen anfallen. Nachdem eine Sicherheitslücke entdeckt worden ist, dauert es eine gewisse Zeit, bis ein entsprechender Patch veröffentlicht wird. Sie müssen das durch die Sicherheitslücke auftretende Risiko einschätzen und entscheiden, was zu tun ist, solange der Patch nicht getestet und bereitgestellt werden kann.

Unter Umständen müssen Sie Dienste deaktivieren, Systeme offline stellen oder den Zugang auf interne Benutzer oder Gruppen beschränken. Sobald ein Patch veröffentlicht ist, müssen Sie das Risiko einer sofortigen Bereitstellung gegen die Kosten abwägen, die entstehen, wenn Ihre Dienste nicht verfügbar oder ungeschützt sind, während Sie den Patch testen und somit sicherstellen, dass er sich nicht negativ auf das System auswirkt. Wenn Sie sich entscheiden, zunächst Tests durchzuführen, müssen Sie wissen, wie lange Sie testen können, bis die Risken einer vorübergehenden Nichtbereitstellung die Risiken der Bereitstellung überwiegen.

Hinweis: In Ihrem Unternehmen sollte ein Verfahren zur Änderungsverwaltung bestehen. Microsoft Operations Framework (MOF) umfasst ein Verfahren zur Änderungsverwaltung, dass eventuell als Grundlage für Ihr Unternehmen geeignet ist. Eine Sammlung von weiterführenden Informationen zu MOF haben wir am Ende dieses Moduls für Sie zusammengestellt.

Voraussetzungen für die Lösung

Mithilfe der Lösung zur Patchverwaltung muss die IT-Abteilung von Trey Research zu Folgendem in der Lage sein:

Da Trey an mehreren Standorten Büros samt Administratoren unterhält, muss das Unternehmen eine einheitliche Reihe von Tools und Verfahren zur Patchverwaltung einführen. Dies ist zwar in erster Linie eine Verfahrensfrage (die durch die weiter unten beschriebene Lösungskonzeption gelöst werden kann), es gibt jedoch mehrere technische Aspekte, die sich auf die Konzeption der Lösung von Trey auswirken können:

Lösungsarchitektur

Der Aufbau der Patchverwaltung kann je nach Unternehmen sehr unterschiedlich sein. Einige Unternehmen entscheiden sich für ein sehr zentrales und strikt verwaltetes System mit so vielen Standardtools wie möglich, während andere individuelle Tools zur Patcherfassung und -bereitstellung entwickeln. All diesen Architekturen sind jedoch gewisse Merkmale und Anforderungen gemeinsam. Die Patchverwaltung umfasst grundsätzlich vier Phasen:

Wichtig: Es wird nachdrücklich empfohlen, Sicherheitskopien aller Produktionssysteme zu erstellen, bevor Sie Patches implementieren.

Analyse der Umgebung

Zur Patchverwaltung sollten Ihre IT-Mitarbeiter mindestens über die folgenden Informationen verfügen:

Es wird nachdrücklich empfohlen, dass diese Informationen stets aktuell und allen Personen zugänglich sind, die an der Patchverwaltung beteiligt sind. Sobald Sie Ihre Ressourcen, Sicherheitslücken, Bedrohungen und die Konfiguration Ihrer Umgebung kennen, können Sie festlegen, welche der Bedrohungen und Sicherheitslücken am wichtigsten sind und als erste angegangen werden.

Wenn Sie sich nach der Vorgabe in Kapitel 2, "Anwenden von SRMD (Security Risk Management Discipline) auf das Beispiel von Trey Research", richten, stehen Ihnen viele dieser Informationen bei der Planung Ihrer Patchverwaltung bereits zur Verfügung. Informationen über die jeweils verwendeten Patches erhalten Sie, indem Sie die in den folgenden Abschnitten erläuterten Schritte durchführen. Daten über Anwendungen, Ressourcen, Risiken und Gegenmaßnahmen können anhand der SRMD-Materialien und der Empfehlungen in den vorherigen Kapiteln dieses Leitfadens erlangt werden.

Ermitteln des Patchbedarfs

Sie müssen gewährleisten, dass die Patches auf Ihren Computern stets aktuell sind. Manchmal wird ein neuer Patch veröffentlicht, den Sie auf allen Servern installieren müssen. In anderen Fällen muss ein neuer Server, der online gehen soll, entsprechend gepatcht werden. Sie sollten alle Server überprüfen, um sicherzustellen, dass sie ausnahmslos mit den letzten Patchversionen versehen sind. Um die Computer in Ihrem Unternehmen effizient auf dem neuesten Stand zu halten, sollten Sie wissen, welche Sicherheitslücken vorliegen und welche Schutzmaßnahmen bereits vorhanden sind. Dazu können Sie die folgenden Tools verwenden: Microsoft Baseline Security Analyzer (MBSA), Microsoft Systems Management Server (SMS) Version 2.0 und SMS 2003 sowie das Inventurprogramm für Office Update.

Verwenden von Microsoft Baseline Security Analyzer

So wichtig es auch ist, dass Sie die auf Ihr System angewendeten Patches kennen – noch wichtiger ist es, die nicht angewendeten Patches zu kennen! MBSA scannt Computer unter Windows NT 4.0, Windows 2000, Windows XP Professional und Windows XP Home Edition und erstellt Berichte, welche Patches vorhanden und welche erforderlich sind.

Hinweis: MBSA kann von jedem Computer unter Windows 2000 Professional, Windows 2000 Server, Windows XP Home oder Windows XP Professional aus ausgeführt werden. Es kann nicht unter Windows 98 oder Windows NT 4.0 ausgeführt werden, und es scannt keine Computer unter Windows 98.

Das MBSA-Tool führt die Scans anhand einer XML-Datenbank (Extensible Markup Language) durch, die Microsoft regelmäßig aktualisiert. Außerdem verwendet es das von Microsoft im August 2001 veröffentlichte beliebte Tool HFNetChk. Die XML-Datei enthält die Namen und Titel von Sicherheitsbulletins und detaillierte Angaben über produktspezifische Sicherheitshotfixes. Dies umfasst Folgendes: die Dateien in den einzelnen Hotfixpaketen samt Dateiversionen und -prüfsummen; die durch das Hotfixinstallationspaket angewendeten Registrierungsschlüssel; Informationen darüber, welche Patches andere Patches ersetzen; zugehörige Artikelnummern in der Microsoft Knowledge Base (KB) und vieles mehr.

Wenn Sie MBSA erstmals ausführen, muss es eine Kopie dieser XML-Datei abrufen, um die für die einzelnen Produkte verfügbaren Hotfixes zu ermitteln. Die XML-Datei ist im Microsoft Download Center in komprimierter Form (digital signierte .cab-Datei) verfügbar. MBSA lädt die .cab-Datei herunter, überprüft die Signatur und dekomprimiert dann die Datei auf den lokalen Computer, auf dem MBSA ausgeführt wird. Eine .cab-Datei ist komprimiert und ähnelt einer WinZip-Datei (.zip-Datei).

Hinweis: Sobald Sie MBSA ausführen, versucht das Programm, eine Verbindung ins Internet herzustellen, um die XML-Datei von Microsoft herunterzuladen. Wenn keine Internetverbindung verfügbar ist, sucht das Tool in seinem Installationsordner nach einer lokalen Kopie. Sobald die Datei während eines Scans erfolgreich heruntergeladen wurde, wird auf dem Computer eine lokale Kopie für den Fall gespeichert, dass bei späteren Scans keine Internetverbindung möglich ist. Bei Computern, auf denen nie eine Internetverbindung besteht, können die Benutzer über einen anderen Computer diese Datei vom Microsoft Download Center herunterladen und dann auf den Computer kopieren, auf dem das Tool ausgeführt wird.

Nachdem die .cab-Datei dekomprimiert wurde, scannt MBSA Ihren (oder den ausgewählten) Computer, um Betriebssystem, Service Packs und ausgeführte Programme zu ermitteln. Anschließend analysiert MBSA die XML-Datei und ermittelt die Sicherheitspatches, die für Ihre Kombination installierter Software zur Verfügung stehen.

Um zu ermitteln, welche Patches auf einem Computer installiert sind, untersucht MBSA drei Punkte: den vom Patch installierten Registrierungsschlüssel, die Dateiversion und die Prüfsumme jeder durch den Patch installierten Datei.

In der Standardkonfiguration vergleicht MBSA die Dateidetails und den Registrierungsschlüssel aus dem entsprechenden XML-Bereich mit den Dateien und Registrierungsdetails auf dem gescannten Computer. Wenn eine der Dateien oder ein Detail der Registrierungsschlüssel auf dem Computer nicht mit den in der XML-Datei gespeicherten Informationen übereinstimmt, wird der entsprechende Sicherheitspatch als nicht installiert eingestuft und im Sicherheitsbericht ausgewiesen. Außerdem wird die Nummer des entsprechenden Knowledge Base-Artikels für den Patch angezeigt.

Generell sucht MBSA nach Sicherheitsproblemen in den Windows-Betriebssystemen (Windows NT 4.0, Windows 2000 und Windows XP), etwa Status der Gastkonten, Dateisystemart, verfügbare Dateifreigaben, Mitglieder der Administratorengruppe usw. In den Sicherheitsberichten finden Sie Beschreibungen der einzelnen Betriebssystemprüfungen sowie Anleitungen, wie die gefundenen Probleme behoben werden können.

Hinweis: Um MBSA zu verwenden, müssen Sie auf dem zu überprüfenden Computer entweder als lokaler Administrator oder Domänenadministrator angemeldet sein.

MBSA verfügt über mehrere Befehlszeilenoptionen, die in zwei Modi verwendet werden können: MBSA und HFNetChk. Der MBSA-Modus speichert die Ergebnisse (wie in MBSA Version 1.0) in getrennten XML-Dateien, so dass sie später in der MBSA-Benutzeroberfläche angezeigt werden können. Der MBSA-Modus umfasst sämtliche Prüfungen für Windows, Internetinformationsdienste, Microsoft SQL Server™, Desktopanwendungen und Sicherheitsupdates.

Der HFNetChk-Modus sucht nach fehlenden Sicherheitsupdates und zeigt die Ergebnisse des Scans im Befehlszeilenfenster an, wie beim eigenständigen Tool HFNetChk. MBSA 1.1 umfasst das Flag /hf, das dem MBSA-Modul einen HFNetChk-Scan anzeigt. Darüber hinaus kann MBSA im HFNetChk-Modus eine in Form einer Textdatei angegebene Liste von Computern scannen und Systeme daraufhin überprüfen, ob alle Patches eines bestimmten SUS-Servers installiert sind.

Wenn Sie mit MBSA Ihren Patchstatus überprüfen, sollten Sie sicherstellen, dass dies regelmäßig erfolgt. In den meisten Umgebungen ist es am einfachsten, dazu ein bestimmtes Zeitintervall anzugeben.

Hinweis: Weitere Informationen über die Verwendung von MBSA finden Sie auf der Seite "Microsoft Baseline Security Analyzer" der Microsoft Website unter http://www.microsoft.com/germany/technet/sicherheit/tools/mbsa.mspx.

Inventurprogramm für Office Update

Angesichts der leistungsfähigen Funktionen von Microsoft Office zur Anwendungsprogrammierung ist es von großer Bedeutung, auf Sicherheitslücken in den Anwendungen selbst zu achten. Zahlreiche Viren und Trojaner nutzen die Fähigkeit moderner Anwendungen, aktive Inhalte in Dokumenten, Tabellenkalkulationen und E-Mails auszuführen. Damit die Office-Installationen stets aktuell und sicher sind, hat Microsoft das Inventurprogramm für Office Update veröffentlicht. Dieses Dienstprogramm kann auf Computern mit Windows 98 oder höher sowie Office 2000 oder höher ausgeführt werden. Dadurch können Administratoren die Patchstufen ihrer Office-Installationen präzise ermitteln.

Das Inventurprogramm für Office Update kann von der folgenden Website heruntergeladen werden: http://www.microsoft.com/office/ork/2003/journ/offutoolv2.htm.

Weitere Methoden zum Ermitteln der Hotfixstufen

Wenn Sie MBSA in bestimmten Teilen Ihrer Umgebung nicht verwenden können oder wollen, gibt es andere Methoden, um festzustellen, ob Hotfixes installiert sind.

Am einfachsten ermitteln Sie dies in der Registrierung des Computers unter dem Schlüssel HKLM\Software\Microsoft\Windows NT\Currentversion\hotfix. Jedes neu installierte Hotfix sollte über einen Schlüssel verfügen, der sich aus Q und der Nummer des Knowledge Base-Artikels zusammensetzt, in dem das Hotfix erläutert wird. Dies trifft allerdings bei manchen älteren Hotfixes und bei Hotfixes für bestimmte Anwendungen nicht zu.

Weitere Tools zum Ermitteln der Hotfixstufen

Es gibt zwei weitere kostenlose Tools von Microsoft, mit denen Sie diese Informationen zusammenstellen können. Diese Tools sind:

Analysieren und Planen der Patchanwendung

Nicht jede Bedrohung oder Sicherheitslücke stellt ein erhebliches Risiko für Ihre Umgebung dar. Wenn Sie Mitteilungen über mögliche neue Sicherheitslücken in Betriebssystemen oder Anwendungen lesen, sollten Sie analysieren, ob diese Sicherheitslücken in Ihrer jeweiligen Umgebung tatsächlich von Bedeutung sind.

Beispiel: Wenn die Sicherheitslücke für den FTP-Dienst (File Transfer Protocol) in Windows 2000 gilt und Sie diesen Dienst niemals aktivieren, betrifft Sie die Sicherheitslücke nicht. Ähnlich würde es sich verhalten, wenn Sie wüssten, dass in diesem Jahr vermehrt Küstenstürme auftreten – wenn sich Ihr Unternehmen weit im Landesinneren befindet, ist diese Bedrohung minimal. Wenn Sie Bedrohungen und Sicherheitslücken angehen, die auf Ihre Umgebung nicht zutreffen, vergeuden Sie wertvolle Ressourcen und beeinträchtigen möglicherweise die Stabilität Ihrer Umgebung, ohne einen entsprechenden Vorteil zu erlangen.

Sobald neue Bedrohungen und Sicherheitslücken auftreten, sollten Sie die entsprechenden Informationen darüber lesen. Dadurch können Sie eine fundierte Entscheidung darüber treffen, welches Risiko tatsächlich für Ihre Umgebung besteht, und dann entsprechend reagieren. Ihre Alternativen lauten: nicht zu handeln, den gefährdeten Dienst zu deaktivieren oder ein Patch bereitzustellen.

Wichtig: Wenn Sie einen Plan zum Bereitstellen eines neuen Patches erstellen, sollten Sie auch einen Wiederherstellungsplan erstellen, in dem aufgeführt ist, wie der Patch wieder entfernt werden kann oder die Auswirkungen einer fehlgeschlagenen Patchinstallation gemindert werden können.

Damit Ihre Patches stets auf dem neuesten Stand sind, sollten Sie regelmäßig die Sicherheitsbulletins von Microsoft lesen. Um die Aktualisierungsbulletins zu abonnieren, rufen Sie die weltweite Microsoft-Website auf (http://www.microsoft.com/worldwide). Geben Sie dann Ihr Land an. Nun gelangen Sie zur Startseite von Microsoft Security (/germany/sicherheit/).

Kategorisieren von Patches

Sobald ein neuer Patch verfügbar ist, sollten Sie seine Bedeutung für Ihre Umgebung ermitteln. Dadurch können Sie entscheiden, wie rasch Sie den Patch bereitstellen müssen und wie lange Sie testen können.

Microsoft bewertet in den Sicherheitsbulletins jeweils den Schweregrad der Sicherheitslücke. Diese Bewertungen sind in der folgenden Tabelle aufgeführt.

Tabelle 6.1: Bewertung des Schweregrads laut Microsoft

Dieses Bewertungssystem klassifiziert Sicherheitslücken nach ihren möglichen Auswirkungen und ihrer Wahrscheinlichkeit.

Sie können dieses Bewertungssystem als Richtlinie zum Kategorisieren von Patches verwenden. Das Bewertungssystem von Microsoft ist jedoch nur eine generelle Einschätzung der möglichen Auswirkungen, die für Millionen Kunden weltweit gilt. Die Bewertungen des Schweregrads beruhen auf der bisherigen Erfahrung und auf subjektiver Einschätzung. Aus diesem Grund beschreiben sie die möglichen Auswirkungen in Ihrer Umgebung unter Umständen nicht richtig. Letzten Endes müssen Sie die Patches anhand Ihrer eigenen Umgebung klassifizieren.

Analysieren des Patches

Die Analyse eines Patches sollte zumindest folgende Schritte umfassen:

Suchen Sie beim Lesen der Dokumentation nach Antworten auf folgende Fragen:

Neben dem Lesen der zusammen mit den Updates veröffentlichten Dokumentation sollten Sie auf der Support-Website von Microsoft zusätzliche, nach der Veröffentlichung bereitgestellte Informationen suchen. Auf der Website von TechNet finden Sie die Sicherheitsbulletins in einer (nach Produktname und Service Pack) durchsuchbaren Datenbank. Hier finden Sie wichtige Informationen, die ebenfalls überprüft werden müssen.

Testen der Patches

Wie jede Software funktionieren Patches unter Umständen nicht in jeder Umgebung perfekt. Im Idealfall sollten Sie sämtliche Patches, die Sie in Ihrer Umgebung installieren möchten, sorgfältig testen. Allerdings müssen viele Sicherheitspatches rasch installiert werden, um möglicherweise schwerwiegende Probleme zu beheben.

In vielen Fällen stellt sich heraus, dass Ihr Testverfahren letzten Endes nur einen Kompromiss zwischen der Notwendigkeit, ein Sicherheitsproblem zu beheben, einerseits und der Anforderung, die Stabilität des Patches in Ihrer Umgebung zu gewährleisten, andererseits darstellen kann.

Der angemessene Testaufwand hängt davon ab, in welche Kategorie Sie den Patch einordnen. In der folgenden Tabelle ist entsprechend den Kategorisierungen von Microsoft aufgeführt, welche Tests Sie pro Patchart mindestens durchführen sollten. Im Beispiel von Trey Research musste jede Serverrolle nach Installation der empfohlenen Hotfixes ordnungsgemäß funktionieren. Dazu wurde zunächst überprüft, ob verschiedene Clientcomputer weiterhin eine Verbindung zu den auf den einzelnen Serverrollen ausgeführten Netzwerkdiensten herstellen konnten. Überdies wurden andere grundlegende Tests durchgeführt, um sicherzustellen, dass alles weiterhin wie vorgesehen funktionierte.

Tabelle 6.2: Mindesttestaufwand für Patches

Im Rahmen Ihres Risikomanagements müssen Sie festlegen, wie intensiv die einzelnen Schritte durchzuführen sind. Wenn Sie in einem Notfall bestimmte Phasen auslassen müssen, sollten Sie sie dennoch zu einem späteren Zeitpunkt im Testlabor durchführen, um mögliche Probleme zu entdecken, bevor diese auf bereits gepatchten Systemen auftreten.

Die Tests sollten stets auf Servern erfolgen, die Ihren Produktionsservern so weit wie möglich entsprechen.

Installieren des Patches

Sie sollten herausfinden, ob der Patch korrekt installiert wird, ob ein Neustart erforderlich ist, wie viel Speicherplatz notwendig ist (einschließlich Deinstallationsordner), welche Optionen Ihnen zur Verfügung stehen usw. Außerdem sollten Sie die entsprechende Dokumentation auf zusätzliche Informationen hin durchlesen, um die Vor- und Nachteile einer Patchanwendung zu ermitteln.

Testen des Serverbetriebs

Sobald der Patch installiert ist, müssen Sie überprüfen, ob der Server weiterhin normal funktioniert. Es empfiehlt sich, das Ereignisprotokoll und den Systemmonitor auf unerwartete Ergebnisse hin zu überprüfen.

Testen Sie sämtliche Serverfunktionen, und stellen Sie sicher, dass alles normal funktioniert. Welches Risiko Sie auf einem Server mit einer bestimmten Sicherheitslücke akzeptieren können, hängt davon ab, wie lange der Server ausgeführt werden muss, bis Sie wissen, dass alles normal verläuft. Wenn Probleme auftreten, sollten Sie diese so schnell wie möglich dokumentieren und Microsoft vorlegen.

Hinweis: Mit Microsoft Operations Manager (MOM) können Sie die Daten des Ereignisprotokolls und des Systemmonitors für Server unter Windows NT 4.0 erfassen.

Testen des Anwendungsbetriebs

Als Teil Ihres Testverfahrens sollten Sie den Patch mit allen auf den Servern vorhandenen Anwendungen testen und alle Probleme hinsichtlich Abhängigkeiten ermitteln. Nach dem Installieren des Patches sollten Sie überprüfen, ob sämtliche Anwendungen weiterhin wie zuvor funktionieren.

Vorbereiten einer Deinstallation

Es ist möglich, dass trotz Testens nach dem Installieren des Patches Probleme auftreten, die dazu führen, dass Sie den Patch deinstallieren müssen. Daher ist es wichtig, die Funktion der Deinstallationsprozedur zu überprüfen. Nach der Deinstallation sollten Sie überprüfen, ob der Server weiterhin wie erwartet funktioniert, und das Ereignisprotokoll und den Systemmonitor überwachen.

Erstellen eines Wiederherstellungsplans

Auch wenn das Testen ohne Zwischenfall verläuft, kann es vorkommen, dass Probleme auftreten, wenn Sie den Patch im gesamten Unternehmen bereitstellen. Deshalb müssen Sie einen Plan erstellen, wie Sie das System wieder in den Originalzustand, also vor der Bereitstellung des Patches, zurückversetzen können.

Ein solcher Plan kann zum Beispiel eine Snapshotsicherung eines Servers vor der Installation umfassen. Dann können Sie den Server rasch wieder herstellen, wenn Probleme auftreten. Sie sollten den Wiederherstellungsplan Ihres Unternehmens sorgfältig testen.

Bereitstellen der Patches

Wenn das Testen ohne Zwischenfall verlaufen ist, können Sie den Patch in Ihrem Unternehmen bereitstellen. Dies kann auf verschiedene Arten geschehen, zum Beispiel mithilfe der folgenden Verfahren:

Manuelle Bereitstellung

Häufig werden Hotfixes manuell installiert. Dabei wird einfach die ausführbare Datei des Hotfixes auf den einzelnen Servern gestartet. Wenn Ihr Unternehmen zahlreiche Server besitzt, stellt dies unter Umständen einen zu großen Aufwand dar. Trey Research hat eine überschaubare Anzahl an Servern, und da sich diese auf mehrere Standorte verteilen, werden die Patches manuell bereitgestellt.

Am Namen eines Hotfixes können Sie wichtige Informationen ablesen: Ein typischer Hotfixname ist etwa Q292435_W2K_SP3_x86_en.exe. In diesem Fall gilt Folgendes:

Hinweis: Hotfixes, deren Dateiname nach dem Muster QXXXXXX.exe aufgebaut ist, jedoch keine Erweiterung nach dem Muster W2K_SP3_x86 enthält, gelten für bestimmte Anwendungen wie etwa Microsoft Internet Explorer.

Hotfixes unterstützen zudem mehrere Befehlszeilenoptionen, mit denen Sie den Verlauf des Hotfix-Installationsprozesses steuern können. Siehe dazu die folgende Tabelle.

Tabelle 6.3: Optionen für ausführbare Hotfix-Dateien

Hinweis: Anwendungsspezifische Hotfixes mit Dateinamen nach dem Muster QXXXXXX.exe unterstützen in der Regel nicht alle der in der vorhergehenden Tabelle aufgeführten Optionen.

Wenn Sie ein Skript zur Installation mehrerer Hotfixes erstellen, können Sie die Optionen -q und -z verwenden, so dass das Hotfix ohne Benutzereingriff installiert wird und kein Neustart erforderlich ist.

Wenn Sie mehrere Hotfixes installieren, müssen Sie den Computer normalerweise dazwischen jeweils neu starten. Dies gilt deshalb, weil sämtliche Dateien, die gesperrt sind oder verwendet werden, nicht überschrieben werden können. Sie werden in eine Warteschlange gestellt und erst nach dem Neustart des Systems ersetzt.

Mit dem Tool QChain können Sie mehrere Hotfixes für Windows NT 4.0 aneinander hängen, so dass nur ein einziger Neustart erforderlich ist. Um QChain zu verwenden, führen Sie das Installationsprogramm des Hotfixes mit der Option -z aus. Dadurch wird das Installationsprogramm angewiesen, nach der Installation keinen Neustart einzuleiten. Führen Sie dann QChain.exe aus, und starten Sie den Computer neu.

Wenn nach der Installation eines Service Packs und von Patches weitere Windows-Komponenten, etwa der DNS-Dienst (Domain Name System), hinzugefügt werden, müssen das Service Pack und die Patches erneut installiert werden, um sicherzustellen, dass auch die neue Komponente ordnungsgemäß gepatcht ist.

Bereitstellung per Skript

Mit der Microsoft Visual Basic®-Skriptsprache oder Batchdateien können Sie eigene Skripts zum Bereitstellen der Patches erstellen. Diese Skripts sollten als Anmelde- oder Startskripts vorliegen, die den aktuellen Patchstatus überprüfen und dann auf einem Zentralserver Updates ermitteln. Diese Skripts können QChain umfassen, so dass auch bei mehreren Hotfixes nur ein einziger Neustart erfolgt.

Überwachen und Protokollieren der Bereitstellung

Nachdem Sie die Patches in Ihrer Produktionsumgebung installiert haben, sollten Sie Ihre Server weiterhin überwachen. Achten Sie insbesondere darauf, ob im Ereignisprotokoll und im Systemmonitor Probleme angezeigt werden. Wenn auf dem Computer in den folgenden Wochen sonstige Probleme auftreten, sollten Sie überprüfen, ob diese mit dem installierten Patch zusammenhängen. Wenn Sie einen Patch aufgrund hoher Dringlichkeit ohne ausführliche Tests installieren mussten, sollten Sie zudem den Patch anschließend in einer Laborumgebung testen, um sicherzustellen, dass kein Aspekt übersehen wurde.

Sie sollten nicht nur die vorhandenen Server, sondern Ihre gesamte Umgebung überwachen, um zu gewährleisten, dass neue Server nur dann ins Netzwerk eingebunden werden, wenn die aktuellen Patches installiert sind. Neue Server sollten stets über den aktuellen Build verfügen. Dies sollte durch die Überwachungsrichtlinien Ihres Unternehmens sichergestellt werden.

Die einzige Möglichkeit festzustellen, dass ein Prozess ordnungsgemäß abläuft, besteht in einer Überprüfung. Sobald Sie die Patchverwaltung für einen Patch abgeschlossen haben, sollten Sie den Vorgang überprüfen, um sicherzustellen, dass jeder Patch korrekt bereitgestellt wurde und dass alle Abläufe ordnungsgemäß stattfanden. Dadurch können Sie sicherstellen, dass Ihre Patchverwaltung auch weiterhin wie vorgesehen funktioniert. Wenn Sie das Verfahren überprüfen, sollten Sie die Umgebung auf weitere Veränderungen hin analysieren. In einem solchen Fall müssen Sie die Patchverwaltung erneut starten.

Zum Seitenanfang

Implementierung

Die Lösung von Trey Research zur Patchverwaltung umfasst mehrere eigenständige Komponenten, die zusammen eine zuverlässige, robuste Bestandsaufnahme und Umsetzung gewährleisten. Als Erstes führte Trey eine umfassende Analyse der vorhandenen Netzwerke und Systeme im Unternehmen durch. Patches werden oft uneinheitlich in einem Unternehmen bereitgestellt, und häufig ist auch nicht dokumentiert, warum, wann und wo sie bereitgestellt wurden. Trey wollte eine einheitliche Patchverwaltung aufbauen, mit der wiederholbare Verfahren möglich wären, um Patches einheitlich zum richtigen Zeitpunkt auf die richtigen Computer anzuwenden.

Aufbau von Staging-Servern zur stufenweisen Aktualisierung

In vielen Umgebungen kann es hilfreich sein, wenn spezielle Computer vorhanden sind, über die Sie einen Großteil der bei der Patchverwaltung anfallenden Schritte durchführen. Diese Systeme bieten spezielle Speicherorte für Sicherheitstools, Patches, Hotfixes, Service Packs und Dokumentation. Auf diesen Systemen können Sie die Analyse, das Abrufen und die Bereitstellung von Patches durchführen. Der Softwareaktualisierungsdienst (SUS) und Windows Update Services (WUS) von Microsoft übernehmen diese Funktionen für Windows-Netzwerke. SUS konnte jedoch in der Umgebung von Trey nicht verwendet werden, da Windows 98 und Windows NT 4.0 ihn nicht unterstützen. Stattdessen baute Trey eigene Staging-Server auf, um Patches stufenweise zu testen und bereitzustellen. Bei diesen Servern handelt es sich um Freigaben auf Microsoft Windows Server™ 2003-Domänencontrollern. Trey lud das Microsoft Security Tool Kit herunter, platzierte es auf den Staging-Servern und sicherte die vorhandenen Computer mit den darin enthaltenen Patches ab. Darüber hinaus aktualisierte Trey sein Verfahren zum Aufbau von Servern und Arbeitsstationen. Dieses umfasst nun die Anwendung von Patches aus dem Security Tool Kit.

Trey entschied sich dafür, die vorhandenen Domänencontroller als Staging-Server zu verwenden, um sicherzustellen, dass sich die Sicherheitsupdatesysteme auf einem bzw. mehreren speziellen Computern befinden, die strikt kontrolliert und abgesichert werden können. Trey traf diese Entscheidung, da diese Systeme dazu dienen, Sicherheitspatches für alle Systeme in der Umgebung bereitzustellen und zu warten.

Diese Sicherheitsupdatesysteme brauchen in der Regel nicht allzu leistungsfähig zu sein (da die Last auf ihnen meist recht niedrig ist), sehr wichtig ist jedoch eine hohe Verfügbarkeit.

Um ein Sicherheitsupdatesystem ordnungsgemäß bereitstellen zu können, benötigt der Computer direkten oder indirekten Zugriff auf das Internet, um die jüngsten Patchinformationen aus vertrauenswürdigen Quellen herunterzuladen, sowie Zugriff auf jeden Computer, für dessen Aktualisierung er zuständig ist.

Hinweis: MOF behandelt Updatesysteme als Teil des Verfahrens zum Versionsmanagement.

Ermitteln fehlender Patches

Nur durch kontinuierliche Analyse kann sichergestellt werden, dass alle Server und Arbeitsstationen stets mit den neuesten Patches versehen sind. Um die Computer im Netzwerk stets auf dem neuesten Stand zu halten, verwendeten die IT-Mitarbeiter von Trey eine Kombination der zuvor in diesem Kapitel beschriebenen Tools.

Scannen des Basisbetriebssystems

Mit MBSA können die IT-Mitarbeiter von Trey regelmäßig ihre Server und Arbeitsstationen unter Windows NT scannen und die Ergebnisse katalogisieren. Zunächst führte der Leiter der IT-Abteilung mit MBSA einen raschen Basisscan durch, um Systeme zu ermitteln, bei denen Patches fehlten. Sobald diese Systeme gepatcht waren, wurde MBSA auf regelmäßige Scans verschiedener Systemgruppen eingestellt.

So führen Sie mit MBSA einen Basisscan durch

So führen Sie mit MBSA einen Standardscan durch

Im Whitepaper "Microsoft Baseline Security Analyzer V1.2"(http://download.microsoft.com/download/1/0/0/10088d15-5a65-4ad8-a4bf-bf466012c407/mbsa_1_2_final.doc, in englischer Sprache) finden Sie eine komplette Beschreibung der Scanmodi von MBSA und der durchgeführten Prüfungen auf Sicherheitslücken.

Scannen von Office-Installationen

Mit dem weiter oben in diesem Kapitel beschriebenen Inventurprogramm für Office Update können Sie einzelne Arbeitsstationen auf kritische Office-Updates hin untersuchen. Dazu muss allerdings auf jedem System eine ausführbare Clientdatei installiert sein und ausgeführt werden. Da Trey Research im Rahmen seines Plans zur IT-Modernisierung auf Office 2003 migriert, hat das Unternehmen eine Mischung von Office 2000- und Office XP-Installationen; die Administratoren haben die aktuellen Service Packs bereits als Teil der normalen Systemwartung installiert. Trey stufte das Risiko einer Netzwerkgefährdung durch Sicherheitslücken in Office als relativ gering ein und setzte deshalb eine Strategie um, in deren Rahmen die Benutzer direkt auf der Office Update-Website (http://office.microsoft.com/officeupdate) nach Updates suchen können. Wichtige Systeme, darunter auch diejenigen von Führungskräften, werden wie folgt gescannt:

Planen der Patchanwendung

Der Leiter der IT-Abteilung von Trey Research IT erstellte eine Vorlage für einen Plan zur Patchanwendung, die als Basis für die monatlichen Pläne des Unternehmens zur Patchanwendung dient. Da Microsoft Sicherheitspatches in überschaubaren Abständen veröffentlicht, steht den Administratoren von Trey mit der Vorlage ein standardisiertes Verfahren zur Verfügung, mit denen sie jede Gruppe von Sicherheitspatches analysieren, auswerten und bereitstellen können, sobald Microsoft es veröffentlicht. Die Richtlinien der Vorlage umfassen Folgendes:

Neben der Erstellung dieser Vorlage abonnierten die IT-Mitarbeiter von Trey den Microsoft-Sicherheitsbenachrichtigungsdienst (/germany/technet/datenbank/articles/430926.mspx). Außerdem lesen sie regelmäßig das Microsoft Security-Portal (/germany/sicherheit/).

Kategorisieren von Patches

Trey Research verwendet das in Tabelle 6.1 aufgeführte Schema zur Bewertung des Schweregrads. Das Unternehmen ergänzt diese Kategorisierung jedoch um einen weiteren Parameter: die Relevanz des Patches für seine Umgebung. Da Trey derzeit noch nicht Office 2003 verwendet, erhalten Patches für dieses Programm die Einstufung "nicht relevant", unabhängig von dem Schweregrad, den Microsoft der entsprechenden Sicherheitslücke zuweist. Da Trey hingegen Microsoft Data Engine (MSDE) und SQL Server 2000 intensiv verwendet, werden alle Patches für SQL Server als "relevant" eingestuft. Dieser Ansatz erfordert zwar einen höheren Aufwand zur Kategorisierung, dadurch kann sich Trey aber auf die Patches konzentrieren, die für die Umgebung des Unternehmens am wichtigsten sind.

Testen der Patches

Der leitende IT-Administrator von Trey Research entwickelte einen Testplan, in dem die Bedingungen zum Testen von Patches, die allgemein bereitgestellt werden sollen, auf der Grundlage ihres Schweregrads, ihrer Anwendbarkeit und der Art der zu patchenden Systeme festgelegt sind. Trey übernahm dabei die Empfehlungen von Microsoft für den Testumfang (Tabelle 6.2) und baute im Labor ein Modell seines Produktionsnetzwerks mit Entsprechungen für Arbeitsstationen und Server auf. Neue Patches werden zunächst im Testlabor bereitgestellt, um sicherzustellen, dass die Patches korrekt installiert werden können und keine kritischen Funktionen stören. Wenn diese Anfangstests erfolgreich verlaufen, werden die Patches nach den Kriterien des Plans zur Patchanwendung bereitgestellt.

Nachdem ein Patch im Testlabor installiert ist, führt Trey eine Reihe von Standardtests durch. Dies umfasst das Hinzufügen und Entfernen von Ressourcen im Verzeichnisdienst Microsoft Active Directory® und die Ausführung einer Standardreihe mit Geschäftsbereichsanwendungen des Unternehmens. Darüber hinaus umfassen die Testkriterien die Überprüfung von Ereignisprotokoll und Systemmonitor auf unerwartete Ergebnisse.

Hinweis: Mit Microsoft Operations Manager (MOM) können Sie die Daten des Ereignisprotokolls und des Systemmonitors für Server unter Windows NT 4.0 erfassen.

Bereitstellen der Patches

Sofern das Testen ohne Zwischenfall verlaufen ist, stellt Trey Research die Patches auf allen entsprechenden Systemen bereit. Dabei wird eine Kombination aus zwei Methoden verwendet: manuelle Bereitstellung durch Administratoren oder betroffene Benutzer sowie automatisierte Bereitstellung mithilfe individueller Skripts.

Manuelle Bereitstellung

Häufig werden Hotfixes manuell installiert. Dabei wird einfach die ausführbare Datei des Hotfixes auf den einzelnen Servern gestartet. Wenn Ihr Unternehmen zahlreiche Server besitzt, stellt dies unter Umständen einen zu großen Aufwand dar. Trey Research hat eine überschaubare Anzahl an Servern, und da sich diese auf mehrere Standorte verteilen, werden die Patches manuell bereitgestellt. Um unnötige Ausfallzeiten zu vermeiden, installieren die IT-Mitarbeiter die Patches mithilfe der Option –z. Dadurch erfolgt ein Neustart erst nach Installation des letzten Patches. Letzter Schritt im Installationsprozess ist die Ausführung der Datei Qchain.exe, um alle während der Patchbereitstellung installierten Dateien zu vereinheitlichen.

Bereitstellung per Batchdatei

Trey Research erstellte eine individuelle Batchdatei, die mithilfe von QChain mehrere Hotfixes installiert und den Computer nach Installation des letzten Patches neu startet. Diese Batchdatei wird im Knowledge Base-Artikel 296861 ("Installieren von mehreren Windows-Updates oder Hotfixes mit nur einem Neustart") unter http://support.microsoft.com/?kbid=296861 beschrieben. Das folgende Muster zeigt, wie Qchain eingesetzt wurde:

@echo off
setlocal
set PATHTOFIXES=some path
%PATHTOFIXES%\Q123456_w2k_sp2_x86.exe -z -m
%PATHTOFIXES%\Q123321_w2k_sp2_x86.exe -z -m
%PATHTOFIXES%\Q123789_w2k_sp2_x86.exe -z -m
%PATHTOFIXES%\qchain.exe

Zum Seitenanfang

Zusammenfassung

Die meisten Verletzungen der IT-Sicherheit entstehen durch die Ausnutzung von Systemumgebungen, deren Sicherheitspatches nicht auf dem neuesten Stand sind. Um Sicherheitsrisiken zu minimieren, ist eine gute Patchverwaltung unerlässlich. Wenn Sie die Patchverwaltung ernst nehmen, können Sie die Kosten, die durch Verletzungen der Sicherheit entstehen, wahrscheinlich dramatisch reduzieren. Bei Trey Research ist die Patchverwaltung, wie bei den meisten Unternehmen, ein ständiger Prozess; die Server müssen mithilfe sicherheitsrelevanter Hotfixes stets auf dem neuesten Stand gehalten werden.

Weitere Informationen

Tools von Drittanbietern

Es gibt zahlreiche Tools von Drittanbietern, die bei der Patchverwaltung hilfreich sind. Diese Tools bieten einige Funktionen, die die kostenlosen Tools von Microsoft nicht umfassen. Dazu zählen die Möglichkeit, nach dem Bereitstellen von Patches einen Statusbericht zu erhalten, das Erstellen von Computergruppen mit vergleichbarem Aktualisierungsbedarf, die Unterstützung weiterer Produkte, die von den zuvor beschriebenen Tools nicht abgedeckt werden, sowie Benutzeroberflächen für administrative Aufgaben. Sie sollten diese Funktionen analysieren und ermitteln, ob sie für Ihre Umgebung relevant sind. Auswahl verfügbarer Tools von Drittanbietern:

Zum Seitenanfang

7 von 10