Patchmanagement und Testing

Autor: Johannes Schmidt, MCSEboard.de

Jeder Administrator in einem mittleren bis großen Unternehmen könnte vermutlich abendfüllende Geschichten zu den Interessenskonflikten beim Patchen Erzählen. Das Business bzw. der Anwendungsinhaber will einfach nur, dass sein System immer verfügbar ist und ist dabei wenig verständnisvoll wenn man ein scheinbar tadellos funktionierendes System wegen eines zu installierenden Patches über Nacht neu starten muss. Ein evtl. vorhandener IT-Security Officer oder gar die interne oder externe Revision dagegen werden es kaum gerne sehen, wenn ein sicherheitsrelevanter Patch nicht zeitnah auf den Systemen installiert wird.

In diesem Artikel werde ich nun versuchen einige Denkanstöße zu liefern, wie ein funktionsfähiges Patchmanagement in einem Unternehmen aussehen kann bzw. sollte.

Warum sind Patches wichtig?

Diese Frage wird man als Administrator schon des Öfteren gehört haben. Die Antwort darauf ist für Administratoren naheliegend und an sich keine Frage wert – Patches beseitigen Fehler, die beim Erstellen des Programms bzw. des Betriebssystems gemacht wurden. Einige dieser Fehler führen z. B. „nur“ zu Abstürzen von Diensten. Andere ermöglichen es Benutzern, ihre Rechte zu erweitern und wieder andere ermöglichen es, beliebigen Personen aus dem Netzwerk sich administrativen Zugang auf einem System zu beschaffen.

Als sehr effektive und lehrreiche Möglichkeit, dieses Thema den entsprechenden Entscheidungsträgern näher zu bringen, ist eine live Demo (natürlich mit einem Testsystem!). Tools hierfür findet der versierte Administrator in wenigen Minuten im Internet. Beispielhaft sei an dieser Stelle das Framework "Matasploit" erwähnt.

Was muss wann gepatcht werden?

Grundsätzlich alle Systeme im eigenen Netzwerk. Dies umfasst nicht nur die verwendeten Betriebssysteme sondern auch die darauf installierten Anwendungen. Oft vernachlässigt werden vor allem Netzwerkkomponenten wie Router, Switches oder gar Firewalls. Auch für diese Systeme werden in regelmäßigen Abständen Aktualisierungen veröffentlicht, welche sicherheitsrelevante Probleme beseitigen.

Um möglichst kein eingesetztes Produkt beim Patchen zu vernachlässigen, empfiehlt es sich eine Art Datenblatt für jedes Produkt zu erstellen, welches die aktuell verwendeten Versionsstände sowie einen Link zu der Herstellerseite beinhaltet. Des Weiteren ist es sinnvoll, für jedes Produkt zu entscheiden, in welchen Intervallen der Versionsstand der eigenen Software sowie die zur Verfügung stehenden Patches geprüft werden sollten. Diese Prüfung sollte möglichst durch das Namenskürzel z. B. in einem Excelsheet oder auf einer papierhaften Checkliste dokumentiert werden.

Das Intervall der Prüfung sollte bei keinem Produkt länger als 3 Monate sein. Sicherheitskritische Produkte wie Firewalls sollten einer täglichen Prüfung unterzogen werden. Bei Betriebssystemen wie denen von Microsoft kann man sich den Intervallen der so genannten „Patchdays“ anpassen.

Testen von Patches

Auch das Testen von Patches sollte nicht vernachlässigt werden. Die Vergangenheit hat gezeigt, dass einige Patches nicht nur einen Fehler beseitigt sondern auch Fehler produziert haben. Die Palette reicht hier von Performanceverlusten bis hin zu nicht mehr bootenden Systemen. Diese Tatsache sollten Sie jedoch nicht als Entschuldigung missbrauchen, um sich vor dem Patchen zu drücken. Mit der richtigen Vorbereitung kann man das Risiko weitgehend reduzieren. Sie sollten also, bevor Sie sich daran machen alle Ihre Server und Clients zu aktualisieren, zuerst einige Testläufe unter möglichst realistischen Bedingungen in Ihrer Testumgebung durchführen. In Zeiten der Virtualisierung ist der technische Aufwand hierfür durchaus vertretbar. In der Praxis hat sich zudem gezeigt, dass es durchaus sinnvoll ist, seine Systeme in Patchgruppen zu unterteilen und z. B. an den ersten beiden Patchtagen nur 50 % der Systeme zu patchen und an den Folgetagen (wenn keine Probleme aufgetreten sind) die nächsten 50 %.

Dokumentation der installierten Patches

Auch beim Patchen bleibt man nicht davon verschont – Dokumentation ist auch hier wichtig und gewinnt in Zeiten von BASEL II und SOX weiter an Bedeutung.

Sie sollten daher sicherstellen, dass als Minimum folgende Schritte dokumentiert werden:

  • Die regelmäßige Überprüfung auf neue Patches sowie das jeweilige Ergebnis
  • Die Durchführung des Testings der Patches

© MCSEboard.de, Johannes Schmidt