Diesen Monat beschäftigt sich unser Blog mit Patch Management. Die heutige Software ist komplex, der Quellcode von Windows umfasst mehrere Millionen Zeilen Code und Schwachstellen werden regelmäßig entdeckt. Gleichzeitig hat sich die Szene der Angreifer, in der sich auch staatliche Akteure mit Zugriff auf immense Ressourcen tummeln, deutlich professionalisiert. Umso wichtiger ist es, diese Schwachstellen durch die vom Hersteller bereitgestellten Patches möglichst schnell zu schließen.

Eine Untersuchung des Sicherheitsanbieters FireEye von 60 Schwachstellen in den Jahren 2018/2019 kommt zu dem Ergebnis, dass 58 Prozent der Schwachstellen schon vor der Veröffentlichung eines Patches ausgenutzt wurden und 27 Prozent innerhalb eines Monats nach Veröffentlichung eines Patches ausgenutzt wurden. Gleichzeitig dauert es in Unternehmen laut einer Studie des Sicherheitsanbieters Edgescan im Durchschnitt bis zu 73 Tage, bis die Sicherheitslücke durch Installation des Patches geschlossen wird. Die Botschaft ist klar, der Patchmanagement Prozess muss beschleunigt werden.

Das klingt auf den ersten Blick banal, aber die Erfahrung bei Kunden zeigt, dass viele Organisationen das Thema nicht vollständig im Griff haben oder im Vergleich zu den Angreifern einfach zu lange brauchen. Zu dem Thema Patchmanagement gibt es in der Literatur und im Netz unzählige Artikel, weshalb wir uns in dem Blogartikel darauf beschränken, unseren „Standardprozess“ zu beschreiben. Mit diesem Standardprozess starten wir in der Regel die Diskussion mit dem Kunden und passen den Prozess auf die konkreten Bedürfnisse und technischen Voraussetzungen beim Kunden an.

Der Patch Management-Prozess umfasst die regelmäßige Identifizierung von vorhandenen Patches sowie die Planung und Installation der Patches im Unternehmen. Voraussetzung für die Identifizierung der Patches ist, dass die eingesetzten Systeme und Software im Unternehmen bekannt sind.

Um die Zeit zwischen Bekanntwerden und Schließen einer Sicherheitslücke zu verkürzen, ist es wichtig, diesen Prozess so weit wie möglich zu automatisieren. Verbreitete Management Tools wie Windows Server Update Services (WSUS) oder Microsoft Endpoint Manager bieten dazu schon eine Reihe von Funktionen für eine Automatisierung:

• Bereitstellen von Patch-Metadaten
• Automatische Inventur von Systemen
• Feststellen von nicht-installierten Patches auf Basis der Metadaten
• Automatische Installation von Patches zu definierten Zeitpunkten
• Berichte über installierte oder nicht-installierte Patches auf allen Systemen

Überblick Patch Management-Prozess

Identifizieren von Patches

Die von den Herstellern veröffentlichten Patches müssen regelmäßig identifiziert und evaluiert werden. Im Falle von sehr dringlichen Updates wie bei den diesjährigen Remote ausnutzbaren Schwachstellen für Microsoft Exchange ist ein monatlicher Aktualisierungszyklus nicht ausreichend. Hier muss ein Emergency Patch-Prozess vorgesehen sein, um die Patches möglichst schnell und wenn notwendig auch manuell auf den betroffenen Systemen zu installieren. Die restlichen Patches werden im Rahmen des normalen Patch-Prozesses im Regelintervall (in den meisten Fällen alle 4 Wochen) installiert.

Für die Identifizierung der Patches sind Management Tools sehr hilfreich, die die Metadaten der Patches für Microsoft und idealerweise für verbreitete Softwarehersteller zur Verfügung stellen und regelmäßig aktualisieren. Auf Basis dieser Metadaten können diese Management Tools alle verwalteten Systeme scannen und feststellen, welche Patches installiert oder nicht installiert sind. So kann auch eine weitgehende Automatisierung vieler Prozess-Schritte erreicht werden.

Für Systeme, die nicht automatisch mit Management Tools verwaltet werden, wie z.B. Server in einer DMZ oder in der Tier 0 in einer ESAE-Umgebung, muss festgelegt werden, wie dort die Vorgehensweise ist. In diesen Fällen bietet es sich häufig an, eine separate WSUS-Umgebung bereitzustellen.

Das BSI gibt auch regelmäßig Cyber-Sicherheitswarnungen über neue und bedrohliche Angriffsvektoren heraus.

Planung

In den meisten Fällen werden Patches monatlich ausgerollt. Hier ist es dann sinnvoll, alle Patches zu bündeln und diese zur selben Zeit in einem Wartungsfenster zu installieren. Patches im Rahmen des Emergency Patch-Prozesses werden separat installiert.

Wenn ein ITIL-konformes Change Management implementiert ist, wird die Installation der Patches durch das Change Advisory Board (CAB) genehmigt. Da die Installation von Patches eine regelmäßig wiederkehrende Aktivität ist, wird hierfür normalerweise ein Standard Change definiert, der automatisch genehmigt wird.

Testen von Patches

Für das Testen von Patches ist sehr hilfreich, eine Testumgebung zu haben. Diese sollte idealerweise möglichst nahe an der Produktionsumgebung sein. In der Testumgebung sollten die wesentlichen Infrastrukturdienste wie Active Directory, Exchange oder SharePoint installiert sein, natürlich in einer kleineren Ausführung, aber trotzdem in ähnlicher Konfiguration. Für Active Directory bedeutet das mindestens zwei Domain Controller oder bei SQL Server in einer Clusterkonfiguration, wenn das in Produktion auch der Fall ist (im Test reichen dann in der Regel zwei Knoten aus).

Beim Testen sollte der jeweilige Infrastrukturdienst oder die Applikation nach der Installation von Patches auf Funktionsfähigkeit geprüft werden. Hier helfen automatisierte Tests, die Aufwände und die kritische Zeit bis zur Installation der Patches zu reduzieren. Monitoring-Werkzeuge wie System Center Operations Manager können hier sehr hilfreich sein, weil sie regelmäßig prüfen, ob ein Dienst auch tatsächlich erreichbar ist.

Ausrollen von Patches

Das Ausrollen von Patches sollte, um Risiken zu minimieren nicht auf alle Systeme gleichzeitig erfolgen. Dazu werden verschiedene Rollout-Gruppen definiert, auf die die Patches sukzessive zu unterschiedlichen Zeiten installiert werden. Zwischen den Installationszeiten der einzelnen Rollout-Gruppen liegt ausreichend Puffer, um bei auftretenden Problemen reagieren zu können.

Die Systeme werden kategorisiert und den verschiedenen Rollout-Gruppen zugewiesen. Dabei sollten die Systeme, die einen bestimmten Dienst implementieren, unterschiedlichen Rollout-Gruppen zugewiesen werden. Zum Beispiel Domain Controller 1 an die Rollout-Gruppe 1 und Domain Controller 2 an die Rollout-Gruppe 2.

Zur Automatisierung komplexerer Abhängigkeiten kann ein Runbook Automation Tool wie System Center Orchestrator verwendet werden.

Zwischen dem Deployment der verschiedenen Rollout-Gruppen werden Tests durchgeführt. Diese Tests werden von den jeweiligen Server- bzw. Applikations-Verantwortlichen nach den Anforderungen der Applikation durchgeführt.

Bei einem vollautomatisierten Ausrollverfahren für Patches sollte es die Möglichkeit geben, die Installation eines Patches für ein bestimmtes System zu verhindern.

Verifizieren

Nach der Installation wird geprüft, ob die Patches tatsächlich installiert sind. Bei den gängigen Management Tools wird die Prüfung automatisch durchgeführt. Der Status wird in der Regel in web-basierten Berichten dargestellt. SQL Server Reporting Services bietet dabei die Möglichkeit, Berichte zu bestimmten Zeitpunkten zu erzeugen und diese an E-Mailverteiler zu versenden. Darüber hinaus enthalten sie eine Umgebung zur Entwicklung von Berichten, die an die Anforderungen des Unternehmens angepasst sind und essentielle Informationen für das Management aufbereiten.

Patch Compliance Overall

Ergänzend kann es sehr sinnvoll sein, einen Schwachstellen-Scanner wie Nessus einzusetzen. Dieser durchsucht die Systeme im Netzwerk und prüft, ob die Schwachstelle ausnutzbar ist.

Vorgehensweise

Hier wollen wir eine Standardvorgehensweise für die Umsetzung eines Patch Management-Prozesses skizzieren.

Implementierungsprojekt

Am Beginn steht ein Implementierungsprojekt, dessen Umfang von den Zielen des Kunden, der Anzahl der Systeme und Applikationen und der Reife des vorhandenen Prozesses abhängt. Eine typische Projektstruktur kann folgende Aktivitäten umfassen:

Patch-Zyklus

Im Folgenden werden die Aktivitäten, die in einem Patch-Zyklus anfallen, beschrieben. In den meisten Unternehmen wird dieser monatlich durchgeführt. In Microsoft-lastigen Unternehmen hat es sich eingebürgert, den Patch-Zyklus am „Patch Tuesday“ von Microsoft auszurichten. Microsoft veröffentlicht seine Patches immer am zweiten Dienstag im Monat. Dieser Vorgehensweise haben sich zwischenzeitlich einige weitere Hersteller angeschlossen.

Zunächst werden die von den Herstellern veröffentlichten Patches identifiziert. Die Patches werden in einem Release (und ggf. in einem Emergency Release) zusammengefasst. Das Patch-Release wird auf vorbereiteten Wellen für Testsysteme installiert. Diese Systeme befinden sich normalerweise in einer getrennten Testumgebung. In größeren Unternehmen sind die Testumgebungen häufig mehrstufig. Falls eine solche nicht vorhanden ist, werden dedizierte Testsysteme innerhalb der Produktionsumgebung verwendet. Wenn eine Testumgebung zwar vorhanden ist, diese aber die Produktionsumgebung nur sehr eingeschränkt reflektiert, bietet es sich an, einige Produktionssysteme in die Testwelle mitaufzunehmen.

Die Patches werden in mehreren Wellen ausgerollt. Zu den einzelnen Wellen sind die Systeme in der Regel statisch zugeordnet. Das bedeutet, diese werden einmal konfiguriert und an dieser Konfiguration muss während des regelmäßigen Patch-Zyklus keine Änderung vorgenommen werden. In vielen Patch Management-Tools können die erforderlichen Schritte auch automatisiert werden. Die Installation der Patches muss überprüft werden. Dazu bieten die gängigen Patch Management-Tools web-basierte Berichte an.

Der hier dargestellte Prozess illustriert, wie die Installation der Patches im Unternehmen in kurzer Zeit durchgeführt werden kann. Selbstverständlich muss dieser bei einer Implementierung auf die Anforderungen und Rahmenbedingungen angepasst werden.

Zusammenfassung

Im Detail gibt es sicherlich noch viele weitere Aspekte, die beachtet werden müssen, wir hoffen jedoch, euch eine Idee gegeben zu haben, wie ein schneller Patch Management Prozess aussehen kann. Gebt uns gerne Feedback dazu.