Die Verwaltung von Sicherheitspatches

Patrick Chambet

patrick@chambet.com

http://www.chambet.com

Die Verwaltung von Sicherheitspatches - das Patch Management - ist heute eines der Schlüsselelemente beim Schutz von Informationssystemen. Noch vor wenigen Jahren war das Management von Softwarekorrekturen nur in einem ganz beschränkten Systembereich notwendig: hauptsächlich für besonders empfindliche und/oder exponierte Server, wie zum Beispiel für Server, die vom Internet aus erreichbar waren. Leider ist es heute nicht mehr so einfach.

Der wichtigste Grund ist die immer wieder neue Verbreitung von Viren und anderen, sich selbst verbreitenden Würmern. Die Bedrohung hat sich mit dem Auftreten der Würmer wie CodeRed, Nimda, Blaster, ZoTob usw., die die Sicherheitslücken der marktüblichen Softwareprogramme ausnutzen, vergrößert. Und auch die Angriffsfläche hat sich beträchtlich ausgeweitet: Es reicht heute nicht mehr aus, nur empfindliche oder exponierte Server zu schützen, denn jede Maschine (zum Beispiel der Büro-PC eines Anwenders) ist ein potentielles Ziel und kann sich in eine Kontaminierungsquelle verwandeln. Zugegeben, die Auswirkungen auf die einzelnen Geräte sind gering, aber da Millionen von PCs mit Würmern infiziert sind, die ganze Adressbereiche auf der Suche nach verwundbaren Maschinen durchforsten, kann das gesamte interne Firmennetzwerk für mehrere Tage außer Gefecht gesetzt werden, ganz zu schweigen von den möglichen Randeffekten der fraglichen Würmer oder Viren (Zerstörung von Dateien, Verbreitung von vertraulichen Dokumenten aus dem Verzeichnis „Eigene Dateien" oder dem Arbeitsplatz nach außen usw.).

Die Untersuchung der wichtigsten Würmer, von denen die Unternehmen in den letzten Jahren weltweit infiziert wurden, zeigt im übrigen, dass sich die Lage immer weiter verschlechtert. Für Würmer von CodeRed bis hin zu ZoTob hat sich die Vorbereitungszeit (von der Veröffentlichung der Schwachstelle durch den entsprechenden Hersteller bis zum Auftauchen eines Wurms, der die fragliche Sicherheitslücke ausnutzt) zum Beispiel erheblich verkürzt: 11 Monate für Nimda, 6 Monate für SQL Slammer und nur drei Wochen für Blaster. Oder gar im Fall des Witty-Wurms, der ISS-Produkte infizierte: er tauchte am Tag nach der offiziellen Veröffentlichung der Sicherheitslücke, die er ausnutzte, auf.

Auch die Verbreitungsgeschwindigkeit der Würmer (der Zeitraum zwischen dem Auftauchen der ersten Würmer und dem Erreichen der Höchstzahl der kontaminierten Maschinen weltweit) beschleunigt sich: von einigen Tagen bei CodeRed bis hin zu nur wenigen Minuten für SQL Slammer.

Die Verwaltung von Sicherheitspatches

Wir müssen also handeln, wenn wir keine Zeit (und Geld) verlieren möchten, indem wir erst im Fall der Kontamination reagieren: Es geht darum, proaktiv zu sein und nicht nur zu reagieren. Das hindert uns natürlich nicht daran, ein Notfallverfahren als Antwort auf das Auftreten eines neuen Wurms, der eine verbreitete Sicherheitslücke ausnutzt oder eines neuen Virus einzurichten. Deshalb ist es interessant, das Patch Management in das SOC (Security Operations Center) und in die allgemeine Sicherheitsüberwachung zu integrieren (lesen Sie bitte die anderen Artikel über die überwachung der Sicherheit in diesem Dossier).

Die mit der Verwaltung von Sicherheitspatches verbundene Problematik wird auf den ersten Blick deutlich: man muss „einfach“ nur in regelmäßigen Abständen die Softwarekorrekturen installieren, die von den Herstellern zur Korrektur der Lücken in ihren Betriebssystemen, Produkten und Anwendungen herausgegeben werden. In der Praxis jedoch stoßen die Unternehmen rasch auf zahlreiche Schwierigkeiten, die proportional zur Größe und Komplexität ihrer IT-Systeme steigen: zu lange Reaktionszeiten, eine Vielzahl an Systemarten und damit verbundene Schwachstellen, fehlendes technisches Know-how, Regressionsprobleme, Verteilungskosten, Verwaltung mobiler Geräte usw. Das Verfahren zur Verwaltung der Patches im Unternehmenskontext muss deshalb industrialisiert werden.

Eine Lösung besteht in der Definition von Strategien zum proaktiven Patch Management, die auf die Bedrohungen und branchenspezifischen Einschränkungen des Unternehmens angepasst sind, und in ihrer Implementierung mit Hilfe der markterhältlichen Automatisierungswerkzeuge. Wir werden diesen Artikel also damit beginnen, die verschiedenen Managementstrategien für Sicherheitspatches zu beschreiben und dabei vom Einsatz in einem großen Unternehmen ausgehen. Dann werden wir einen raschen überblick über die Werkzeuge zur Verwaltung der Patches liefern, bei dem wir detaillierter auf die von Microsoft gelieferten Werkzeuge eingehen.

Managementstrategien für Sicherheitspatches

Die Problematik, die mit der Verwaltung der Sicherheitspatches verbunden ist, hängt vom jeweiligen Kontext ab. Die Strategie für das Patch Management in der Produktion zum Beispiel ist eine andere als im Büro. Auch die Strategie für die regelmäßige Anwendung der Patches unterscheidet sich von der des Krisenmanagements, das dem beim Auftauchen einer kritischen Schwachstelle oder eines Wurms im internen Netz eingesetzt wird.

In den folgenden Abschnitten werden wir mit der Analyse des normalen, sich wiederholenden Verfahrens für die Verwaltung der Patches beginnen, indem wir die verschiedenen Ansätze in verschiedenen Umgebungen erklären.

Sich wiederholende Verfahren

Zunächst einmal möchten wir uns hier selbst in einen proaktiven Modus schalten. Die meisten Hersteller verteilen ihre Patches in regelmäßigen Abständen, um es den Administratoren auf diese Weise zu ermöglichen, Testzyklen durchzuführen und die Patches zu verteilen, damit die individuellen Patches gemeinsam verteilt werden können. Microsoft verteilt seine „nicht dringenden“ Sicherheitspatches zum Beispiel einmal pro Monat (jeden zweiten Dienstag im Monat) und Oracle veröffentlicht seine größeren Patches alle 3 Monate („Oracle Critical Patch Update").

Das Managementverfahren für Patches ist ein iterativer Prozess. Dabei sind insbesondere folgende Schritte zu berücksichtigen:

Die Verwaltung von Sicherheitspatches

1 - Analyse

Zunächst einmal müssen der Bestand innerhalb des Unternehmens, in den verschiedenen Umgebungen (Produktion, Produktionsvorbereitung, Integration, Bürotechnik, Netzwerk…) analysiert und eine Risikountersuchung durchgeführt werden, bei der die empfindlichsten Verfahren und Systeme berücksichtigt werden.

Eine umfassende Bestandsaufnahme des Computerparks, unter anderem auch der mobilen Computer (in einer großen Anzahl von Fällen die Hauptursache für Probleme) erlaubt es, alle notwendigen Informationen über die Systemtypen und Anwendungen, ihre Versionen, ihre Position (zum Beispiel DMZ oder mitten in der Produktion) zu sammeln. Der Einsatz eines Werkzeugs für die Bestandsaufnahme und Verwaltung der Geräte ist häufig unerlässlich zum Sammeln der Informationen und vor allem, um damit eine zeitliche Kohärenz aufrecht zu erhalten.

Es ist auch möglich, Nessus-Vulnerability Scanner einzusetzen, obwohl wir hier auf die nachfolgenden Schritte vorgreifen (siehe Artikel über VDS in derselben Ausgabe).

2 - Sicherheitsüberwachung

Nachdem der Bestand aus Hard- und Software bestimmt wurde, ist es das Ziel der Sicherheitsüberwachung, neu entdeckte und/oder veröffentlichte Schwachstellen in Bezug auf die bestehende Umgebung zu identifizieren und eventuelle Updates zu finden, die von den Herausgebern oder Lieferanten – und zwar auf vertrauenswürdige Weise – zur Verfügung gestellt werden. Herausgebern oder Lieen Herausgebern oder Lieeionen liefern.Gruppe, der ein ne adäquate Reaktion handelt, n eines Wurm

Diese Sicherheitsüberwachung kann von einem internen Sicherheitsteam, von einer mit der Verwaltung des Informatikparks betrauten Instanz ist oder auch extern durchgeführt werden.

3 - Qualifikation

Ziel der Qualifikation ist es einerseits, die Ausnutzbarkeit der im vorherigen Schritt identifizierten Schwachstellen und ihre möglichen Folgen zu bestimmen, andererseits aber auch abzuschätzen, wie wichtig die Verteilung von Patches in den unterschiedlichen Unternehmensumgebungen ist und festzulegen, ob das anzuwendende Verfahren normal oder dringend ist.

Dieser Schritt ist von größter Bedeutung: hier wird entschieden, ob ein Patch in einem Unternehmen eingesetzt wird oder nicht, und wenn ja, unter welchen Bedingungen und in welchem Umfang. Der Kontext der zukünftigen Verteilung beeinflusst sowohl die Beurteilung des Schweregrads der Schwachstelle als auch die Kosten der Patch-Verteilung.

Lassen Sie uns als Beispiele eine Büro- und eine Produktionsumgebung nehmen.

Büroumgebung

Auf bestimmte Weise ist der Bürokontext am einfachsten. Die von Microsoft veröffentlichen Softwarekorrekturen werden zurzeit auf extrem sorgfältige Weise getestet, Randeffekte bei ihrem Einsatz werden immer seltener. Eine große Anzahl an Unternehmen hat sich dafür entschieden, die von Microsoft verteilten Sicherheitspatches (insbesondere solche, die als kritisch eingestuft werden) nach einem eingeschränkten Testzyklus für die Gesamtheit der Windows-Geräte einzusetzen, insbesondere auf Workstations. In der Praxis sind Kompatibilitätsprobleme mit Client-Anwendungen auf den Workstations sehr selten und beruhen immer häufiger auf der Tatsache, dass die eingesetzten Softwarepakete veraltet sind. Bei Auftauchen eines Wurms im internen Netzwerk, der versucht, bereits gepatchte Schwachstellen auszubeuten, liegt es auf der Hand, wie groß der Vertrauensgewinn ist.

Produktionsumgebung

Im Produktionskontext dagegen muss die Qualifikation der Patches vorsichtiger und sorgsamer beurteilt werden. Man kann keine Patches auf Anwendungsservern installieren, ohne sich zuvor zu vergewissern, dass die Auswirkungen auf ihre Funktionsweise mit den Serviceverträgen zu vereinbaren sind.

In sehr großen Geräteparks (mehrere Tausend Server) ist es darüber hinaus häufig aus zwei wichtigen Gründen nicht möglich, alle von den Herstellern verteilten Patches anzuwenden:

Hinzu kommt noch die Problematik obsoleter Systeme, für die die Hersteller keine Sicherheitskorrekturen mehr liefern (zum Beispiel Windows NT 4.0). Das kann bei einer Wiederverwendung des vorhandenen Bestandes in einem sehr großen Gerätepark passieren, dessen Vorgeschichte sich nicht erschließt oder wenn der Park Softwareelemente enthält, die man nicht beherrscht (zum Beispiel bei Ericsson-Geräten). In diesem Fall ist es darüber hinaus sogar verboten, die Systeme zu aktualisieren, die auf einer derartigen Lösung laufen, denn damit erlischt die Herstellergarantie!

Während der Qualifikationsphase, die im Allgemeinen durch das Sicherheitsteam oder die interne Entwicklungsabteilung ausgeführt wird, sind in der Produktionsumgebung die für die Anwendung zuständigen Mitarbeiter sehr wichtig: sie sind es, die die auf den Servern laufenden Anwendungen kennen und deshalb auch die eventuellen Auswirkungen der Patches beurteilen können. Das gilt insbesondere für Software-Pakete (SAP, Siebel…) und etwas weniger im Fall von Patches der zugrunde liegenden Betriebssysteme.

Bei Oracle können die funktionalen Auswirkungen der Patches groß sein: Insbesondere die ziemlich voluminösen Oracle-Softwarekorrekturen erfordern häufig ein Angleichen einer großen Anzahl abhängiger Geräte. Eine Aktualisierung ähnelt hier eher einem Migrationsprojekt als einem einfachen Sicherheitsupdate. Die Bewertung durch die für die Anwendungen zuständigen Mitarbeiter ist in diesem Fall obligatorisch.

4 - Tests

Nachdem die Qualifikation durchgeführt wurde, muss das Sicherheitspatch in einer Umgebung getestet werden, die in ausreichendem Maße repräsentativ für die Zielumgebung ist. Für Workstations reichen einige Installationen auf den Masterrechnern aus, welche die von den Anwendern am häufigsten eingesetzten Anwendungen enthalten.

Für die Produktion kann man natürlich Anwendungstests verwenden. Durch die überwachung der Produktionsvorbereitung während eines bestimmten Zeitraums ist es dann möglich sich zu vergewissern, dass keinerlei Randeffekte oder Regressionsprobleme auftreten.

Vergessen Sie bitte auch nicht, die Deinstallation der Patches für den Fall zu testen, in dem ein Zurückgehen auf den Ausgangszustand notwendig ist.

5 – Planung und Verteilung

Während dieser Phase werden Einsatz und Verteilung der Patches auf den Zielsystemen vorbereitet und ausgeführt.

Für die Planung sind folgende Punkte zu berücksichtigen:

Wir empfehlen Ihnen, sich in einem großen Gerätepark während dieser Phase auf eine Software zur Verteilung der Patches zu stützen, um auf diese Weise zu vermeiden, dass sie sich sogar im proaktiven Modus über einen zu langen Zeitraum hinzieht. Eine gute Managementsoftware für Softwarekorrekturen beinhaltet eine Hierarchiefunktion für Patches abhängig vom Schweregrad der Schwachstellen und entdeckt Inkompatibilitätsprobleme zwischen den Patches bereits vor ihrem Einsatz. Einige Tools wie Shavlik zum Beispiel unterstützen darüber hinaus heterogene Umgebungen. Im folgenden Kapitel werden wir einige Werkzeuge für das Patch Management untersuchen.

Die Anwendung von Patches im manuellen Modus ist auf bestimmten Maschinen weiterhin möglich oder sogar notwendig, zum Beispiel für Server, die sich in bestimmten DMZ befinden.

Die Verteilung sollte auf jeden Fall in übereinstimmung mit dem eventuellen Service Provider erfolgen.

6 - überprüfung

Während dieser letzten Phase wird überprüft, ob die Patches korrekt auf den Zielsystemen durchgeführt wurden. Hierzu kann man die Logs und Berichte nutzen, die von den Werkzeugen generiert werden, die für die Anwendung der Patches eingesetzt werden (insbesondere WSUS, siehe weiter unten) oder Vulnerability Scanner (Nessus) oder Patch-Scanner (zum Beispiel MBSA 2.0 für Windows).

Wenn Systeme entdeckt werden, auf denen die Anwendung der Patches gescheitert ist, ist es so möglich, die Ursache anhand einer Analyse herauszufinden und eine neue Installation der Patches in Angriff zu nehmen.

Diese überprüfung muss regelmäßig erfolgen, damit zum Beispiel eventuelle nicht-aktualisierter Systeme entdeckt werden können.

Dringende Verfahren

Der Modus der dringenden Installation eines Patches ist ein reaktiver Modus der eingesetzt wird, wenn in der überwachungsphase ein wichtiges Risiko identifiziert wurde. Es kann sich zum Beispiel um die Verbreitung eines Wurms im internen Netz ausgehend von einem tragbaren Gerät eines Dienstleisters handeln (obwohl eine derartige Verbindung einer Workstation verboten sein sollte). Dies könnte auch der Fall sein, wenn Server, die vom Internet aus erreichbar sind, Schwachstellen aufweisen (Beispiel: Verwundbarkeit von Apache, IIS oder auch eine Schwachstelle der TCP/IP-Stacks wie bei TCP CAN-2004-0230).

In diesem Fall müssen alle folgenden Schritte (Qualifikation und dringende Testes, sofortige automatische und manuelle Verteilung) in weniger als 48 Stunden erfolgen. Im Fall eines Wurms können darüber hinaus ergänzende Maßnahmen zur Filterung auf Ebene der Firewalls, Router, Personal Firewalls etc. getroffen werden.

Werkzeuge für das Management von Sicherheitspatches

Wir haben gesehen, dass die klassischen Ansätze, die auf manuellen (apt-get) oder halb-automatischen (Mircosoft Update, RHN) Ansätzen beruhen, für ein großes Unternehmen nicht ausreichen. Das Patch Management muss also so automatisiert werden, dass es die überwachung der Patch-Anwendung vereinfacht, es muss bei Auftreten einer neuen Bedrohung (zum Beispiel eines neuen Angriffs) reaktiv sein und die Patches vor dem Einsatz testen können, damit der Ausgangszustand im Fall eines Problems wiederhergestellt werden kann.

Die Verwendung eines Tools zu Patchverwaltung sollte eine Reihe von Bedingungen erfüllen, insbesondere: Wer? Was? Wann? Wo? Wie?

Bestimmte Werkzeuge unterstützen heterogene Plattformen standardmäßig: PatchLink unterstützt zum Beispiel Windows, Unix (Solaris, IBM AIX, und HP UX), Linux, Macintosh und NetWare. Manche Tools erfordern den Einsatz eines Agenten auf den Maschinen, andere nicht. Agenten bieten häufig eine größere funktionale Vielfalt (zum Beispiel SMS) und verbrauchen weniger Bandbreite, die Kosten für ihren Einsatz müssen jedoch zuvor beurteilt werden.

Microsoft-Umgebungen

Microsoft bietet mehrere Werkzeuge zum Patch Management an:

In den folgenden Absätzen werden wir diese Tools genauer untersuchen.

MBSA

MBSA 2.0 (Microsoft Baseline Security Analyzer) ist eines der einfachsten Windows-Werkzeuge. Es wurde ursprünglich von Shavlik herausgegeben. Eine kostenlose Version dieses Werkzeuges kann an folgender URL heruntergeladen werden: http://www.microsoft.com/technet/security/tools/mbsahome.mspx

MBSA 2.0 kann lokal oder entfernt folgende Systeme scannen: Windows 2000 SP3 und höher sowie Windows XP und Windows Server 2003. Neben den Windows-Sicherheitspatches unterstützt es außerdem eine große Anzahl an Microsoft-Produkten:

Und die anderen Produkte, die von Microsoft Update unterstützt werden (siehe: http://support.microsoft.com/?scid=kb;en-us;895660)

MBSA kann im Grafikmodus (mbsa.exe starten) oder in der Befehlszeile (mbsacli.exe starten) ausgeführt werden. In der Befehlszeile ist es möglich, Batch-Dateien zur Automatisierung des Werkzeuges zu einzusetzen. Hier ein Beispiel für ein Script, das ein System scannt und die Ergebnisse in einer XLM-Datei speichert:

set cname=%computername%

set uname=%username%

"C:\Program Files\MBSA\mbsacli.exe" /nvc /nosum /c %cname% /n

IIS+OS+SQL+Password /o %cname%

copy "%userprofile%\SecurityScans\%cname%.xml"

"\\%cname%\c$\Documents and Settings\%uname% \SecurityScans\"

MBSA-Funktionsweise:

Dies sind die verschiedenen Schritte des MBSA-überprüfungsverfahrens nach seinem Start:

1- MBSA analysiert die Konfiguration der Sicherheit des analysierten Systems. Es deckt die häufigsten Konfigurationsfehler auf wie zum Beispiel:

Eine vollständige Liste der von MBSA ausgeführten Sicherheitstests finden Sie in der Datei Checks.csvim Verzeichnis von MBSA.

2- MBSA lädt dann eine Katalogdatei als Sicherheitsreferenz im XML-Format herunter: es handelt sich um eine Datei mit der Bezeichnung „mssecure.xml". MBSA kann diese Datei direkt aus dem Internet oder ausgehend von einem internen WSUS-Server herunterladen.

Aus dem Internet testet MBSA nacheinander folgende Links:

Die CAB-Datei enthält eine komprimierte Version der Datei mssecure.xml.

Bitte beachten Sie, dass es auch möglich ist, diese Katalogdatei von folgenden Links auf der Shavlik-Seite aus herunterzuladen:

Wenn MBSA die Datei mssecure.xml nicht herunterladen kann, verwendet es eine lokale Kopie (die letzte heruntergeladene Version). Sie können die Datei mssecure.xml also von Shavlik herunterladen und mit MBSA verwenden. Beachten Sie jedoch, dass diese Operation nicht von Microsoft unterstützt wird.

3- MBSA analysiert die Patches des gescannten Systems im Vergleich zur Katalogdatei.

4- MBSA findet fehlende Sicherheitspatches und Service Packs und zeigt die entsprechenden Meldungen in seinem Bericht an.

Die Datei mssecure.xml ist sehr wertvoll: Sie enthält alle Sicherheitspatches, die seit 1998 veröffentlicht wurden sowie die dazugehörigen Beschreibungen. Für jedes Patch werden insbesondere folgende Informationen geliefert:

Die Datei mssecure.xml enthält außerdem eine Historie der früheren Patches, die seither in den kumulativen Patches oder in den Service Packs enthalten sind. Diese XML-Datei wird natürlich immer dann geändert, wenn ein neues Patch veröffentlicht wird.

MBSA-Script

Die MBSA-Scans können anhand von Scripts automatisiert werden: Auf diese Weise ist es möglich, Tests im großen Maßstab durchzuführen. Weitere Informationen finden Sie hier:

http://www.microsoft.com/technet/security/tools/mbsascript.mspx

Sie können zum Beispiel die Scripts batchscan.js und rollup.js herunterladen, mit denen das Scannen einer unbegrenzten Anzahl von Systemen oder IP-Adressen ausgehend von einer Datei möglich ist und dann die Ergebnisse in einem einzigen zusammenfassenden Bericht zusammentragen (XML-Datei), der über den Internet Explorer angezeigt werden kann.

Microsoft Update

Microsoft Update ist ein Werkzeug zur Online-überprüfung und -Installation von Patches, das in zwei Modi eingesetzt werden kann: im manuellen Modus, wenn Sie mit dem Internet Explorer auf die Adresse http://windowsupdate.microsoft.com surfen und im automatischen oder halb-automatischen Modus unter Verwendung des Dienstes „Automatic Updates" auf der Client-Seite. Microsoft Update ist ideal für kleine Unternehmen geeignet.

Wird es im Automatikmodus eingesetzt, muss für „Automatic Updates“ – mit dem eine automatische Aktualisierung im Hintergrund möglich ist – der BITS-Dienst (Background Intelligent Transfer Service) aktiviert sein. Dieser Dienst verwendet nicht genutzte Bandbreiten, um Patches von der Microsoft-Webseite herunterzuladen und hält den Vorgang für den Anwender dabei vollständig transparent.

Der Client Microsoft Update überprüft, ob jedes Patch korrekt auf dem lokalen Rechner installiert wurde. Hierzu führt er überprüfungen auf mehreren Ebenen durch:

Die Aktualisierung läuft im Hintergrund und bleibt für den normalen Anwender transparent. Die Hinweise über neue Patches werden dem lokal eingeloggten Anwender nur dann angezeigt, wenn er Administrator-Rechte hat:

Diese Mitteilung hat genau dieselbe Form wie die des WSUS-Clients (siehe unten).

Windows Server Update Services

WSUS ist ein kostenloses Werkzeug, das an folgender URL heruntergeladen werden kann:

http://www.microsoft.com/windowsserversystem/updateservices/downloads/WSUS.mspx

Anders als bei MSUS 1.0, dass ausschließlich Windows-Patches verwaltet, kann WSUS jetzt Patches folgender Produkte verwalten:

Das Prinzip von WSUS besteht darin, einen „Microsoft Update"-Server in Ihrem Unternehmen zu bringen: die Sicherheitspatches liegen hierbei auf einem oder mehreren internen Servern. Jedes Mal, wenn neue Sicherheitspatches veröffentlicht werden, muss der Administrator die notwendigen Patches genehmigen. Diese werden dann auf interne WSUS-Server heruntergeladen. Dann stellen die Geräte der Anwender automatisch eine Verbindung zu einem der internen Server her, um gültige Patches herunterzuladen und anzuwenden.

WSUS verwendet eine Administrationsschnittstelle im Web (http://wsus.votre-intranet.com/WSUSAdmin/) und benötigt IIS 6.0 auf den internen WSUS-Servern mit Windows Server 2003.

WSUS-Funktionsweise

WSUS funktioniert ein bisschen so wie MBSA, wobei sich jedoch die Formate unterscheiden: Auch WSUS benötigt eine Katalogdatei als Sicherheitsreferenz. WSUS führt jeden Tag eine Synchronisierung in folgenden Schritten durch:

Scheitert die programmierte Synchronisierung, versucht WSUS es mit einem Intervall von 30 Minuten erneut.

Eine erweiterte WSUS-Architektur sieht wie folgt aus:

WSUS ist ein sehr leistungsstarkes Tool, mit dem eine Politik implementiert werden kann, die typisch für das ist, was wir zuvor gesehen haben und beantwortet dabei die verschiedenen gestellten Fragen:

- Wer? Die Client-Seite, der Dienst „Automatic Updates“, läuft mit SYSTEM-Rechten. Wenn ein Anwender Administrator ist, darf er die Patches anwenden (siehe oben). Normale Anwender dürfen die automatische Anwendung der Patches nicht ablehnen, können die Patches jedoch auch nicht selbst installieren.

Nachdem WSUS in ihrem internen Netzwerk installiert wurde, empfehlen wir Ihnen die Microsoft Update-Domains auf Proxy-Ebene zu sperren, so dass kein Anwender seine Maschine auf eigene Initiative aktualisieren kann. in Anwender eine ender eine e, ren.önnen jelltenmplementiert werden kann, die typisch für das ist, weas wis Jahre Es handelt sich insbesondere um folgende Domains:

http://www.windowsupdate.com

http://windowsupdate.microsoft.com

http://update.microsoft.com

- Was? Der WSUS-Server überprüft die Signatur der Updates, um sicher zu gehen, dass sie auch tatsächlich von Microsoft herausgegeben wurden. Dann werden abhängig vom Zielrechner (Betriebssystemversion, Sprache etc.) die geeigneten Updates ausgewählt (unter denen, die vom Administrator genehmigt wurden).

- Wann? Die Patches werden automatisch jeden Tag zu einer bestimmten Uhrzeit, die Sie definieren können, angewendet. Eine zufallsbedingte Frist zwischen den verschiedenen Clients vermeidet, dass Verbindungen zum WSUS-Server gleichzeitig hergestellt werden. Wenn die angegeben Uhrzeit überschritten wurde, werden die Patches auch beim Gerätestart angewandt.

- Wo? Die Patches werden auf jedem Rechner angewandt, auf dem der Client Automatic Updates konfiguriert ist. Zum Erhalt der Updates wird vom WSUS-Server ein HTTP-Pull verwendet.

- Wie? Die Aktualisierungen werden zunächst vom Administrator genehmigt. Dann werden die Patches zwischen dem WSUS-Hauptserver und den sekundären WSUS-Servern übertragen und schließlich im Hintergrund bei gleichzeitiger Optimierung der Bandbreite mithilfe des BITS-Dienstes an die Clients versandt. Danach werden die Patches automatisch auf jedem Rechner – im Hintergrund oder im Vordergrund – installiert. Falls notwendig, wird ein einzelner Neustart durchgeführt. Abschließend werden die Synchronisierungs- und Genehmigungsprotokolle (im XML-Format) aktualisiert.

WSUS bietet mehrere Verteilungspunkte für Windows-Patches. Auch die Replikation zwischen den internen WSUS-Servern basiert auf den „Automatic Updates“-Diensten und BITS und erlaubt es so, eine im Netz nicht genutzte Bandbreite einzusetzen. Trotzdem kann der Transfer der Updates sehr lang dauern (manchmal sogar Tage!). Bedenken Sie dabei aber bitte, dass ein kompletter Patch-Satz für ein Windows-System (2000/XP/2003) zurzeit etwa 1 GB pro Spracheversion ausmacht.

Systems Management Server

SMS 2.0 und SMS 2003, die ursprünglich für die Verwaltung von Computerparks vorgesehen waren (Bestand, Fernverteilung von Anwendungen etc.) können allein oder in Kombination mit ergänzenden Werkzeugen verwendet werden, die von Microsoft angeboten werden und auf die Verteilung von Sicherheitspatches spezialisiert sind. ilung vno gen werden und afu die Verteilung vno atches für ein System auf Windows 2000/XP/2003 zurzeit etw

WSUS kann mithilfe des Tools ITMU (Inventory Tool for Microsot Updates) in SMS 2003 SP1 integriert werden. ITMU ist kostenlos und ermöglicht die Bestimmung des Patchstatus entfernter Systeme. Dieses Werkzeug unterstützt die Patches von Windows Update und Microsoft Update und ist in der Lage, sie auf den Systemen nach Bedarf zu verteilen (siehe die Links am Ende dieses Artikels).

Sie können SMS 2.0 und SMS 2003 jedoch auch ohne ITMU einsetzen, um Sicherheitspatches zu verteilen, auch wenn das nicht das ursprüngliche Ziel von SMS war. Um Ihnen das Leben zu vereinfachen, können Sie zum Beispiel ein SMS-Paket als „intelligenten Patch-Starter“ erstellen, so dass eine Neukompilierung bei jedem zusätzlichen Patch nicht mehr notwendig ist. Das Hinzufügen eines Patches kann mit der Erstellung einer einfachen .INI-Datei erfolgen, in der die Voraussetzungen, die Parameter in der Befehlszeile und die für eine ordnungsgemäße Ausführung notwendigen Informationen beschrieben werden.

Darüber hinaus können Sie in ein solches SMS-Paket auch andere Anwendungspatches einfügen, wie zum Beispiel die Aktualisierung der Antivirensysteme auf den Workstations.

Unix-Umgebung

In der Unix-Umgebung hat jeder Hersteller seine eigenen Mechanismen und seine eigenen Tools zur Verwaltung der Patches entwickelt. Darüber hinaus bieten die großen Akteure im Bereich des Gerätemanagements wie Tivoli, BMC, Novell oder Computer Associates, aber auch die Patch Management-Spezialisten wie Criston, Landesk, Altiris, RippleTech, Ecora Software, Tenable, Shavlik, PatchLink und St Bernard Software interessante, heterogene und integrierte Lösungen an.

Diese Werkzeuge verwenden im Allgemeinen die gleichen Tools wie die, die wir weiter oben vorgestellt haben: Analyse des Patchstatus, Download der Sicherheitspatches, Validierung, Verteilung, überprüfung der korrekten Anwendung und schließlich Berichterstellung.

Hier eine zusammenfassende Tabelle mit Werkzeugen (Unix, aber auch Microsoft und Oracle), die von den Herstellern – oft kostenlos – angeboten werden. Einige dieser Tools sind manuell (apt-get) einzusetzen, andere sind automatisierbar (zum Beispiel RHN):

OS Scan-Tool für Patch Patch Management-Tool
SUN Solaris pkginfo patchadd, smpatch, install_cluster, Sun Update Manager, Solaris Patch Manager, JumpStart
HP-UX Security Patch Check Tool (security_patch_check) Patch Assessment Tool, Custom Patch Manager
IBM AIX lslpp instfix, installp
Linux RedHat   up2date, rpm (RPM Package Manager), RHN (Red Hat Network)
Linux Debian   dpkg, apt-get (Advanced Package Tool)
Windows MBSA 2.0 Microsoft Update, WSUS, SMS
Oracle   Patch Wizard, AutoPatch

Zusammenfassende Tabelle der Patch Management-Tools, die von den Herstellern angeboten werden

Schlussfolgerung

Wie wir gesehen haben, kann sich heutzutage kein Unternehmen vom Einsatz einer wirkungsvollen Politik für das Management von Sicherheitspatches freimachen. Es existieren zahlreiche Werkzeuge, ihr Einsatz erfordert jedoch globale überlegungen, um den Zeitraum zu reduzieren, in dem eine Sicherheitslücke ausgenutzt werden kann und gleichzeitig die Unternehmensaktivitäten nicht zu belasten.

Wir möchten darauf hinweisen, dass sich einige Hersteller nunmehr sehr intensiv damit befassen, ihre Software weniger verwundbar (standardmäßige, restriktivere Konfiguration des Betriebssystems zum Beispiel) oder exponiert (integrierter aktivierter Firewall in Windows XP SP2, Schutz des Arbeitsspeichers gegen buffer overflows in Windows 2003 und Windows XP SP2) zu machen, während gleichzeitig das Patch Management (insbesondere mit WSUS) vereinfacht wird.

Dennoch tauchen regelmäßig immer leistungsstärkere  „Automated Hacking“-Formen auf, so dass es dringender als je zuvor wird, die Sicherheitsprobleme von Morgen bereits heute vorauszusehen.

Weitere Informationen:

- Methode für ein Patch Management-Verfahren:

- Management von Microsoft-Patches

- MBSA :

- WSUS :

- SMS :

- MBSA 2.0 :

- SUN :

- HP :

- IBM :

- Linux RedHat :

- Linux Debian :

- Oracle :