Die meisten Patch-Programme scheitern nicht daran, dass das Team die einzelnen Schritte nicht kennt. Sie scheitern an den Lücken dazwischen: an der Anlage, die nie in das Inventar aufgenommen wurde, an dem Patch, der drei Wochen lang im Status „genehmigt“ auf ein Wartungsfenster wartete, oder an dem Bereitstellungsbericht, den niemand überprüft hat, weil das Dashboard bereits eine Compliance-Rate von 96 % anzeigte.

Ein solider Patch-Management-Prozess sorgt dafür, dass aus diesen unsicheren Übergaben wiederholbare Abläufe werden. Er bietet Ihnen eine Abfolge von Schritten, die Sie befolgen können, eine Möglichkeit, zu überprüfen, wann ein Schritt tatsächlich abgeschlossen ist, und eine klare Antwort, wenn ein Prüfer fragt, wie Sie entschieden haben, welche Patches am vergangenen Dienstag installiert wurden.

Dieser Leitfaden führt Sie Schritt für Schritt durch den gesamten Lebenszyklus. Sie erfahren, was in den einzelnen Phasen geschieht, wer in der Regel dafür verantwortlich ist, an welchen Stellen der Prozess am häufigsten ins Stocken gerät und wie lange jeder Schritt in einer reibungslos funktionierenden Umgebung ungefähr dauern sollte. Die RMM-Software von Kaseya verwaltet die Patch-Verwaltung für Millionen von Endgeräten für MSPs und interne IT-Teams, was ein recht klares Bild davon vermittelt, wo es zu Problemen kommt und wie eine „optimale“ Abwicklung in den einzelnen Phasen des Prozesses aussieht.

Was ist ein Patch-Management-Prozess?

Wenn Sie sich mit diesem Thema noch nicht auskennen, lesen Sie zunächst unseren umfassenden Leitfaden„Was ist Patch-Management?“ und kehren Sie anschließend hierher zurück. Für alle anderen gilt: Der Prozess ist das operative Rückgrat hinter der Definition. Es handelt sich um einen wiederholbaren Zyklus, bei dem eine Sicherheitslücke oder eine Hersteller-Veröffentlichung in einen gepatchten, geprüften und dokumentierten Endpunkt umgewandelt wird.

In der Praxis wird dieser Vorgang auf verschiedene Weise bezeichnet: Lebenszyklus des Patch-Managements, Workflow des Patch-Managements, Verfahren des Patch-Managements oder einfach nur „Patching-Prozess“. Alle diese Bezeichnungen beschreiben dasselbe. Die Anzahl der Schritte variiert zwischen vier und zehn, je nachdem, wer darüber schreibt, doch die zugrunde liegende Logik ändert sich dabei kaum.

Wir arbeiten hier mit sieben Schritten, da dies der Detaillierungsgrad ist, bei dem jede Phase einen klaren Verantwortlichen und ein klares Ergebnis hat. Bei weniger Schritten beginnen die einzelnen Schritte ineinander zu verschwimmen. Bei mehr Schritten erfindet man Unterscheidungen, die in der Praxis gar nicht existieren.

Bevor wir ins Detail gehen, sollte eines klargestellt werden: Der Prozess für routinemäßige, geplante Patches unterscheidet sich von dem für Notfall- oder Zero-Day-Patches. Die Schritte mögen auf dem Papier ähnlich aussehen, doch die Zeitrahmen, Genehmigungsstufen und die Risikotoleranz sind deutlich enger gesteckt. Wir werden beide Fälle behandeln, wobei wir den Routineablauf als Grundlage nehmen und auf die Abweichungen im Notfall dort eingehen, wo sie am wichtigsten sind.

Ablauf des Patch-Managements: 7 wichtige Schritte

Ein solider Patch-Management-Prozess beschreibt einen wiederholbaren Ansatz, um Updates zu ermitteln, zu priorisieren, zu installieren und zu überprüfen, ohne sich auf Vermutungen verlassen zu müssen. Im Folgenden wird der typische Ablauf des Prozesses von der Erfassung der IT-Ressourcen bis hin zur Berichterstellung beschrieben.

Schritt 1: Bestandsaufnahme und Ermittlung der Ressourcen

Verantwortlicher: In der Regel der Endgeräte- oder Systemadministrator, unter Einbeziehung der Sicherheitsabteilung.

Was man nicht kennt, kann man auch nicht patchen. Der erste Schritt besteht darin, ein vollständiges, genaues und aktuelles Inventar aller Geräte, Betriebssysteme, Anwendungen und Firmware-Versionen in Ihrer Umgebung zu erstellen und zu pflegen. Dazu gehören Server, Workstations, Laptops, mobile Geräte, virtuelle Maschinen, Netzwerkgeräte, IoT-Geräte sowie alle von Ihnen verwalteten Cloud-Workloads.

Das Ideal ist keine Tabellenkalkulation, die jemand vierteljährlich aktualisiert. Es ist ein kontinuierlich aktualisierter Bestand, der auf automatisierter Erfassung basiert und in dem jede Ressource mit Informationen zur Software-Stückliste, zur Betriebssystemversion, zum Zeitpunkt der letzten Überprüfung und zum Eigentümer angereichert ist. Jede Lücke in diesem Bestand wird zu einer Lücke in Ihrer Patch-Abdeckung, und jede Lücke in der Abdeckung zeigt sich später in Form eines Hosts, von dem niemand wusste, dass er eine nicht mehr unterstützte Version von OpenSSL lief.

Häufige Fehlerquellen: BYOD-Geräte, auf denen der Agent nicht läuft, Laptops von Auftragnehmern, die sich einmal pro Quartal mit dem VPN verbinden, der Laborserver, den jemand eingerichtet und dann vergessen hat zu registrieren, sowie alles, was sich in einem Cloud-Abonnement befindet, das einem einzelnen Team gehört.

Zeitaufwand: Der Discovery-Prozess läuft kontinuierlich. Das erstmalige Erreichen einer als vollständig anzusehenden Baseline dauert in der Regel ein bis vier Wochen, abhängig von der Größe der Umgebung und dem Ausmaß der Schatten-IT.

Schritt 2: Überwachung und Identifizierung von Patches

Verantwortlicher: In der Regel gemeinsam von der IT- und der Sicherheitsabteilung.

Sobald Sie wissen, welche Systeme Sie im Einsatz haben, müssen Sie sich darüber informieren, welche Lösungen zur Behebung von Problemen zur Verfügung stehen. Dieser Schritt umfasst die regelmäßige Verfolgung von Patch-Veröffentlichungen aller Anbieter, deren Software in Ihrer Umgebung läuft, sowie von Sicherheitshinweisen der CISA, der PSIRT-Teams der Anbieter und aus Quellen für Bedrohungsinformationen, um Schwachstellen zu identifizieren, die möglicherweise eine außerplanmäßige Reaktion erfordern.

Für Microsoft, Adobe und Oracle ist dieser Prozess relativ strukturiert. Der „Patch Tuesday“ findet immer am zweiten Dienstag des Monats statt, die Sicherheitsbulletins sind vorhersehbar und die meisten Patch-Management-Tools übernehmen sie automatisch. Die Probleme treten überall sonst auf. Browser, Videokonferenz-Tools, Laufzeitbibliotheken, Nischen-Branchenanwendungen, Netzwerk-Firmware und Druckertreiber werden alle nach ihrem eigenen Rhythmus veröffentlicht – oft ohne großes Aufsehen. Dies ist eines der stärksten Argumente für ein Patch-Management-Tool, das die Erkennung von Drittanbieter-Patches nativ übernimmt, anstatt Ihr Team dazu zu zwingen, Hunderte von RSS-Feeds manuell zu überwachen.

Häufige Fehlerquellen: Das vollständige Übersehen von Releases von Drittanbietern, das Übersehen von „Out-of-Band“-Sicherheitshinweisen, die zwischen den „Patch Tuesdays“ eingehen, sowie die Behandlung von CVE-Feeds als maßgebliche Quelle anstelle der Sicherheitshinweise der Hersteller.

Zeitaufwand: Fortlaufend. Von der Veröffentlichung bis zur Erkennung in Ihrer Umgebung sollten Sie diesen Zeitraum bei Tier-1-Anbietern in Stunden und bei allen anderen Anbietern innerhalb von ein bis zwei Tagen messen.

Schritt 3: Risikobewertung und Priorisierung

Verantwortlicher: Sicherheitsabteilung, unter Einbeziehung der IT hinsichtlich der betrieblichen Auswirkungen.

Die meisten Teams verfügen über mehr Patches, als sie testen und bereitstellen können. Durch Priorisierung stellen Sie sicher, dass die wichtigsten Patches zuerst bereitgestellt werden.

Der traditionelle Ansatz bestand darin, nach dem CVSS-Wert zu sortieren und alle kritischen Schwachstellen zu beheben. Das hat nach wie vor seine Berechtigung, ist aber für sich genommen zu pauschal. Eine Schwachstelle mit einem CVSS-Wert von 9,8 in einer Software, die nicht mit dem Internet verbunden ist, für die kein Exploit bekannt ist und die auf drei internen Hosts läuft, stellt ein anderes Problem dar als eine Schwachstelle mit einem CVSS-Wert von 7,5, für die es einen funktionierenden Exploit gibt, der in der Praxis aktiv gegen Unternehmen Ihrer Branche eingesetzt wird. Ein risikobasierter Ansatz berücksichtigt nicht nur den Schweregrad, sondern auch die Kritikalität der Ressourcen, die Gefährdung, die Verfügbarkeit von Exploits und die geschäftlichen Auswirkungen.

Hier kommen der CISA-Katalog „Known Exploited Vulnerabilities“ und die Threat-Intelligence-Feeds voll zum Tragen. Sie geben Aufschluss darüber, welche Sicherheitslücken Angreifer ausnutzen – und das ist ein weitaus besserer Anhaltspunkt dafür, welche Patches zuerst installiert werden sollten, als CVSS allein.

Das Ergebnis dieses Schritts ist eine nach Priorität geordnete Liste mit groben Zeitplänen. Ein gängiges Rahmenkonzept sieht wie folgt aus: Kritische Patches werden innerhalb von 48 bis 72 Stunden bereitgestellt, Patches mit hoher Priorität innerhalb von 14 Tagen, solche mit mittlerer Priorität innerhalb von 30 Tagen und solche mit niedriger Priorität innerhalb von 90 Tagen. „Cyber Essentials“ in Großbritannien schreibt vor, dass Patches für Schwachstellen mit einer Bewertung von 7,0 oder höher innerhalb von 14 Tagen bereitgestellt werden müssen, was sich als nützliche Richtlinie für Unternehmen etabliert hat, die dieses Niveau der Compliance-Reife anstreben. Unabhängig davon, welche Zeitrahmen Sie festlegen, sollten Sie diese in Ihrer Patch-Management-Richtlinie dokumentieren, damit sie im weiteren Verlauf des Prozesses berücksichtigt werden.

Häufige Fehlerquellen: Die ausschließliche Orientierung am CVSS-Score, das Ignorieren von Daten zur Ausnutzbarkeit, die Gleichsetzung aller als „kritisch“ eingestuften Patches, das umgekehrte Problem, Zeitpläne als Fristen statt als Zielvorgaben zu betrachten, sowie das Warten bis zum 13. Tag mit der Bereitstellung.

Zeitaufwand: Stunden pro Patch-Zyklus, wenn Ihre Tools die Hauptarbeit übernehmen. Ein ganzer Tag oder mehr, wenn Ihr Team jede Sicherheitsempfehlung manuell bewertet.

Schritt 4: Patch-Test

Verantwortlich: IT-Betrieb, unter Einbeziehung der Anwendungsverantwortlichen bei Patches mit hohem Risiko.

Das Testen ist der Schritt, der als Erstes gestrichen wird, wenn ein Team unter Druck steht, und es ist der Schritt, dessen Auslassung am meisten bedauert wird. Der Sinn des Ganzen besteht darin, den Patch zu erkennen, der einen Fehler verursacht, bevor er in die Produktion gelangt.

Erfahrene Teams nutzen Bereitstellungsringe oder schrittweise Rollouts. Ein Patch wird zunächst auf einer repräsentativen Auswahl von Testrechnern installiert, die idealerweise eine Mischung aus verschiedenen Hardwaremodellen, Betriebssystemversionen und wichtigen Anwendungen umfasst. Nach 24 bis 72 Stunden störungsfreiem Betrieb wird er auf eine größere Pilotgruppe ausgeweitet. Erst dann wird er auf die gesamte Produktionsumgebung übertragen. Die genaue Anzahl der Ringe ist weniger wichtig als das Prinzip: Zu keinem Zeitpunkt sollte eine einzelne Bereitstellung alle Endgeräte gleichzeitig betreffen.

Bei Routine-Patches dauert die Testphase in der Regel 24 bis 72 Stunden. Bei Notfall- oder Zero-Day-Patches können Sie diese Phase auf einige Stunden Smoke-Testing in einem kleinen Ring verkürzen, bevor Sie den Patch flächendeckend bereitstellen, wobei Sie das höhere Risiko in Kauf nehmen, um das Sicherheitslückenfenster schneller zu schließen. Dieser Kompromiss sollte eine bewusste Entscheidung sein und nicht die Standardvorgehensweise.

Häufige Fehlerquellen: Das vollständige Auslassen von Tests in kleinen Umgebungen, das Testen ausschließlich auf Hardware, die nicht der Produktionsumgebung entspricht, das Erklären eines Patches als „getestet“, nachdem ein einzelner Host 30 Minuten lang gelaufen ist, sowie das Fehlen eines Rollback-Plans für den Fall, dass etwas schiefgeht.

Voraussichtliche Bearbeitungszeit: 24 bis 72 Stunden für Standard-Patches, zwei bis zwölf Stunden für Notfälle, je nach Risikotoleranz.

Schritt 5: Bereitstellung

Verantwortlicher: IT-Betrieb

Bei der Bereitstellung geht es um die praktische Umsetzung. Patches werden gemäß einem festgelegten Zeitplan und innerhalb der mit dem Unternehmen vereinbarten Wartungsfenster von der Staging-Umgebung in die Produktionsumgebung übertragen.

Dieser Schritt birgt mehr Fehlerquellen als jeder andere im gesamten Prozess, vor allem, weil hier die chaotische Realität ins Spiel kommt. Laptops, die zum Zeitpunkt der Bereitstellung nicht mit dem Netzwerk verbunden sind. Endnutzer, die Neustarts immer wieder aufschieben. Server, bei denen aufgrund von Abhängigkeiten eine sorgfältige Reihenfolge eingehalten werden muss. Patches, für die zunächst ein bestimmter Dienst beendet werden muss. Geräte außerhalb des Netzwerks, die sich seit Wochen nicht mehr gemeldet haben.

Ein gut konfiguriertes RMM-Tool erledigt den Großteil der Arbeit hier im Hintergrund. Es verteilt Patches gemäß den Richtlinien, versucht es erneut, sobald die Rechner wieder online sind, führt Neustarts innerhalb vereinbarter Zeitfenster durch und meldet Ausnahmen, die manuell bearbeitet werden müssen. Was Sie in dieser Phase von Ihrem Tool erwarten, sind hohe Erfolgsraten bei der Bereitstellung ohne manuelles Nachverfolgen sowie Einblick in die „Long Tail“-Geräte, die den Patch beim ersten Mal nicht angenommen haben.

Wartungsfenster spielen eine größere Rolle, als man denkt. Ein Patch, der mitten in einer Krankenhausschicht einen Neustart eines klinischen Arbeitsplatzrechners erfordert, wird verschoben – was bedeutet, dass der Patch tatsächlich nicht installiert wird, auch wenn Ihr Dashboard das Gegenteil anzeigt. Die Abstimmung der Wartungsfenster auf die tatsächlichen Betriebsabläufe ist der entscheidende Unterschied zwischen Patch-Programmen, die gute Ergebnisse ausweisen, und solchen, die Risiken tatsächlich reduzieren.

Häufige Fehlerquellen: Die Annahme, dass „bereitgestellt“ bedeutet, dass der Patch installiert ist, obwohl damit eigentlich nur gemeint ist, dass das Paket gesendet wurde; das Ignorieren der zahlreichen Geräte, die nicht mit dem Netzwerk verbunden oder nicht konform sind; die Bereitstellung ohne abgestimmte Wartungsfenster sowie das Fehlen eines Rollback-Plans für den Fall, dass eine Bereitstellung den Produktivbetrieb beeinträchtigt.

Zeitaufwand: Für die technische Bereitstellung selbst sind pro Rechner Minuten bis Stunden erforderlich; der Gesamtzeitaufwand für die vollständige Abdeckung der gesamten Infrastruktur im Rahmen eines routinemäßigen Patch-Zyklus beträgt jedoch in der Regel ein bis zwei Wochen, wenn man Geräte außerhalb des Netzwerks, aufgeschobene Neustarts und die Behandlung von Ausnahmen berücksichtigt.

Schritt 6: Überprüfung

Verantwortlicher: IT-Betrieb, mit Überprüfung durch die Sicherheitsabteilung.

Die Überprüfung ist der Schritt, von dem die meisten Teams wissen, dass sie ihn besser durchführen sollten. Das Ziel besteht darin, nach Abschluss der Arbeiten sicherzustellen, dass jeder Patch auf jedem Zielgerät installiert ist und die zugrunde liegende Sicherheitslücke geschlossen wurde.

Hier gibt es zwei Aspekte. Erstens: Wurde der Patch erfolgreich installiert? Die meisten Patch-Management-Tools geben darüber Auskunft, doch hinter der Antwort verbirgt sich oft eine lange Reihe von Zuständen wie „Neustart ausstehend“ oder „zurückgestellt“, die zwar auf den ersten Blick in Ordnung erscheinen, es aber nicht sind. Zweitens: Ist die Sicherheitslücke tatsächlich behoben? Ein separater Schwachstellen-Scan nach der Patch-Installation deckt Fälle auf, in denen ein Patch zwar installiert wurde, die Schwachstelle jedoch nicht vollständig behoben wurde, oder in denen eine damit zusammenhängende Schwachstelle bestehen bleibt, weil ein anderer Patch erforderlich gewesen wäre.

Die Diskrepanz zwischen der von Ihrem Patching-Tool gemeldeten „Erfolgsquote bei der Bereitstellung“ und der von Ihrem Scanner gemeldeten „Schließungsquote bei Sicherheitslücken“ ist häufig der Grund für Beanstandungen bei Audits. Ein Team, das eine Patch-Compliance von 98 %, aber eine Schließungsquote bei Sicherheitslücken von nur 85 % meldet, hat eine Prozesslücke – kein Problem mit dem Tool.

Häufige Fehlerquellen: Das Vertrauen auf Kennzahlen zum Erfolg der Bereitstellung als Nachweis für die Fehlerbehebung, das Fehlen eines Scans nach der Bereitstellung sowie das Versäumnis, die „Long Tail“-Fälle fehlgeschlagener Bereitstellungen zu untersuchen.

Voraussichtliche Dauer: 24 bis 48 Stunden nach der Bereitstellung, bis der Scan nach dem Patch-Einbau ausgeführt wurde und fehlerfreie Daten liefert.

Schritt 7: Berichterstattung und Dokumentation

Verantwortlicher Bereich: IT-Betrieb, häufig gemeinsam mit den Bereichen Sicherheit und Compliance.

Der Zyklus ist nicht abgeschlossen, sobald die Patches überprüft wurden. Er ist erst dann abgeschlossen, wenn die Maßnahmen so dokumentiert sind, dass sie den Prüfern die Einhaltung der Sorgfaltspflicht belegen, der Unternehmensleitung Trends aufzeigen und als Grundlage für die Verbesserung des nächsten Zyklus dienen.

So sieht eine gute Dokumentation aus: Ein Datensatz pro Patch-Zyklus, aus dem hervorgeht, was veröffentlicht wurde, was Priorität hatte, was bereitgestellt wurde, was fehlgeschlagen ist und warum, welche Ausnahmen gewährt wurden und für welche Assets. Kennzahlen zur Zeit bis zur Patch-Installation, aufgeschlüsselt nach Schweregrad. Prozentsätze der Patch-Compliance nach Kunde, Abteilung oder Asset-Klasse. Ein klarer Prüfpfad, dem ein externer Prüfer folgen kann, um den Patch-Verlauf jedes einzelnen Endpunkts zu überprüfen.

Genau hier liegen auch Ihre Verbesserungsmöglichkeiten. Wenn 30 % Ihrer kritischen Patches außerhalb des 14-Tage-Fensters landen, lautet die Frage nicht: „Wie können wir die Bereitstellung beschleunigen?“, sondern: „Wo in den vorangegangenen sechs Schritten geht die Zeit verloren?“ Die Antwort liegt fast immer entweder bei Schritt drei (die Priorisierung dauert zu lange) oder bei Schritt fünf (die Bereitstellung weist zu viele Ausnahmen auf). Die Dokumentation ist es, die diese Diagnose erst möglich macht.

Häufige Fehlerquellen: Dokumentation als nachträglicher Einfall, Dashboards, die den Einsatz ohne Kontext darstellen, fehlender Überprüfungszyklus, fehlender Zusammenhang zwischen Kennzahlen und Prozessverbesserungen.

Zeitaufwand: Monatliches Besprechungstreffen sowie fortlaufende Erfassung der Kennzahlen. Die Berichterstellung selbst sollte automatisiert sein; zeitaufwendig sind die manuelle Überprüfung und die daraus resultierenden Prozessänderungen.

Wie Notfall-Patches den Prozess verändern

All das beschreibt den üblichen Ablauf beim Patchen. Wenn eine Zero-Day-Schwachstelle oder eine aktiv ausgenutzte Sicherheitslücke auftritt, verkürzt sich dieser Ablauf. Es gelten zwar weiterhin dieselben sieben Schritte, doch der Zeitrahmen schrumpft von Wochen auf Stunden.

In einem Notfall-Patch-Zyklus erfolgt die Identifizierung innerhalb weniger Stunden nach der Sicherheitswarnung, die Priorisierung wird im Wesentlichen für Sie festgelegt (es ist kritisch, es wird ausgenutzt, es wird veröffentlicht), das Testen beschränkt sich auf einen schnellen Smoke-Test in einem kleinen Netzwerk, und die Bereitstellung erfolgt flächendeckend mit der Erwartung, dass gewisse Störungen einer anhaltenden Sicherheitslücke vorzuziehen sind. Die Überprüfung und Dokumentation werden straffer gehandhabt, da ein Audit-Gespräch stattfinden wird.

Das Risiko bei Notfallmaßnahmen besteht in der Regel nicht darin, dass man zu schnell vorgeht. Vielmehr liegt es darin, keinen Plan zu haben, sodass das Team unter Druck improvisieren muss und wichtige Schritte überspringt. Ein dokumentierter Notfall-Patch-Prozess, der einen benannten Entscheidungsträger, eine vorab genehmigte Umgehung der üblichen Änderungskontrolle und einen getesteten Rollback-Pfad umfasst, ist das, was ein schnelles Patchen sicher macht.

In welchen Fällen unterscheidet sich der Patching-Prozess je nach Umgebung?

Server, Endpunkte, Anwendungen von Drittanbietern und Cloud-Workloads nutzen alle dasselbe siebenstufige Grundgerüst, weisen jedoch in wesentlichen Punkten unterschiedliche Besonderheiten auf.

Bei Servern spielt der Abhängigkeitsgraph eine größere Rolle. Wird ein Patch auf einem Datenbankserver in einer falschen Reihenfolge im Verhältnis zu den davon abhängigen Anwendungsservern installiert, kann dies zu stundenlangen Ausfällen führen. Die Wartungsfenster sind enger, die Änderungskontrolle strenger und die Planung von Rollbacks ist unverzichtbar. Die Zeit bis zur Behebung nicht kritischer Server-Sicherheitslücken ist in der Regel länger als bei Endgeräten, und das ist auch angemessen.

Bei Endgeräten ist der „Long Tail“ das Problem. Laptops, die mitgenommen werden, Geräte, bei denen der Neustart aufgeschoben wird, und Benutzer, die das Gerät herunterfahren, anstatt es neu zu starten. Die Patch-Verwaltung für Endgeräte erfordert einen zuverlässigen Umgang mit Geräten, die nicht mit dem Netzwerk verbunden sind, sowie eine Lösung für die unvermeidlichen 5–10 % der Rechner, die einen bestimmten Patch-Zyklus verpassen.

Bei Anwendungen von Drittanbietern ist der Umfang das Problem. In einer typischen Umgebung gibt es Dutzende von Anwendungen von Drittanbietern, von denen jede ihren eigenen Release-Zeitplan hat, und ein erheblicher Anteil der Sicherheitsverletzungen geht auf eine nicht gepatchte Anwendung eines Drittanbieters zurück und nicht auf ein nicht gepatchtes Betriebssystem. Dies ist so bedeutend, dass wir diesen Aspekt separat behandelt haben. Die operativen Details finden Sie in unserem speziellen Leitfaden zum Patch-Management für Anwendungen von Drittanbietern.

Bei Cloud-Workloads stellt die Unveränderlichkeit eine bahnbrechende Neuerung dar. In einer ordnungsgemäß konzipierten Cloud-Umgebung wird eine laufende Instanz nicht gepatcht, sondern durch eine neue Instanz ersetzt, die auf der Grundlage eines gepatchten Images erstellt wurde. Der siebenstufige Prozess gilt nach wie vor, doch Schritt fünf ähnelt eher der Image-Erstellung und dem Austausch von Instanzen als einer Softwareinstallation. In hybriden Umgebungen werden letztendlich beide Muster parallel angewendet, worin der Großteil der betrieblichen Komplexität liegt.

Wo der Prozessablauf am häufigsten ins Stocken gerät

In Umgebungen, in denen das Patch-Programm nicht so eingesetzt wird, wie es sein sollte, tauchen immer wieder bestimmte Muster auf.

Der erste Grund ist eine unvollständige Bestandsaufnahme. Wenn der erste Schritt lückenhaft ist, zieht sich diese Lücke durch alle nachfolgenden Schritte. Die Hosts, von denen Sie nichts wissen, erhalten keine Patches, und genau diese Hosts werden von Angreifern oft als Erstes ausfindig gemacht, da sie aus demselben Grund, aus dem sie nicht in der Bestandsaufnahme erfasst sind, schlecht gewartet werden.

Der zweite Punkt ist die Lücke zwischen Test und Bereitstellung. Patches werden getestet, als freigegeben markiert und warten dann auf ein Wartungsfenster, das vom Unternehmen immer wieder verschoben wird. Zwei Wochen später ist der Patch immer noch nicht in der Produktion, und die ursprüngliche Dringlichkeit ist verflogen. Die Lösung hierfür ist in der Regel eine engere Verknüpfung zwischen Freigabe und Bereitstellung sowie weniger, dafür aber zuverlässigere Wartungsfenster.

Der dritte Punkt ist der „Long Tail“ der nicht konformen Geräte. Das Dashboard zeigt 95 % an. Die verbleibenden 5 % sind in jedem Zyklus dieselben 5 %, und es handelt sich fast immer um die wichtigsten 5 %. Die Laptops der Führungskräfte, die Server, an die sich niemand heranwagen will, die Laborumgebung mit ihren eigenen Regeln. Ein ausgereiftes Programm macht diesen „Long Tail“ sichtbar, benennt Verantwortliche für jede Ausnahme und arbeitet die Probleme ab, anstatt sie zu ignorieren.

Der vierte Punkt betrifft die Überprüfung ausschließlich anhand des Bereitstellungsstatus. Das Tool meldet einen Erfolg, das Team macht weiter, doch der Schwachstellenscan drei Wochen später zeigt, dass 8 % der vermeintlich gepatchten Umgebung nach wie vor anfällig sind. Um diese Lücke zu schließen, müssen die Ergebnisse des Schwachstellenscans als maßgebliche Quelle für die Behebung herangezogen werden – und nicht der Bereitstellungsbericht des Patch-Tools.

Die Kombination dieser Fehlerursachen ist der Grund dafür, dass Unternehmen durchschnittlich 209 Tage benötigten, um die 17 Sicherheitslücken in Edge-Geräten zu schließen, die Verizon in seinem DBIR 2025 erfasst hat – während Angreifer diese Schwachstellen bereits nach fünf Tagen ausnutzen konnten. Das Problem liegt in den Prozessen, nicht im mangelnden Bewusstsein.

Wie die modernen Tools von Kaseya den Prozess verändern

Manuelles Patchen funktioniert in jedem nennenswerten Umfang nicht. Das Volumen der Releases, die Vielfalt der Plattformen und die Geschwindigkeit, mit der Sicherheitslücken ausgenutzt werden, haben ein Ausmaß erreicht, das ein Team mit Tabellenkalkulationen und einzelnen Bereitstellungen längst nicht mehr bewältigen kann.

Ein gutes Tooling fasst diese sieben Schritte zu einem schlüssigen, automatisierten Workflow zusammen, bei dem Menschen nur an den Entscheidungspunkten eingreifen. Die Erkennung von Assets läuft kontinuierlich. Die Identifizierung von Patches erfolgt innerhalb weniger Stunden nach der Veröffentlichung durch den Anbieter. Die Priorisierung kann richtliniengesteuert erfolgen, wobei kritische Patches für Notfall-Bereitstellungsringe automatisch genehmigt werden. Die Tests laufen in definierten Bereitstellungsringen ohne manuellen Eingriff ab. Die Bereitstellung berücksichtigt Geräte außerhalb des Netzwerks und führt Neustarts innerhalb vereinbarter Zeitfenster durch. Die Verifizierung fließt in die Schwachstellenscans zurück. Die Berichterstellung erfolgt automatisch.

Dies ist das Betriebsmodell, das dem automatisierten Patch-Management zugrunde liegt, das mittlerweile der Standard für jede Umgebung ist, die es mit der Durchführung von Patches in großem Maßstab ernst meint. Der oben beschriebene siebenstufige Prozess bildet die Grundlage für die Automatisierung; die Automatisierung wiederum sorgt dafür, dass das Ganze nachhaltig funktioniert.

Die Patch-Management-Software von Kaseya übernimmt diesen Arbeitsablauf für IT-Teams und MSPs systemübergreifend und für über tausend Anwendungen von Drittanbietern – mit richtlinienbasierter Bereitstellung, Bereitstellungsringen, der Verwaltung von Geräten außerhalb des Netzwerks und Berichten zur Patch-Compliance in einer einzigen Lösung. Datto RMM, Teil der Kaseya-RMM-Familie, ist die cloudnative Option für Teams, die dieselben Patch-Funktionen nutzen möchten, ohne die zugrunde liegende Infrastruktur verwalten zu müssen.

Der Prozess ist wichtiger als das Tool. Sobald der Prozess jedoch solide ist, entscheidet das richtige Tool darüber, ob ein Programm nur auf dem Papier funktioniert oder ob es die Infrastruktur tatsächlich in dem vom Unternehmen benötigten Rhythmus auf dem neuesten Stand hält. Der nächste Schritt besteht darin, vom Prozess zum Programm überzugehen: In unserem begleitenden Leitfaden zu Best Practices im Patch-Management finden Sie die Grundsätze, die ein funktionierendes Patch-Programm von einem hervorragenden unterscheiden.

Der Prozess des Patch-Managements: Eine Schritt-für-Schritt-Anleitung