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 Hinweis darauf, 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 bewertet sie. 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 das Patchen auf Millionen von Endgeräten für MSPs und interne IT-Teams. Dies vermittelt ein recht klares Bild davon, welche Vorgehensweisen gut geführte Programme gemeinsam haben und welche in den Programmen, die zu kämpfen haben, nie umgesetzt werden.
Wenn Sie zunächst grundlegende Informationen suchen, beginnen Sie mit unserem umfassenden Leitfaden zum Patch-Management. Ansonsten lassen Sie uns gleich mit den praktischen Tipps loslegen.
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 geordnet. 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 betrieblichen Grundvoraussetzungen, die sich im Laufe der Zeit summieren: Sie bewirken diese Woche zwar keine sofortigen Veränderungen, aber ein Programm ohne sie wird nicht lange gesund 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 Laufenden hält.
Maßnahmen mit großer Wirkung
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 diese Maßnahmen gut umsetzen, können Sie bei den meisten der folgenden Punkte nachlässig sein und trotzdem ein solides Programm betreiben. Sie sind 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 hat die CISA 245 Sicherheitslücken in ihren Katalog „Known Exploited Vulnerabilities“(KEV) aufgenommen, 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 die Liste bereits in Ransomware-Kampagnen genutzt, und 20,5 % aller KEV-Einträge wurden in der Vergangenheit von Ransomware-Betreibern ausgenutzt. 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 (zum Beispiel, 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 hoch punkten, werden vorrangig behandelt. Patches, die bei einem Kriterium hoch und bei den anderen niedrig punkten, 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 Prüfer zu begründen.
Verkürzung der Zeit bis zur Bereitstellung 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 mittlere Zeit, die Unternehmen benötigten, um diese Schwachstellen vollständig zu beheben, betrug 209 Tage. Die mittlere Zeit, die Angreifer benötigten, um nach Bekanntwerden der Schwachstelle mit der massenhaften Ausnutzung zu beginnen, betrug fünf Tage.
Genau in dieser Lücke entstehen Sicherheitslücken. Edge-Systeme (VPN-Gateways, Firewalls, Web-Application-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 mit Internet-Schnittstelle 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 Angreifern als Erstes ins Visier nehmen. Dabei geht es nicht darum, bei jedem Patch schneller vorzugehen, sondern darum, bei den Patches, die am wichtigsten sind, schneller vorzugehen.
Routineaufgaben automatisieren
Manuelles Patchen in großem Maßstab funktioniert nicht. Der KEV-Katalog wuchs innerhalb eines Jahres um 20 %, während die Personalstärke der meisten IT-Teams unverändert blieb. Die Zahlen sprechen nicht für den Einsatz von Personal.
Die sinnvolle Aufteilung sieht folgendermaßen aus: Alles, was vorhersehbar ist (Identifizierung, Zeitplanung, Bereitstellung in definierten Ringen, Wiederholungslogik, Berichterstellung), wird automatisiert, während Menschen sich um alles kümmern, was Ermessensentscheidungen erfordert (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. Vielmehr geht es darum, die Automatisierung mit den richtigen Sicherheitsvorkehrungen auszustatten: Bereitstellungsringe, die Probleme in einer Pilotgruppe abfangen, bevor sie die Produktion erreichen, automatische Rollbacks 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 über automatisiertes Patch-Management.
Behandeln Sie Anwendungen von Drittanbietern mit derselben Sorgfalt wie das Betriebssystem
Die meisten Patch-Programme decken Windows, macOS und Linux zuverlässig ab, während andere Systeme eher stiefmütterlich behandelt werden. 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 nutzen sie als Einstiegspunkt.
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. Alles wie bisher. 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 Informationen zu diesem Thema finden Sie in unserem Blog zum Patch-Management für Anwendungen von Drittanbietern.
Übungen 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 verkürzt keine dieser Maßnahmen Ihr Risikozeitfenster so stark wie die besonders wirkungsvollen Maßnahmen. In ihrer Gesamtheit machen sie jedoch den Unterschied zwischen einem Programm, das Prüfungen und Personalwechsel unbeschadet übersteht, und einem Programm, das still und leise an Qualität verliert, sobald jemand das Unternehmen verlässt oder es geschäftlich hektisch wird.
Verwenden Sie Deployment-Ringe, statt alles auf einmal oder nacheinander
Ein Rollout-Ring ist eine festgelegte Abfolge von Systemgruppen, die einen Patch in mehreren Phasen 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 den Patch verursachte Probleme erkannt.
Diese Vorgehensweise verhindert zwei Fehlerquellen, die den Teams bares Geld kosten. Die erste ist der Ansatz „Freitagnachmittag auf alles bereitstellen“, der garantiert, dass ein fehlerhafter Patch die gesamte Organisation auf einen Schlag lahmlegt. Die zweite ist der Ansatz „jeweils nur einen Rechner patchen“, der zwar umsichtig klingt, aber so lange dauert, dass der Patch bereits veraltet ist, bevor er vollständig bereitgestellt ist. Rings bieten Ihnen die Geschwindigkeit der Automatisierung mit der Sicherheit einer schrittweisen Bereitstellung.
Eine sinnvolle Einstiegsstruktur besteht aus drei Phasen: 5–10 % des Netzwerks als Pilotphase, 25–35 % als erweiterte 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 verkürzen sich in Notfällen auf wenige Stunden.
Machen Sie das Rollback zu einem vollwertigen Vorgang und nicht zu einer Notmaßnahme
Rollbacks sind eine Vorgehensweise, über die sich alle einig sind, 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, nachdem ein fehlerhaftes Update 4.000 Endgeräte lahmgelegt hat.
Eine funktionierende Rollback-Funktion erfordert drei Dinge: eine dokumentierte Vorgehensweise für jedes gängige Betriebssystem und jeden Patch-Typ, einen als funktionsfähig bestätigten Wiederherstellungspfad (Image, Snapshot oder die plattformspezifische Deinstallationsfunktion) sowie mindestens eine vierteljährliche Testübung, 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 gebraucht wird.
Die Auswirkungen sind eher moderat als gravierend, da in gut geführten Programmen mit einer soliden Rollout-Strategie 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 Compliance pro Gerät, 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 Fälle 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 Verantwortlicher 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 Richtlinien. Drei Zustände, keine Unklarheiten. Die meisten Teams stellen bei der ersten Durchführung dieser Übung fest, dass der Großteil ihrer „anhaltenden Nichtkonformität“ von einer kleinen, stabilen Gruppe von Geräten stammt: Laptops auf Dienstreisen mit mangelnder Neustartdisziplin, Altsysteme, deren Besitzer Angst haben, sie anzufassen, sowie Entwicklungs- oder Laborsegmente, die außerhalb des Produktions-Patching-Umfangs laufen. Die Liste ist endlich. Sie gezielt abzuarbeiten ist ein anderes Problem als die Verbesserung der allgemeinen Konformität und verdient eine eigene vierteljährliche Aufmerksamkeit.
Für Programme, die mehrere Geschäftsbereiche oder – im Falle von MSP – mehrere Kunden bedienen, gilt dieselbe Vorgehensweise pro Mandant. Compliance-Berichte auf Kundenebene sind zudem das bei Rahmenwerk-Prüfungen am häufigsten angeforderte Prüfungsdokument.
Halten Sie das Programm in einer 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 „tatsächliche, durchgesetzte“ Teil ist 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 Beanstandungen bei Audits führt, wenn die Realität vom Dokument abweicht. Die Konsequenz 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 Auditoren wirklich wichtig sind, finden Sie in unserem Leitfaden zur Erstellung einer Patch-Management-Richtlinie.
Umweltfreundliche Maßnahmen
Diese Punkte tauchen auf jeder Checkliste auf. Es lohnt sich, sie zu erledigen, aber erwarten Sie nicht, dass sie Ihre Zahlen wesentlich verändern:
- Die Pflege eines Anlagenverzeichnisses ist zwar mit viel Arbeit 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 – ein Problem, das das Verzeichnis allein nicht lösen kann.
- Die Information der Endnutzer über Wartungsfenster ist im Hinblick auf die Beziehung zum Unternehmen sinnvoll, ändert jedoch nichts an Ihrer Sicherheitslage.
- Die Vereinheitlichung auf unterstützte Softwareversionen bietet einen echten Mehrwert, der sich jedoch erst langfristig auszahlt: Die Reduzierung der Anzahl unterschiedlicher Betriebssystem- und Anwendungsversionen im Bestand erleichtert alle weiteren Aufgaben, doch das Projekt, um dieses Ziel zu erreichen, dauert in der Regel ein Jahr oder länger.
- Endnutzer darauf zu schulen, Update-Aufforderungen nicht zu ignorieren, zahlt sich zwar aus, doch bei den meisten ausgenutzten Sicherheitslücken muss der Nutzer gar nichts tun. Das Nutzerverhalten spielt beim Phishing eine größere Rolle als beim Installieren 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 zu befolgen, wenn man die Maßnahmen aus den ersten beiden Abschnitten außer Acht lässt.
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:
- Zeit bis zur Behebung kritischer Sicherheitslücken, gemessen vom Veröffentlichungsdatum des Herstellers bis zur unternehmensweiten Bereitstellung.
- Prozentualer Anteil der Geräte, die die SLA für Patches erfüllen, aufgeschlüsselt nach Patch-Stufen (kritisch, hoch, mittel).
- Durchschnittsalter der noch in der Umgebung vorhandenen, nicht behobenen Sicherheitslücken.
- Anzahl der Geräte, für die ein Ausnahmezustand dokumentiert ist, mit aktuellem Überprüfungsdatum.
- Anzahl der durch Patches verursachten Vorfälle pro Zyklus als Rückmeldesignal für Tests und die Bereitstellung im Ring.
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 langfristig umsetzen kann, ohne dabei an seine Grenzen zu stoßen.
Die folgenden Funktionen sollten Sie beachten: ein einheitlicher Bestandsüberblick ü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, automatische Wiederholungsversuche und die Eskalation von Ausnahmen sowie gerätebezogene Compliance-Berichte, die auf Abruf 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 Modul „Advanced Software Management“ von Datto RMM deckt über 200 sofort einsatzbereite Anwendungen von Drittanbietern ab und bietet Richtlinien für Bereitstellungsringe, die Verwaltung von Geräten außerhalb des Netzwerks sowie Compliance-Berichte pro Mandant – allesamt Funktionen, 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.
