Sicherheit auf dem PrüfstandGerade habe ich ein Sicherheitsbulletin erhalten. Was nun?

Christopher Budd

Den Anstoß für die monatliche Herausgabe eines Microsoft-Sicherheitsbulletins, die seit Oktober 2003 erfolgt, gaben Kundenanfragen. Eines der wichtigsten Kundenanliegen war ein fester Zeitplan für die Herausgabe von Sicherheitsbulletins. Wir konnten uns diesen Umstand für eine Verfeinerung und Verbesserung unserer Arbeitsabläufe zunutze machen.

Unter „Microsoft Security Bulletins“ können Sie sich das aktuelle Sicherheitsbulletin ansehen und alte Bulletins durchsuchen (siehe Abbildung 1). Ein Beispiel, in diesem Fall das Bulletin für August 2006, sehen Sie in Abbildung  2.

Figure 1** „Microsoft Security Bulletins“ **(Klicken Sie zum Vergrößern auf das Bild)

Für viele Kunden hat das monatliche Sicherheitsbulletin von Microsoft einen wichtigen Beitrag zur Entwicklung verfeinerter Abläufe für die Bereitstellung von Microsoft-Sicherheitsupdates geleistet. Die Kunden haben sich die Tatsache, dass die Sicherheitsbulletins zu einem festen Termin herausgegeben werden, für die Entwicklung eigener, regelmäßiger Abläufe für den Umgang damit zunutze gemacht. Diese Kunden haben Zeitvorgaben und Schritte in ihre eigenen Sicherheitsupdateprüfungs- und Bereitstellungsabläufe integriert, die sich an den festen Zeitvorgaben in Verbindung mit der Herausgabe des monatlichen Sicherheitsbulletins von Microsoft orientieren. Die Kunden nutzen diesen Prozess, um Updates systematisch zu analysieren, zu testen und bereitzustellen, wodurch ihre Sicherheit generell erhöht und Ausfallzeiten und Störungen verringert werden.

Figure 2** Sicherheitsbulletin für August 2006 **(Klicken Sie zum Vergrößern auf das Bild)

Einige Kunden halten sich bei der Prüfung und Bereitstellung von Sicherheitsupdates jedoch nicht an feste Abläufe. Auch wenn es möglich ist, bei der Bereitstellung von Updates unsystematisch vorzugehen, ohne dass Probleme auftreten, widerspricht diese Vorgehensweise gänzlich unseren Empfehlungen für den Umgang mit Sicherheitsupdates.

Wir haben hilfreiche Informationen darüber zur Verfügung gestellt, wie und wann wir Bulletins herausgeben, haben jedoch keine klaren Anhaltspunkte dafür gegeben, wie Sie mit den Bulletins verfahren sollten und wie Sie sie in Ihre internen Abläufe einbinden können. Manchen Kunden ist möglicherweise nicht klar, welche Abläufe sie sich zunutze machen können und wie sie diese am besten erstellen.

Daher werden in diesem Artikel die Arbeitsschritte und Abläufe umrissen, die für die Prüfung und Bereitstellung von Sicherheitsupdates empfohlen werden. Unternehmen jeder Größenordnung können diese Arbeitschritte umsetzen. Bei größeren Unternehmen ist es unter Umständen ratsam, die Arbeitsschritte in Abhängigkeit von der internen Firmenstruktur auf verschiedene Gruppen aufzuteilen. Bei kleineren Unternehmen können alle Arbeitsschritte von einer Gruppe oder gar von einer Person ausgeführt werden. Unabhängig davon, auf wessen Schultern diese Aufgaben verteilt sind, sollte die Erledigung all dieser Arbeitsschritte im Rahmen Ihrer Prüfungs- und Bereitstellungsabläufe deutlich nachvollziehbar sein. Abbildung 3 enthält eine Übersicht über den Ablauf.

Figure 3** Sicherheitsbulletinbewertung und Bereitstellungsprozess **

1. Erhalt der Advanced Notification (Ankündigung)

Der erste Schritt in Ihrem monatlichen Sicherheitsbulletin-Ablauf sollte darin bestehen, dafür zu sorgen, dass Sie die Ankündigung anstehender Updates erhalten. Microsoft veröffentlicht die entsprechenden Informationen drei Werktage vor dem monatlichen Standardbulletin (der jeweils am 2. Dienstag eines Monats herausgegeben wird), ca. um 2:00 Uhr morgens auf der Microsoft-Website. Die Ankündigung wird also jeweils am vorhergehenden Donnerstag gesendet.

Ziel der Ankündigung ist die Bekanntgabe von Informationen, um die Bereitstellungsplanung im Vorfeld der eigentlichen Veröffentlichung zu erleichtern. Die Ausführlichkeit der darin enthaltenen Details hält sich die Waage mit dem Bedürfnis, die Kunden bis zur Veröffentlichung der Sicherheitsupdates zu schützen, indem keine Informationen bekanntgegeben werden, die Angriffen Tür und Tor öffnen könnten. In der Ankündigung sind Informationen über die bevorstehenden Updates untergliedert nach Produktnamen, jedoch ohne genaue Angaben zur Version zu enthalten (z. B. Microsoft® Windows® oder Microsoft Office). In jedem dieser Einträge wird angezeigt, wie viele Bulletins für dieses Produkt veröffentlicht werden, der maximale Schweregrad dieser Bulletins, ob für einige der Updates ein Neustart erforderlich ist und welche Ihrer Erkennungstools diese Bulletins betreffen.

Um Überraschungen auszuschließen und möglichst wenig Verwirrung zu stiften, enthält die Ankündigung auch Informationen über andere Updates, die nicht mit Sicherheitsbulletins zusammenhängen, die am selben Tag freigeschaltet werden. Sie gibt insbesondere an, wie viele hochrangige, nicht die Sicherheit betreffende Updates (High Priority Non-Security Updates) durch Microsoft Update (MU) und Windows Update (WU) freigeschaltet werden, und nennt alle Updates für das MSRT Windows-Tool zum Entfernen bösartiger Software.

Letztendlich werden wir Informationen über alles liefern, was bei Ihnen zu Verzögerungen in Bezug auf die Bereitstellung führen könnte, wie bei der „Send as“-Berechtigungsänderung in MS06-019.

Jeden Monat wird die neue Ankündigung freigeschaltet und sogleich eine Benachrichtigung durch die Security Notification Service Comprehensive Edition (SNSCE) herausgegeben. Sie können sich bei der SNSCE anmelden.

2. Beurteilung der möglichen Auswirkungen

Nach Erhalt der Ankündigung sollten Sie zunächst die Relevanz der bevorstehenden Upgrades in Ihrer Umgebung einschätzen. Wenngleich die Ankündigung nur wenige Details über die betroffenen Produkte enthält, bietet sie Ihnen genug Informationen, um abschätzen zu können, ob bevorstehende Bulletins für Ihre Umgebung relevant sind.

Beispiel: Angenommen in der Upgrade-Vorwarnung werden zwei Microsoft Exchange-Bulletins genannt, deren maximaler Schweregrad als kritisch bezeichnet wird und die einen Neustart erfordern. Wenn Sie dieses Programm gar nicht verwenden, wissen Sie sofort, dass diese Bulletins für Ihre Umgebung nicht relevant sind. Andererseits wissen Sie, wenn Sie Exchange Server 2003 verwenden, dass Sie am Dienstag möglicherweise zwei als kritisch eingestufte Bulletins haben werden, die Neustarts erfordern.

Mit Blick auf die Planung sollten Sie die Ankündigung als Hilfsmittel sehen, mit dem Sie die größtmöglichen Auswirkungen auf Ihr Unternehmen in Bezug auf die Anzahl der Bulletins, deren Schweregrad sowie deren Auswirkungen auf die Bereitstellung in Bezug auf Neustarts ermitteln können. Sobald Sie die Relevanz und die größtmöglichen Auswirkungen der Updates beurteilt haben, können Sie einen Terminplan erstellen, der die folgenden Elemente umfassen sollte:

• Personal zur Risikoabwägung, Prüfung und Bereitstellung
• Testpläne und Testdauer
• Bereitstellungspläne und geplante Neustarts (bei Bedarf)

Zu diesem Zeitpunkt kann lediglich ein vorläufiger Terminplan entworfen werden, da Änderungen der Informationen in der Ankündigung vorbehalten bleiben. Aufgrund des begrenzten Informationsgehalts der Ankündigung ist es außerdem möglich, dass Sie nach Bekanntwerden aller Details Änderungen vornehmen.

Schließlich sollten Sie, sofern zusätzliche Informationen wie z. B. Funktionsänderungen vorliegen, die Zeit zwischen der Ankündigung und dem eigentlichen Sicherheitsbulletin nutzen, um das Thema näher zu untersuchen und mögliche Auswirkungen auf Ihre Umgebung abzuschätzen. Aufgrund der Ergebnisse Ihrer Untersuchung müssen Sie Ihren vorläufigen Terminplan möglicherweise revidieren.

3. Erhalt neuer Microsoft-Sicherheitsbulletins

Jeden zweiten Dienstag im Monat veröffentlicht Microsoft seine Sicherheitsbulletins. Der vorgegebene Zeitpunkt für die Veröffentlichung ist 2:00 Uhr morgens. Da die Veröffentlichung jedoch Teil eines umfangreichen, komplizierten Prozesses ist, können aus mehreren Gründen Verspätungen auftreten. In dieser Veröffentlichung werden Sicherheitsbulletins, Sicherheitsupdates, Updates für Erkennungs- und Bereitstellungstools wie Microsoft Baseline Security Analyzer (MBSA) und Windows Server® Update Services (WSUS) sowie neue Erkennungstools, wie z. B. eine neue Version von Enterprise Scan Tool (EST), auf Microsoft-Websites gestellt.

Die Microsoft-Sicherheitsbulletinseite unterstützt RSS-Feeds. Wenn Sicherheitsbulletins Updates enthalten, wird unser RSS-Feed ebenfalls aktualisiert, was wiederum eine Aktualisierung der RSS-Aggregatoren und Viewer bewirkt. Außerdem wird über den Security Notification Service (SNS) und die SNSCE eine Benachrichtigung gesendet. Benachrichtigungen werden sowohl über E-Mail als auch über MSN® Alerts gesendet.

Um über neue Sicherheitsbulletins informiert zu werden, sollten Sie sich bei allen verfügbaren Benachrichtigungsmechanismen anmelden. Sie können sowohl das RSS-Feed als auch SNS und SNSCEabonnieren.

4. Einschätzen der Relevanz von Sicherheitsbulletins

Es sollte klar definiert sein, wer für die Prüfung der neuen Sicherheitsbulletins und Einschätzung ihrer Relevanz für Ihre Umgebung verantwortlich ist. Im Rahmen dieser Einschätzung können Sie Ihren vorläufigen Terminplan auf der Grundlage der umfassenden, genauen Informationen aus den Sicherheitsbulletins bei Bedarf revidieren. Um noch einmal auf das Beispiel zurückzukommen: Sollten Sie Ihr Exchange-Administrationsteam über ein potenzielles kritisches Sicherheitsupdate benachrichtigt haben, dann jedoch erfahren, dass Exchange Server gar nicht betroffen ist, können Sie Ihre Terminplanung für diese Ressourcen entsprechend korrigieren.

Sobald Sie die Relevanz der Sicherheitsbulletins für Ihr Unternehmen eingeschätzt haben, können Sie sich den Punkten widmen, die für Ihre Abläufe relevant sind.

5. Abwägen der Risiken und Einstufen der Bulletins

Nun müssen Sie die Risiken der relevanten Bulletins abwägen. In Unternehmen mit geteilten Verantwortungsbereichen wird dieser Schritt oft von der Sicherheitsgruppe ausgeführt. Wenngleich jedes Microsoft-Sicherheitsbulletin einen maximalen Schweregrad enthält, spiegelt diese Bewertung die schwerwiegendsten Schwachstellen in allen betroffenen Produkten wider. Der Microsoft-Schweregrad, der für Ihr Unternehmen gilt, könnte von dem maximalen Schweregrad abweichen, der angegeben ist. Dies hängt davon ab, wie schwerwiegend die Angelegenheit bei den in Ihrer Umgebung verwendeten Versionen ist. Es ist sehr wichtig, das vollständige Verzeichnis der Schweregrade und Schwachstellenbezeichner unter der Zusammenfassung des Sicherheitsbulletins zu lesen und daraus die spezifischen Schwachstelleninformationen für Ihre Versionen zu entnehmen.

Anschließend sollten Sie zu jeder Schwachstelle zusätzliche technische Informationen, wie entschärfende Faktoren und technische Details aus den FAQ, durchlesen und Ihre Risikoeinschätzung auf der Grundlage Ihrer Umgebung und Richtlinien korrigieren. Ihre Richtlinien können die Einbeziehung nichttechnischer, umgebungsspezifischer Faktoren in Ihre Einschätzung zwingend erfordern, wie z. B. die Bedrohung für die Umgebung oder die Gefährlichkeit bestimmter Anwendungen für Ihr Unternehmen.

Am Ende dieses Prozesses sollten Sie eine Risikoeinstufung für jedes der Bulletins und die dazugehörigen Updates haben. Um erneut auf unser Beispiel zurückzukommen: Die Exchange-Administrationsgruppe kann ein Sicherheitsupdate auf der Grundlage der im Sicherheitsbulletin genannten Änderungen als „mittleres Risiko“ einstufen. Sie sollten Ihren Terminplan basierend auf Ihren Richtlinien bei Bedarf aktualisieren und korrigieren. Beispielsweise könnten Ihre Richtlinien vorsehen, dass Updates mit mittlerem Risiko ein bis zwei Tage länger zu testen sind als Updates mit geringem Risiko.

In manchen Fällen sehen die Richtlinien vor, dass Sie bei Bulletins mit einer bestimmten Risikoeinstufung die Implementierung von provisorischen Lösungen in Betracht ziehen sollten. Beispielsweise können die Unternehmensrichtlinien besagen, dass Sie für alle von Ihnen als kritisch eingestuften Sicherheitsupdates so bald wie möglich provisorische Lösungen zu prüfen und bereitzustellen haben. In diesem Fall müssen Sie zusätzlich die Risiken der provisorischen Lösungen abwägen und entscheiden, was Sie zu welchem Zeitpunkt implementieren.

Am Ende dieses Prozesses sollten Sie eine Liste der in Ihrem Umfeld bereitzustellenden Updates mit der dazugehörigen Risikoeinstufung für jedes dieser Updates haben. Zusätzlich sollten Sie eine Liste der zu implementierenden provisorischen Lösungen haben, anhand derer Sie Ihren Prüfungs- und Bereitstellungszeitplan aktualisieren. Die Veränderungen Ihres Zeitplans sollten die in Ihren Richtlinien genannten Zeitvorgaben widerspiegeln. Beispielsweise könnten Sie eine Richtlinie haben, die zwingend vorschreibt, dass für alle kritischen Sicherheitsupdates innerhalb von 24 Stunden provisorische Lösungen und innerhalb von sieben Kalendertagen Updates bereitzustellen sind.

6. Ermitteln der möglichen Auswirkungen von Sicherheitsupdates und /oder provisorischen Lösungen auf das Unternehmen

Erkenntnisse über die Auswirkungen von Sicherheitsupdates oder provisorischen Lösungen auf Ihre Umgebung zu gewinnen, ist ein wichtiger Schritt innerhalb des Bewertungsprozesses. In Unternehmen mit geteilten Verantwortungsbereichen wird dieser Schritt häufig von der Gruppe ausgeführt, die die Systeme betreut, die direkt von den Sicherheitsupdates oder provisorischen Lösungen betroffen sind.

Erkenntnisse über die möglichen Auswirkungen verhelfen Ihnen zu einem besseren Verständnis der Risiken, die von den Sicherheitsupdates oder provisorischen Lösungen selbst ausgehen. Diesbezügliche Informationen finden Sie im Abschnitt mit häufig gestellten Fragen (FAQ) im Zusammenhang mit dem Sicherheitsupdate. Informationen darüber, wie das Sicherheitsupdate die Schwachstelle behebt, sind in den FAQ zum Thema Schwachstellen, im Abschnitt über Schwachstellen-Details angegeben.

Der Zweck dieses Arbeitsschritts besteht darin, eine Risikoeinstufung für die Updates und provisorischen Lösungen zu ermitteln. Um erneut auf das obige Beispiel zurückzukommen: Die Exchange-Administrationsgruppe kann ein Sicherheitsupdate auf der Grundlage der im Sicherheitsbulletin genannten Änderungen als „mittleres Risiko“ einstufen. Sie sollten Ihren Terminplan aufgrund der entsprechenden Richtlinien bei Bedarf korrigieren. Beispielsweise könnten Ihre Richtlinien vorsehen, dass Updates mit mittlerem Risiko einen Tag länger zu testen sind als Updates mit geringem Risiko.

Ferner müssen Sie aufgrund der Auswirkungen Ihrer Risikoeinstufung auf Ihren Terminplan die Entscheidungen hinsichtlich der Bereitstellung provisorischer Lösungen möglicherweise überdenken. Sie könnten z. B. feststellen, dass Sie die Testphase um zwei Tage verlängern müssen, und Ihr System wäre dadurch länger ungeschützt als es die Richtlinien erlauben. In diesem Fall würden Sie noch einmal über die Bereitstellung provisorischer Lösungen nachdenken, um Ihre Richtlinien zu erfüllen.

Sie werden die in diesem Arbeitsschritt gewonnenen Informationen verwerten, wenn Sie später einen Testplan für die Updates entwickeln.

7. Definieren eines Testplans

Um effektiv zu sein, müssen die Tests systematisch und sinnvoll aufgebaut sein. Ihr Test sollte auf Bereiche abzielen, die am wahrscheinlichsten Probleme in Ihrer Umgebung aufdecken. Da jede Umgebung anders ist, gibt es kein Standardrezept für einen effektiven Testplan.

In Unternehmen mit geteilten Verantwortungsbereichen wird der Testplan häufig von mehr als einer Gruppe entwickelt. Die Gruppe, die die Technologien oder Systeme verwaltet, die unmittelbar von den Sicherheitsupdates oder provisorischen Lösungen betroffen sind, kann ihre besondere Sachkenntnis einbringen. Die Testgruppe hat spezielle Kenntnisse über die Entwicklung von Testfällen, Optionen für Test-Tools und ein Verständnis praktischer Zeitvorgaben zu bieten.

In dieser Phase sollten Sie ermitteln, wie der Testplan sich auf Ihre Risikoeinstufung der Sicherheitsupdates oder provisorischen Lösungen auswirkt, und Ihren Test- und Bereitstellungsplan entsprechend korrigieren. Sie stellen zum Beispiel fest, dass Sie keinen Testplan erstellen können, um ein Update so umfassend zu testen wie gewünscht. In diesem Fall können Sie die Risikoeinstufung erhöhen, die Bereitstellung auf später verschieben und in der Zwischenzeit provisorische Lösungen implementieren.

8. Entwicklung eines Bereitstellungsplans

Als Bereitstellung wrid die eigentliche Implementierung des Schutzes, den die Sicherheitsupdates oder die provisorischen Lösungen gewähren, bezeichnet. Da die Bereitstellung das letztendliche Ziel des Prozesses ist, ist ein Verständnis der verfügbaren Bereitstellungsmethoden und deren Berücksichtigung bei Ihrer Einschätzung des Sachverhalts ebenso wichtig wie die Einschätzung des Sicherheitsrisikos. In Unternehmen mit geteilten Verantwortungsbereichen werden mögliche Bereitstellungsmethoden für Sicherheitsupdates häufig von den Gruppen ermittelt, die für die Verwaltung der Softwareupdate-Infrastruktur verantwortlich sind, wie die Gruppe, die Systems Management Server (SMS) verwaltet. Gruppen, die Aufsicht über Configuration Management-Technologien wie Active Directory führen, sind möglicherweise an der Ermittlung potenzieller Bereitstellungsmethoden für provisorische Lösungen beteiligt.

Die Zielvorgabe in diesem Arbeitsschritt ist, sich mit den möglichen Bereitstellungsmethoden vertraut zu machen und einen Plan für die Bereitstellung der Sicherheitsupdates oder provisorischen Lösungen auszuarbeiten. Dabei sollten Sie unbedingt berücksichtigen, wie sich die möglichen Bereitstellungsmethoden auf Ihren Terminplan auswirken können, und diesen bei Bedarf korrigieren. Beispiel: Ein Sicherheitsupdate wird nicht von WSUS unterstützt. WSUS ist jedoch Ihre primäre Bereitstellungsmethode. In diesem Fall kommen Sie gegebenenfalls zu dem Schluss, dass die Bereitstellung des Updates zwei Tage länger als geplant dauern wird. Sie können nun beschließen, provisorische Lösungen zu implementieren, um während dieses Bereitstellungszeitfensters den erforderlichen Schutz zu gewährleisten.

Informationen über Bereitstellungsmethoden finden Sie im Abschnitt mit häufig gestellten Fragen (FAQ) im Zusammenhang mit dem Sicherheitsupdate. Informationen über Methoden zur Implementierung von provisorischen Lösungen werden zusammen mit jeder provisorischen Lösung angezeigt; mit jeder Schwachstelle sind individuelle provisorische Lösungen verknüpft.

Die Planungsphase ist nun abgeschlossen. Sie sollten nun einen Terminplan haben, der alle Einschätzungs- und Planungselemente in Bezug auf Sicherheitsrisiko, Risikoeinstufung der Sicherheitsupdates und provisorischen Lösungen, Prüfung und Bereitstellung widerspiegelt. Wie Sie anhand der verschiedenen Phasen erkennen konnten, sind diese untrennbar miteinander verwoben und nicht unbedingt linear. In manchen Unternehmen werden diese Phasen zeitgleich abgewickelt, während sie in anderen Unternehmen der Reihe nach auftreten. Entscheidungen bezüglich der Implementierung dieser Schritte sollten Sie auf der Grundlage der Richtlinien, Anforderungen und Ressourcen Ihres Unternehmens fällen. Das Wichtigste bei diesen Schritten ist nicht die genaue Struktur und Reihenfolge, sondern dafür zu sorgen, dass diese verschiedenen Phasen gut aufeinander abgestimmt sind. Der Schlüssel für jede Implementierung ist, flexibel und anpassungsbereit zu bleiben.

9. Testen von Updates und provisorischen Lösungen

In der Testphase wenden Sie den zuvor definierten Testplan in Ihrer Testumgebung auf die Sicherheitsupdates und provisorischen Lösungen an. Das Ziel in Ihrer Testumgebung besteht darin, die kritischen Elemente in Ihrer Produktionsumgebung zu replizieren. Dadurch, dass Sie die Sicherheitsupdates oder provisorischen Lösungen testen, wollen Sie eventuell auftretenden Probleme vor einer Bereitstellung in Ihrer Produktionsumgebung aufdecken.

Wenn bei den Tests Probleme aufgedeckt werden, sollten Sie ermitteln, wie schwerwiegend diese sind und wie sie sich beheben lassen. Es kann sein, dass Sie kleinere Probleme entdecken, deren Wirkungsgrad in einem akzeptablen Rahmen liegt. Andere wiederum müssen vor der Bereitstellung der Updates bereinigt werden. Sollten Sie beschließen, das Problem zu akzeptieren, dokumentieren Sie dies bitte für Ihr Supportpersonal.

Um das Problem zu lösen, können Sie sich an den Microsoft-Produktsupport (PSS) wenden, der kostenlosen Support für Probleme mit Sicherheitsupdates bietet. Informationen darüber, wie Sie mit dem PSS in Kontakt treten können, finden Sie unter support.microsoft.com/security. Da die Behebung von Problemen einen zeitlichen Mehraufwand für die Tests bedingen und somit die Bereitstellung verzögern kann, sollten Sie die möglichen Folgen für Ihren Terminplan bedenken, bevor Sie beschließen, ein Problem zu beheben.

Nach Abschluss der Tests und nachdem alle Probleme entweder behoben oder dokumentiert wurden, können Sie die Sicherheitsupdates oder provisorischen Lösungen zur Bereitstellung in Ihrer Produktionsumgebung zertifizieren.

10. Bereitstellen von Updates und provisorischen Lösungen

Sobald die Sicherheitsupdates oder provisorischen Lösungen getestet und zertifiziert wurden, können Sie mit der Bereitstellung fortfahren. Während der Bereitstellung sollten Sie sich bei der eigentlichen Implementierung von Sicherheitsupdates oder Konfigurationsänderungen in Systemen am Plan orientieren. Die Gruppen, die an der Entwicklung des Plans mitgearbeitet haben, sind in der Regel für die eigentlichen Bereitstellungen verantwortlich.

Treten bei der Bereitstellung Probleme auf, wenn z. B. ein Sicherheitsupdate durch Ihre Updateverwaltungsstruktur nicht richtig installiert wird, müssen Sie das Problem sorgfältig untersuchen. Wenn das Problem zu Verzögerungen führt, sollten Sie Ihre Optionen überdenken und/oder provisorische Lösungen in Betracht ziehen, um Ihr System zu schützen.

Im Idealfall sollte Ihr Testverfahren vor der Bereitstellung alle Probleme ans Licht bringen, die bei der Produktion auftreten könnten. Sollten Sie jedoch nach der Bereitstellung in Ihrer Produktionsumgebung Probleme erkennen, sollten Sie genauso verfahren, als wäre in der Testphase ein Problem aufgetreten. Untersuchen Sie das Problem und entscheiden Sie, ob Sie es akzeptieren oder beheben wollen.

Wenn Sicherheitsupdates erfolgreich implementiert werden, ist der Schutz gewährleistet, und das letztendliche Ziel dieses Verfahrens wurde erreicht. Werden Sie jedoch nicht erfolgreich implementiert, sind Ihre Systeme nach wie vor anfällig.

Da die Möglichkeit besteht, dass manche Systeme nicht erfolgreich aktualisiert wurden, ist der letzte Schritt des Bereitstellungsverfahrens sehr wichtig: die Überwachung der Systeme, um den Erfolg der Bereitstellung zu kontrollieren. In manchen Unternehmen wird diese Überwachung von einer separaten Überwachungsgruppe durchgeführt, die häufig mit Sicherheitsteams verknüpft ist. Um zu prüfen, ob die Sicherheitsupdates erfolgreich implementiert wurden, eignen sich Microsoft-Tools wie WSUS, MBSA und SMS. Zusätzlich enthält das Sicherheitsbulletin in dem Abschnitt mit Informationen über Sicherheitsupdates Informationen darüber, wie sich die erfolgreiche Implementierung des Sicherheitsupdates kontrollieren lässt.

Schlussbemerkung

Mit dem monatlich erscheinenden Sicherheitsbulletin von Microsoft können Sie regelmäßigere Terminpläne und Abläufe für die Verwaltung von Sicherheitsupdates implementieren. Durch die Entwicklung regelmäßiger Abläufe und Verfahren können Sie Ihre Systeme besser schützen und gleichzeitig Störungen und Ausfallzeiten minimieren.

Zwar sollte jedes Unternehmen eigene, individuelle Abläufe für die Verwaltung von Sicherheitsupdates entwickeln, dennoch sollten in den Abläufen Ihres Unternehmens die in diesem Artikel empfohlenen Arbeitsschritte enthalten sein. Sie benötigen keine separaten Sicherheits- und Updateteams, sollten jedoch sowohl die Sicherheitsrisiken abwägen als auch einen Bereitstellungsplan entwickeln.

Die Kernaussage läuft darauf hinaus, dass Planung eine wichtige Rolle spielt. Bei guter Planung verlaufen die Schritte, in denen die aktive Handlung stattfindet (z. B. die Testphase und die Bereitstellungsphase), sehr viel reibungsloser, was wiederum ein erfolgreiches Sicherheitsupdate-Verfahren zur Folge hat.

Christopher Budd ist Manager für das Sicherheitsprogramm im Microsoft Security Response Center (MSRC). Sein Fachgebiet ist die technische Kommunikation mit IT- und Sicherheitsprofis und anderen Softwareanwendern.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.