Bewährte Verfahren für das Patch-Management: So lassen sich Risiken schneller minimieren

Die meisten Listen mit Best Practices für das Patch-Management ähneln sich. Erfassen Sie Ihre IT-Ressourcen. Testen Sie vor der Bereitstellung. Dokumentieren Sie eine Richtlinie. Automatisieren Sie, wo immer es möglich ist. Das alles ist zwar richtig, aber zu allgemein gehalten. Sie geben keinen Aufschluss darüber, welche Maßnahmen Ihre Sicherheitslage tatsächlich verbessern und welche eher „nice-to-haves“ sind, die Sie zurückstellen können, wenn Ihr Team bereits völlig überlastet ist.

Dieser Leitfaden erstellt eine Rangliste dieser Lösungen. Nicht alphabetisch, nicht nach der NIST-Taxonomie, sondern danach, was bei den entscheidenden Kennzahlen den Ausschlag gibt: Zeit bis zur Behebung kritischer Schwachstellen, Prozentsatz der abgedeckten Infrastruktur, Nachweisfähigkeit bei Audits und Wahrscheinlichkeit von Sicherheitsverletzungen. Einige der unten aufgeführten Vorgehensweisen halbieren Ihr Sicherheitsrisiko. Andere sparen Ihrem Team ein paar Stunden pro Monat. Die RMM-Lösungen von Kaseya übernehmen die Patch-Verteilung auf Millionen von Endgeräten für MSPs und interne IT-Teams. Dadurch ergibt sich ein recht klares Bild davon, welche Vorgehensweisen gut geführte Programme gemeinsam haben und welche in den Programmen, die Probleme haben, nie umgesetzt werden.

Wenn Sie zunächst grundlegende Informationen suchen, beginnen Sie mit unserem umfassenden Leitfaden zum Patch-Management. Andernfalls lassen Sie uns gleich mit den praktischen Vorgehensweisen beginnen.

Bewährte Verfahren für das Patch-Management – von den wirkungsvollsten bis zu den am wenigsten wirkungsvollen

Die folgenden Maßnahmen sind nach ihrer Wirkung und nicht nach ihrer Reihenfolge gruppiert. Innerhalb jeder Gruppe sind sie grob danach geordnet, wie viel Aufwand sie im Verhältnis zum Sicherheitsgewinn erfordern.

Die Maßnahmen mit hoher Wirkung verändern Ihr Risikoprofil auf messbare Weise. Wenn Sie in diesem Quartal nur Zeit für drei Dinge haben, wählen Sie aus dieser Gruppe aus. Die Maßnahmen mit mittlerer Wirkung sind die „betriebliche Hygiene“, deren Effekt sich im Laufe der Zeit summiert: Sie bewirken diese Woche zwar keine sofortige Veränderung, aber ein Programm ohne sie wird nicht lange stabil bleiben. Und die Maßnahmen mit geringer Wirkung sind die Punkte, die in jeder Audit-Checkliste aufgeführt sind. Es lohnt sich, sie durchzuführen, aber verwechseln Sie sie nicht mit der Arbeit, die Sie tatsächlich auf dem neuesten Stand hält.

Besonders wirkungsvolle Methoden

Dies sind die vier Maßnahmen, die Ihre Kennzahlen messbar verbessern. Wenn Sie diese auslassen, wird Ihnen auch der Rest der Liste nichts nützen. Wenn Sie sie jedoch gut umsetzen, können Sie bei den meisten der folgenden Punkte nachlässig vorgehen und dennoch ein solides Programm betreiben. Sie sind zwar anspruchsvoller als die Maßnahmen mit mittlerer Wirkung, aber der Gewinn an Sicherheit pro investierter Stunde ist um ein Vielfaches höher.

Priorisieren Sie nach Ausnutzbarkeit, nicht nur nach Schweregrad

CVSS-Werte sind ein nützlicher Ausgangspunkt, aber ein schlechter Endpunkt. Ein CVSS-Wert von 9,8 in einer Software, die nicht öffentlich zugänglich ist, ist weniger dringlich als ein CVSS-Wert von 7,5, der bereits im CISA-KEV-Katalog aufgeführt ist und diese Woche von Ransomware-Gruppen ausgenutzt wird.

Im Jahr 2025 nahm die CISA 245 Schwachstellen in ihren Katalog „Known Exploited Vulnerabilities“(KEV) auf, wodurch die Liste nun 1.484 Einträge umfasst. Das entspricht einem Anstieg von 20 % innerhalb eines einzigen Jahres. Vierundzwanzig der im Jahr 2025 hinzugefügten Schwachstellen wurden zum Zeitpunkt der Aufnahme in den Katalog bereits in Ransomware-Kampagnen ausgenutzt, und 20,5 % aller KEV-Einträge wurden in der Vergangenheit von Ransomware-Betreibern genutzt. Hier liegt das tatsächliche Angriffsvolumen, und es macht nur einen Bruchteil des gesamten CVE-Universums aus.

Ein risikobasiertes Priorisierungsmodell stützt sich auf drei Faktoren: Schweregrad des Anbieters (CVSS), Ausnutzungsstatus (KEV-Listung, Threat-Intelligence-Feeds, Verfügbarkeit öffentlicher Exploits) und geschäftliche Auswirkungen (beispielsweise, ob ein System mit dem Internet verbunden ist, sensible Daten verarbeitet oder als Dreh- und Angelpunkt für kritische Systeme dient). Patches, die bei allen drei Kriterien hohe Werte erzielen, werden vorrangig behandelt. Patches, die bei einem Kriterium hoch und bei den anderen niedrig abschneiden, werden im regulären Rhythmus bearbeitet. Dies ist keine komplizierte Änderung. Es handelt sich hauptsächlich um eine Änderung der Vorgehensweise bei der Triage Ihres wöchentlichen Schwachstellenberichts.

Was es kostet: ein paar Stunden Arbeitszeit eines Analysten pro Woche. Was es einbringt: den Großteil Ihres unnötigen Aufwands sowie die Möglichkeit, Priorisierungsentscheidungen gegenüber einem Wirtschaftsprüfer zu begründen.

Verkürzung der Zeit bis zur Installation von Patches auf Systemen mit Internetanbindung

Der „Verizon Data Breach Investigations Report 2025“ erfasste 17 Schwachstellen, die Edge-Geräte auf der KEV-Liste betrafen. Die Medianzeit, die Unternehmen benötigten, um diese Schwachstellen vollständig zu beheben, betrug 209 Tage. Die Medianzeit, die Angreifer benötigten, um nach Bekanntwerden der Schwachstellen mit der massenhaften Ausnutzung zu beginnen, betrug fünf Tage.

Genau in dieser Lücke treten Sicherheitslücken auf. Edge-Systeme (VPN-Gateways, Firewalls, Webanwendungs-Firewalls, Identitätsanbieter und alle anderen aus dem Internet erreichbaren Systeme) sollten einem separaten, deutlich schnelleren SLA für Patches unterliegen als der Rest Ihrer Infrastruktur. Ein Zeitfenster von 14 Tagen für routinemäßige Patches für internetexponierte Systeme und ein Zeitfenster von 24 bis 48 Stunden für aktiv ausgenutzte Schwachstellen ist ein vertretbares Ziel. Alles, was darüber hinausgeht, bedeutet, dass Sie wissentlich mit offener Tür arbeiten.

Diese Vorgehensweise ist besonders wirkungsvoll, da sie die Anstrengungen auf die Systeme konzentriert, die Angreifer als Erstes ins Visier nehmen. Dabei ist nicht bei jedem Patch ein schnellerer Rhythmus erforderlich, sondern nur bei den Patches, die am wichtigsten sind.

Routineaufgaben automatisieren

Manuelles Patchen in großem Maßstab funktioniert nicht. Der KEV-Katalog wuchs innerhalb eines einzigen Jahres um 20 %, während die Personalstärke der meisten IT-Teams unverändert blieb. Die Zahlen sprechen nicht für den Einsatz von Menschen.

Die realistische Aufteilung sieht folgendermaßen aus: Alles, was vorhersehbar ist (Identifizierung, Zeitplanung, Bereitstellung in definierten Ringen, Wiederholungslogik, Berichterstellung), wird automatisiert, während Menschen weiterhin für alle Aufgaben zuständig sind, die eine Beurteilung erfordern (Ausnahmebehandlung, Genehmigungen von Änderungsfenstern für sensible Systeme, Entscheidungen über Rollbacks, Kommunikation mit den Beteiligten). Wenn dies gut umgesetzt wird, reduziert sich der Aufwand, der früher eine Vollzeitstelle für die Patch-Verwaltung erforderte, auf wenige Stunden Überwachung pro Woche.

Der häufigste Einwand ist die Befürchtung, dass fehlerhafte Patches die Produktion lahmlegen könnten. Die Lösung dafür besteht nicht darin, alles manuell zu erledigen, sondern darin, die Automatisierung mit den richtigen Sicherheitsvorkehrungen auszustatten: Bereitstellungsringe, die Probleme in einer Pilotgruppe abfangen, bevor sie die Produktion erreichen, automatisches Rollback bei von Agenten gemeldeten Fehlern und ein definierter Ausnahmepfad für die 5 % der Systeme, die tatsächlich manuelle Eingriffe erfordern. Weitere Informationen zum Betriebsmodell und dazu, was automatisiert und was manuell bleiben sollte, finden Sie im Artikel zum automatisierten Patch-Management.

Behandeln Sie Anwendungen von Drittanbietern mit derselben Sorgfalt wie das Betriebssystem

Die meisten Patch-Programme decken Windows, macOS und Linux kompetent ab und behandeln die übrigen Systeme eher als Nebensache. Genau hier liegt die Lücke. Sicherheitslücken in Browsern, PDF-Readern, Konferenztools, Laufzeitumgebungen und Entwicklertools werden massiv ausgenutzt, und viele der am häufigsten genutzten Angriffsketten stützen sich auf sie als Einstiegsvektor.

Es hat sich bewährt, Anwendungen von Drittanbietern in denselben Bestand, dasselbe Priorisierungsschema und dieselben SLAs wie Ihre Betriebssystem-Patches einzubinden. Kein separates Projekt, kein separates Tool, keine separate vierteljährliche Überprüfung. Einfach dasselbe. Wenn Ihre Patch-Management-Plattform mehrere hundert Anwendungen von Drittanbietern nativ unterstützt (was bei den meisten modernen Plattformen der Fall ist), handelt es sich eher um eine Konfigurationsänderung als um ein neues Programm. Ist dies nicht der Fall, muss diese Lücke zuerst geschlossen werden. Welche Anwendungen besonders priorisiert werden sollten und weitere Details zu diesem Thema finden Sie in unserem Blogbeitrag zum Patch-Management für Drittanbieter-Anwendungen.

Trainings mit mittlerer Belastung

Die folgenden vier Maßnahmen sind entscheidend dafür, dass ein gut funktionierendes Programm auch weiterhin gut funktioniert. Für sich genommen wird keine dieser Maßnahmen Ihr Risiko so stark verringern wie die besonders wirkungsvollen Maßnahmen. Zusammen sind sie jedoch der entscheidende Faktor, der ein Programm, das Prüfungen und Personalwechsel standhält, von einem Programm unterscheidet, das still und leise an Qualität verliert, sobald jemand das Unternehmen verlässt oder es geschäftlich hektisch wird.

Verwenden Sie Bereitstellungsringe, statt alles auf einmal oder nacheinander

Ein Rollout-Ring ist eine festgelegte Abfolge von Systemgruppen, die ein Patch schrittweise erhalten: Zunächst eine kleine Pilotgruppe, die repräsentativ für die gesamte Infrastruktur ist, dann eine größere Validierungsgruppe und schließlich die vollständige Einführung in der Produktionsumgebung. Jeder Ring hat eine Wartezeit, bevor der nächste beginnt; während dieser Zeit werden durch die Überwachung etwaige durch das Patch verursachte Probleme erkannt.

Dieses Verfahren schließt zwei Fehlerquellen aus, die den Teams echte Kosten verursachen. Die erste ist der Ansatz „Freitagnachmittag auf alle Systeme bereitstellen“, der garantiert, dass ein fehlerhafter Patch die gesamte Organisation auf einen Schlag lahmlegt. Die zweite ist der Ansatz „jeweils einen Rechner nach dem anderen patchen“, der zwar umsichtig klingt, aber so lange dauert, dass der Patch bereits veraltet ist, bevor er vollständig bereitgestellt ist. Mit Rings profitieren Sie von der Geschwindigkeit der Automatisierung und der Sicherheit einer schrittweisen Bereitstellung.

Eine sinnvolle Einstiegsstruktur besteht aus drei Phasen: 5–10 % des Bestands als Pilotphase, 25–35 % als umfassendere Validierung und der Rest als endgültige Einführung. Die Wartezeiten von 24–48 Stunden zwischen den Phasen eignen sich für routinemäßige Patches und lassen sich in Notfällen auf wenige Stunden verkürzen.

Machen Sie das Rollback zu einem vollwertigen Vorgang und nicht zu einer Notfallmaßnahme

Rollback ist eine Vorgehensweise, der zwar alle zustimmen, die aber die meisten Teams noch nicht wirklich getestet haben. Der richtige Zeitpunkt, um festzustellen, dass das Rollback-Verfahren nicht funktioniert, ist nicht erst am Morgen nach einem fehlerhaften Patch, der 4.000 Endgeräte lahmgelegt hat.

Eine funktionsfähige Rollback-Funktion erfordert drei Dinge: ein dokumentiertes Verfahren für jedes wichtige Betriebssystem und jeden Patch-Typ, einen als funktionsfähig bestätigten Wiederherstellungspfad (Image, Snapshot oder die plattformspezifische Deinstallationsfunktion) sowie mindestens eine Testübung pro Quartal, bei der das Team das Rollback an einer Testgruppe durchführt. Die Testübung ist der Teil, den die meisten Programme auslassen. Ohne sie verliert die Dokumentation an Qualität, und niemand bemerkt dies, bis sie tatsächlich benötigt wird.

Die Auswirkungen sind eher moderat als hoch, da in gut geführten Programmen mit einer guten Ringbereitstellung Rollbacks selten vorkommen. Doch die Asymmetrie spielt eine Rolle: Seltene Vorfälle, deren Behebung Tage dauert, verursachen höhere Kosten als häufige Vorfälle, die innerhalb von Minuten behoben werden können.

Erfassen und dokumentieren Sie die Einhaltung der Vorschriften geräteweise und nicht nur in zusammengefasster Form

Eine Konformitätsrate von 95 % ist zwar beruhigend, aber weitgehend bedeutungslos. Die interessante Frage ist, welche 5 % nicht konform sind, warum und wie lange. Wenn es sich bei diesen 5 % in jedem Zyklus um dieselben handelt, ist das ein anderes Problem als bei zufällig verteilten 5 %, und auch die richtige Vorgehensweise ist eine andere.

Es ist üblich, auf Geräteebene zu berichten, wobei für jedes nicht konforme Gerät ein namentlich genannter Eigentümer und ein definierter Ausnahmezustand angegeben werden. Ein Gerät ist entweder konform, befindet sich in einer dokumentierten Ausnahme mit einem Überprüfungsdatum oder verstößt gegen die Richtlinie. Drei Zustände, keine Unklarheiten. Die meisten Teams stellen bei der ersten Durchführung dieser Maßnahme fest, dass der Großteil ihrer „anhaltenden Nichtkonformität“ von einer kleinen, stabilen Gruppe von Geräten herrührt: Laptops auf Dienstreisen, bei denen die Neustart-Routine nicht eingehalten wird, Altsysteme, deren Besitzer sich nicht trauen, sie anzufassen, sowie Entwicklungs- oder Laborsegmente, die außerhalb des Patching-Umfangs der Produktion betrieben werden. Die Liste ist überschaubar. Diese gezielt abzuarbeiten ist ein anderes Problem als die Verbesserung der allgemeinen Konformität und verdient eine eigene vierteljährliche Aufmerksamkeit.

Bei Programmen, die mehrere Geschäftsbereiche oder – im Falle von MSP – mehrere Kunden betreffen, gilt dieselbe Vorgehensweise pro Mandant. Compliance-Berichte auf Kundenebene sind zudem die am häufigsten angeforderten Prüfungsunterlagen bei Rahmenwerk-Überprüfungen.

Halten Sie das Programm in einer konkreten, verbindlichen Richtlinie fest

Jedes Audit-Rahmenwerk und die meisten Anträge auf Cyber-Versicherungen verlangen mittlerweile eine Richtlinie zum Patch-Management. Die schlechte Variante ist ein dreiseitiges Dokument, in dem es heißt: „Patches werden zeitnah installiert“, und das in einem SharePoint-Ordner schlummert, den niemand öffnet. Die nützliche Variante legt SLAs je nach Schweregrad der Patches fest, definiert Rollen und Genehmigungswege, nennt die Wartungsfenster, legt das Verfahren für Ausnahmen fest und wird vierteljährlich überprüft.

Der Teil „real, durchgesetzt“ bezieht sich auf die Praxis. Eine Richtlinie, die nicht mit dem übereinstimmt, was das Team tatsächlich tut, ist schlimmer als gar keine Richtlinie, da sie jedes Mal zu Prüfungsfeststellungen führt, wenn die Realität vom Dokument abweicht. Die Disziplin besteht darin, entweder die Richtlinie anzupassen, wenn sich die Praxis ändert, oder die Praxis so anzupassen, dass sie der Richtlinie entspricht. Informationen zur Struktur einer praktikablen Richtlinie und zu den Abschnitten, die für Prüfer wirklich wichtig sind, finden Sie in unserem Leitfaden zur Erstellung einer Richtlinie für das Patch-Management.

Umweltfreundliche Maßnahmen

Diese Punkte tauchen auf jeder Checkliste auf. Es lohnt sich, sie umzusetzen, aber erwarten Sie nicht, dass sie Ihre Zahlen wesentlich verändern werden:

• Die Pflege eines Anlagenverzeichnisses ist zwar mit Aufwand verbunden, doch die meisten Teams verfügen bereits über ein solches. Das größere Problem im Zusammenhang mit dem Verzeichnis sind Schatten-IT und nicht verwaltete Endgeräte – Probleme, die sich durch das Verzeichnis allein nicht beheben lassen.
• Die Information der Endnutzer über Wartungsfenster ist im Hinblick auf die Beziehung zum Unternehmen sinnvoll, hat jedoch keinen Einfluss auf Ihre Sicherheitslage.
• Die Standardisierung auf unterstützte Softwareversionen bietet einen echten Mehrwert, der sich jedoch erst langsam auszahlt: Die Reduzierung der Anzahl unterschiedlicher Betriebssystem- und Anwendungsversionen in der IT-Landschaft erleichtert alle weiteren Aufgaben, doch das Projekt, um dieses Ziel zu erreichen, dauert in der Regel ein Jahr oder länger.
• Endnutzer darin zu schulen, Update-Aufforderungen nicht zu ignorieren, zahlt sich zwar in gewisser Weise aus, doch bei den meisten ausgenutzten Sicherheitslücken muss der Nutzer gar nichts tun. Das Nutzerverhalten spielt beim Phishing eine größere Rolle als bei der Installation von Patches.

Der Grund, warum diese Punkte auf jeder Liste stehen, ist, dass sie sich leicht aufschreiben lassen und schwer zu widerlegen sind. Der Grund, warum sie in dieser Liste ganz unten stehen, ist, dass es nicht ausreicht, sie perfekt umzusetzen, wenn man die Maßnahmen aus den ersten beiden Abschnitten außer Acht lässt – das reicht nicht aus, um sicher zu sein.

Kennzahlen zum Patch-Management: So messen Sie den Erfolg von Best Practices

Eine Praxis, die man nicht messen kann, ist keine Praxis. Es ist ein Ziel. Die Kennzahlen, die es wert sind, wöchentlich oder monatlich verfolgt zu werden, sind folgende:

1. Zeit bis zur Behebung kritischer Sicherheitslücken, gemessen vom Veröffentlichungsdatum des Herstellers bis zur unternehmensweiten Bereitstellung.
2. Prozentualer Anteil der Systeme, die die SLA für Patches einhalten, aufgeschlüsselt nach Patch-Stufen (kritisch, hoch, mittel).
3. Durchschnittsalter der noch in der Umgebung vorhandenen, nicht behobenen Sicherheitslücken.
4. Anzahl der Geräte, die sich in einem dokumentierten Ausnahmezustand befinden, mit aktuellem Überprüfungsdatum.
5. Anzahl der durch Patches verursachten Vorfälle pro Zyklus als Rückmeldesignal für Tests und die Ringbereitstellung.

Fünf Kennzahlen. Wenn sie sich in die richtige Richtung entwickeln, funktioniert das Programm. Wenn sie trotz aller Bemühungen stagnieren oder sich verschlechtern, wird eine der oben genannten Maßnahmen nicht so umgesetzt, wie beschrieben.

Wo Kaseya den Unterschied macht

Die oben genannten Vorgehensweisen beschreiben, wie ein gut funktionierendes Patch-Management-Programm aussieht. Die Wahl der richtigen Tools entscheidet darüber, ob Ihr Team diese Vorgehensweisen nachhaltig umsetzen kann, ohne dabei an seine Grenzen zu stoßen.

Die folgenden Funktionen sollten Sie beachten: eine einheitliche Bestandsübersicht über alle Betriebssysteme und Anwendungen von Drittanbietern hinweg, eine richtliniengesteuerte Priorisierung unter Einbeziehung von KEV-Daten, eine ringbasierte Bereitstellung mit automatischen Sperrfristen, die Verwaltung von Geräten außerhalb des Netzwerks, automatisierte Wiederholungsversuche und die Eskalation von Ausnahmen sowie Compliance-Berichte pro Gerät, die bei Bedarf auditfähige Nachweise liefern.

Die RMM-Lösungen von Kaseya bieten Patch-Management-Software für MSPs und interne IT-Teams für verschiedene Betriebssysteme. Das „Advanced Software Management“-Modul von Datto RMM deckt mehr als 200 sofort einsatzbereite Anwendungen von Drittanbietern ab und umfasst Richtlinien für Bereitstellungsringe, die Verwaltung von Geräten außerhalb des Netzwerks sowie Compliance-Berichte pro Mandant, die für die oben genannten Vorgehensweisen erforderlich sind. Datto RMM, Teil der Kaseya-RMM-Familie, ist die cloudnative Option für Teams, die dieselben Funktionen nutzen möchten, ohne die zugrunde liegende Infrastruktur verwalten zu müssen.

Die Maßnahmen, die wirklich etwas bewirken, sind die im obigen Abschnitt „Maßnahmen mit hoher Wirkung“ aufgeführten. Wählen Sie in diesem Quartal eine davon aus, setzen Sie sie konsequent um und messen Sie die erzielten Veränderungen.