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 Bestandsverzeichnis 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 Prozess für das Patch-Management macht aus diesen unsicheren Übergaben einen wiederholbaren Vorgang. Er gibt Ihnen eine Abfolge vor, 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 jeder Phase geschieht, wer in der Regel dafür verantwortlich ist, wo der Prozess am häufigsten ins Stocken gerät und wie lange jeder Schritt in einer reibungslosen 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 ein „optimaler“ Ablauf in jeder Phase 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 dann 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, der eine Sicherheitslücke oder eine Hersteller-Veröffentlichung in einen gepatchten, geprüften und dokumentierten Endpunkt umwandelt.
In der Praxis wird dieser Prozess auf verschiedene Weise bezeichnet: Lebenszyklus des Patch-Managements, Workflow des Patch-Managements, Verfahren des Patch-Managements oder einfach nur der Patch-Prozess. Alle Begriffe beschreiben dasselbe. Die Anzahl der Schritte variiert zwischen vier und zehn, je nachdem, wer darüber schreibt, doch die zugrunde liegende Logik ändert sich 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 diese miteinander zu verschmelzen. Bei mehr Schritten erfindet man Unterscheidungen, die in der Praxis nicht existieren.
Bevor wir uns näher mit dem Thema befassen, sei eines vorweggenommen: Der Prozess für routinemäßige, planmäßige Patches unterscheidet sich von dem für Notfall- oder Zero-Day-Patches. Auf dem Papier mögen die Schritte ähnlich aussehen, doch die Zeitvorgaben, Genehmigungsstufen und die Risikotoleranz sind deutlich knapper bemessen. 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 Prozess für das Patch-Management beschreibt eine standardisierte Vorgehensweise, 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.
Man kann nichts reparieren, von dem man nichts weiß. Der erste Schritt besteht darin, ein vollständiges, genaues und aktuelles Verzeichnis 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 Tabelle, die jemand vierteljährlich aktualisiert. Es ist ein ständig aktualisierter Bestand, der auf automatisierter Erfassung basiert und in dem jede Ressource mit Informationen zu Software-Stücklisten, Betriebssystemversion, Zeitpunkt der letzten Überprüfung und Eigentumsverhältnissen 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 bemerkt hat, dass er eine veraltete Version von OpenSSL laufen hatte.
Häufige Fehlerquellen: BYOD-Geräte, auf denen der Agent nicht läuft, Laptops von Auftragnehmern, die sich nur einmal im Quartal mit dem VPN verbinden, der Laborserver, den jemand eingerichtet und vergessen hat zu registrieren, sowie alle Ressourcen, die sich in einem Cloud-Abonnement befinden, das einem einzelnen Team gehört.
Zeitaufwand: Die Erfassung selbst läuft kontinuierlich. Das erstmalige Erreichen einer zuverlässigen, vollständigen 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 von Quellen für Bedrohungsinformationen, um Schwachstellen zu erkennen, 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 und oft ohne großes Aufsehen veröffentlicht. Dies ist eines der stärksten Argumente für ein Patch-Management-Tool, das die Erkennung von Drittanbieter-Software 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 außerplanmäßigen Sicherheitshinweisen, die zwischen den „Patch Tuesdays“ eintreffen, 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 haben mehr Patches zur Verfügung, 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-Score 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-Score 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-Score 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 die Schwere, sondern auch die Kritikalität der Ressourcen, die Gefährdung, die Verfügbarkeit von Exploits und die Auswirkungen auf das Geschäft.
Hier kommen der CISA-Katalog bekannter ausgenutzter Sicherheitslücken und die Threat-Intelligence-Feeds voll zur Geltung. Sie geben Aufschluss darüber, welche Sicherheitslücken Angreifer ausnutzen – ein weitaus besserer Indikator dafür, welche Patches zuerst installiert werden sollten, als der CVSS-Wert allein.
Das Ergebnis dieses Schritts ist eine nach Priorität geordnete Liste mit groben Zeitvorgaben. Ein gängiges Schema 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 an Compliance-Reife anstreben. Unabhängig davon, welche Zeitpläne Sie festlegen, dokumentieren Sie diese in Ihrer Patch-Management-Richtlinie, damit sie im weiteren Verlauf des Prozesses berücksichtigt werden.
Häufige Fehlerquellen: Sich ausschließlich auf CVSS zu verlassen, Daten zur Ausnutzbarkeit zu ignorieren, jeden „kritischen“ Patch als gleich kritisch einzustufen, das umgekehrte Problem, Zeitpläne als Fristen statt als Zielvorgaben zu betrachten, und mit der Bereitstellung bis zum 13. Tag zu warten.
Zeitaufwand: Stunden pro Patch-Zyklus, wenn Ihre Tools die Hauptarbeit übernehmen. Einen ganzen 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 setzen auf 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 die Patches 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 Risikobereitschaft.
Schritt 5: Bereitstellung
Verantwortlicher: IT-Betrieb
Bei der Bereitstellung geht es ans Eingemachte. 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 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, deren Reihenfolge aufgrund von Abhängigkeiten sorgfältig geplant werden muss. Patches, für die zuvor ein bestimmter Dienst beendet werden muss. Geräte außerhalb des Netzwerks, die sich seit Wochen nicht gemeldet haben.
Ein gut konfiguriertes RMM-Tool erledigt den Großteil dieser Arbeit im Hintergrund. Es installiert 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, bei denen der Patch beim ersten Mal nicht installiert wurde.
Wartungsfenster sind wichtiger, als man gemeinhin annimmt. Ein Patch, der mitten in einer Krankenhausschicht einen Neustart eines klinischen Arbeitsplatzrechners erfordert, wird aufgeschoben – was bedeutet, dass der Patch tatsächlich nicht installiert wird, auch wenn Ihr Dashboard etwas anderes anzeigt. Die Abstimmung der Wartungsfenster auf die tatsächlichen Betriebsabläufe ist der entscheidende Faktor, der Patch-Programme, die gute Ergebnisse liefern, von solchen unterscheidet, die Risiken tatsächlich mindern.
Häufige Fehlerquellen: Die Annahme, dass „bereitgestellt“ bedeutet, der Patch sei installiert, 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 einige Minuten bis einige 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
Verantwortlich: IT-Betrieb, mit Überprüfung durch die Sicherheitsabteilung.
Die Überprüfung ist der Schritt, von dem die meisten Teams wissen, dass sie ihn besser handhaben 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 zu beachten. Erstens: Wurde der Patch erfolgreich installiert? Die meisten Patch-Management-Tools geben darüber Auskunft, doch hinter dieser Antwort verbirgt sich oft eine ganze Reihe von Statusmeldungen wie „Neustart ausstehend“ oder „zurückgestellt“, die zwar auf den ersten Blick in Ordnung erscheinen, dies 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 weiterhin besteht, weil ein anderer Patch erforderlich gewesen wäre.
Die Diskrepanz zwischen der von Ihrem Patch-Tool gemeldeten „Erfolgsquote bei der Bereitstellung“ und der von Ihrem Scanner gemeldeten „Schwachstellenbehebungsquote“ ist oft der Grund für Beanstandungen bei Audits. Ein Team, das eine Patch-Compliance von 98 %, aber eine Schwachstellenbehebungsquote von nur 85 % ausweist, hat ein Prozessproblem, 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 Langzeitfolgen 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
Zuständig: IT-Betrieb, oft 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 gegenüber den Prüfern die erforderliche Sorgfalt belegen, der Unternehmensleitung Trends aufzeigen und in die Verbesserung des nächsten Zyklus einfließen.
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 Patch-Implementierungsdauer 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 die Patch-Historie jedes einzelnen Endpunkts zu überprüfen.
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 schneller bereitstellen?“, 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, fehlende Überprüfungszyklen, fehlende Verknüpfung zwischen Kennzahlen und Prozessverbesserungen.
Zeitaufwand: Monatliches Besprechungstreffen sowie die fortlaufende Erfassung von 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-Sicherheitslücke oder eine aktiv ausgenutzte Schwachstelle 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 Funktionstest in einem kleinen Netzwerk, und die Bereitstellung erfolgt flächendeckend in der Erwartung, dass einige Ausfälle einer anhaltenden Sicherheitslücke vorzuziehen sind. Die Überprüfung und Dokumentation werden straffer gehandhabt, da ein Audit ansteht.
Das Risiko bei Notfallmaßnahmen besteht in der Regel nicht darin, zu schnell zu handeln. Es besteht vielmehr 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, macht schnelles Patchen sicher.
Wo sich der Patching-Prozess je nach Umgebung unterscheidet
Server, Endgeräte, Anwendungen von Drittanbietern und Cloud-Workloads nutzen alle dasselbe siebenstufige Grundgerüst, weisen jedoch in wesentlichen Details Unterschiede auf.
Bei Servern spielt der Abhängigkeitsgraph eine größere Rolle. Wird ein Datenbankserver in einer falschen Reihenfolge im Verhältnis zu den davon abhängigen Anwendungsservern gepatcht, kann dies zu stundenlangen Ausfällen führen. Die Wartungsfenster sind enger, die Änderungskontrolle ist 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 richtig so.
Bei Endgeräten ist der „Long Tail“ das Problem. Laptops, die unterwegs sind, Geräte, bei denen der Neustart hinausgezögert wird, und Benutzer, die das Gerät lieber 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 liegt das Problem in der schieren Menge. In einer typischen Umgebung gibt es Dutzende von Drittanbieter-Apps, von denen jede ihren eigenen Release-Zeitplan hat, und ein erheblicher Anteil der Sicherheitsverletzungen geht auf eine nicht gepatchte Drittanbieter-App zurück und nicht auf ein nicht gepatchtes Betriebssystem. Dies ist so bedeutend, dass wir diesen Aspekt gesondert behandelt haben. Die operativen Details finden Sie in unserem speziellen Leitfaden zum Patch-Management für Drittanbieter-Apps.
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 laufen beide Muster nebeneinander, 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 dort ist, wo 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, werden nicht gepatcht, und oft sind es gerade diese Hosts, die Angreifer als Erstes finden, da sie aus demselben Grund, aus dem sie nicht in der Bestandsaufnahme aufgeführt 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 gibt 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 herantraut, die Laborumgebung mit ihren eigenen Regeln. Ein ausgereiftes Programm macht diesen „Long Tail“ sichtbar, benennt Verantwortliche für jede Ausnahme und arbeitet sich diese 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 Fehlerquellen 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 Ausmaß der Releases, die Vielfalt der Plattformen und die Geschwindigkeit, mit der Sicherheitslücken ausgenutzt werden, haben ein Maß 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 Erfassung der Assets läuft kontinuierlich. Die Identifizierung von Patches erfolgt innerhalb weniger Stunden nach der Veröffentlichung durch den Hersteller. 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 auch Geräte außerhalb des Netzwerks und führt Neustarts innerhalb vereinbarter Zeitfenster durch. Die Verifizierung fließt in die Schwachstellenscans ein. Die Berichterstellung erfolgt automatisch.
Dies ist das Betriebsmodell, das dem automatisierten Patch-Management zugrunde liegt, das mittlerweile in jeder Umgebung, die es mit der groß angelegten Patch-Verwaltung ernst meint, zum Standard geworden ist. Der oben beschriebene siebenstufige Prozess bildet die Grundlage der 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 Werkzeug. Sobald der Prozess jedoch solide ist, entscheidet das richtige Werkzeug 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.
