Das Patch-Management ist eine der Dienstleistungen mit dem größten Hebeleffekt, die ein MSP anbietet. Es läuft täglich im Hintergrund, erfüllt eine Klausel in fast jedem Antrag auf eine Cyberversicherung, bildet den Kern der Compliance-Bescheinigungen für Kunden in regulierten Branchen und sorgt, wenn es gut vermarktet wird, still und leise für wiederkehrende Einnahmen. Dabei wird es von Jahr zu Jahr schwieriger, nicht einfacher.
Der Grund dafür ist struktureller Natur. Ein internes IT-Team führt Patches in einer Umgebung durch – mit einem einzigen Satz von Stacks, einem einzigen Satz von Wartungsfenstern und einem einzigen Genehmigungsworkflow. Ein MSP wendet dasselbe Playbook fünfzig oder hundert Mal parallel an, und zwar auf fünfzig oder hundert verschiedene Umgebungen, die keine einzige gemeinsame Regel teilen. Das ist keine einfach vergrößerte Version der internen IT-Patch-Verwaltung. Es ist ein anderes Betriebsmodell.
Die Patch-Management-Software von Datto RMM ist speziell auf dieses Betriebsmodell zugeschnitten und wird von Tausenden von MSPs eingesetzt, um Patches auf Millionen von Kundenendgeräten zu installieren. Sie bietet einen klaren Überblick darüber, wo die Patch-Programme der MSPs unter hoher Auslastung bestehen und wo sie versagen.
Dieser Artikel befasst sich damit, warum das Patchen ein MSP-Dienstleistungsbereich ist, den man ernst nehmen sollte, was das multitenante Patchen wirklich auszeichnet, welches Betriebsmodell hinter einem funktionierenden Programm steht und wie etablierte MSPs diese Dienstleistungen bündeln und bepreisen.
Warum Patch-Management ein eigenständiger MSP-Dienstleistungsbereich ist und keine bloße Aufgabe
Für die meisten MSPs war die Patch-Verwaltung anfangs nur ein Punkt auf der Checkliste im managed services . Sie war in der Gebühr pro Endgerät enthalten, lief irgendwo im Hintergrund und tauchte in den Monatsberichten als Prozentsatz auf. Es handelte sich um einen unvermeidbaren Geschäftsaufwand, nicht um eine eigenständige Dienstleistung.
Diese Positionierung hat sich mittlerweile als überholt erwiesen. Drei Faktoren haben dazu geführt, dass das Patching aus dem Backoffice in den Mittelpunkt der Vertriebs-, Bereitstellungs- und Preisgestaltung von MSPs gerückt ist.
An erster Stelle steht die Cyberversicherung. Versicherer betrachten das Installieren von Patches mittlerweile als grundlegende Kontrollmaßnahme. Ein dokumentiertes SLA für Patches, der Nachweis, dass kritische CVEs umgehend behoben werden, sowie ein externer Scan der Angriffsfläche sind Standardpunkte in Antragsformularen und Fragebögen zur Vertragsverlängerung. Der „Global Insurance Market Index“ von Marsh für das zweite Quartal 2025 verzeichnete den neunten Rückgang der Prämien für gewerbliche Cyberversicherungen in Folge, was zum Teil darauf zurückzuführen ist, dass sich die Kontrollmaßnahmen in der gesamten Versicherungsbasis verbessert haben. Versicherer führen zudem während der Vertragslaufzeit strengere Prüfungen durch, wobei die Häufigkeit von Patches zu den besonders wichtigen Kontrollmaßnahmen zählt, die darüber entscheiden, ob ein Schadenfall bezahlt wird. Ein MSP, der auf Anfrage Patch-Nachweise für jeden einzelnen Kunden vorlegen kann, bietet etwas Wesentliches anderes an als einer, der dazu nicht in der Lage ist.
Der zweite Punkt betrifft die Bedrohungsdaten. Im Jahr 2025 wurden rund 50.000 CVEs veröffentlicht, was einem Anstieg von 22 % gegenüber dem Vorjahr entspricht, und etwa 30 % der im CISA-Katalog „Known Exploited Vulnerabilities“ aufgeführten Schwachstellen werden innerhalb von 24 Stunden nach ihrer Offenlegung für Angriffe missbraucht. Das Zeitfenster für ein kompetentes Patching-Programm hat sich von Wochen auf Tage verkürzt. Für MSPs, die KMUs betreuen, die über keine internen Sicherheitskapazitäten verfügen, macht diese Verkürzung das Patchen zum kostengünstigsten Schutz, den der Kunde erwerben kann.
Der dritte Punkt ist die Haftung. Der MSP-Versicherungsmarkt verzeichnet, dass in den letzten Jahren ein beträchtlicher Anteil der MSPs Cyber-bezogene Schadensfälle gemeldet hat, wobei fehlerhafte Patch-Installationen und nicht gepatchte Kundennetzwerke zu den häufigsten Schadensursachen zählen. Das vertragliche Risiko ist real. Ein MSA-Vertrag, der die Installation von Patches als Teil der Dienstleistung verspricht, in Verbindung mit einem Sicherheitsvorfall beim Kunden, der auf ein nicht gepatchtes System zurückzuführen ist, ist genau das Szenario, auf dem ein Tech-E&O-Schadensfall basiert.
Zusammengenommen machen diese Faktoren das Patch-Management nicht mehr zu einer nebensächlichen operativen Aufgabe, sondern zu einem eigenständigen Serviceangebot mit eigenen SLAs, einem Nachweispaket und einem festen Preis. Die MSPs, die diesen Wandel vollzogen haben, erzielen mit demselben Kundenstamm höhere Margen, da sie nicht mehr für eine Tätigkeit (die Durchführung von Updates), sondern für ein Ergebnis (einen nachweislich sicheren Patch-Status) abrechnen.
Wer sich eingehender mit diesem Fachgebiet befassen möchte, findet in Kaseyas Leitfaden zum Thema Patch-Management eine Einführung in die grundlegenden Konzepte, auf denen der weitere Verlauf dieses Beitrags aufbaut.
Was das MSP-Patch-Management wirklich auszeichnet
In allgemeinen Abhandlungen zum Patch-Management wird das Problem der Mandantenumgebung oft als „Patching, nur mit mehr Mandanten“ dargestellt. Diese Sichtweise verkennt jedoch, was sich tatsächlich ändert. Der Arbeitsaufwand ist nicht größer. Vielmehr unterscheidet sich die Situation in folgenden fünf Punkten grundlegend:
Unterschiedliche Stacks pro Kunde
Ein einziges internes IT-Team standardisiert auf eine Betriebssystemversion, einen zugelassenen Browser, eine Office-Suite und eine Handvoll Fachanwendungen. Ein MSP, der fünfzig KMUs betreut, unterstützt fünfzig verschiedene Anwendungsumgebungen – vom Augenarzt, der ein spezielles Praxismanagementsystem auf einem älteren Windows Server betreibt, über das Architekturbüro, das CAD-Software mit hartnäckigen Treiberabhängigkeiten einsetzt, bis hin zur Anwaltskanzlei, deren Dokumentenmanagement-Plattform ausfällt, wenn ein bestimmtes Office-Update zuerst installiert wird. Das Patch-Tool muss diese Vielfalt abbilden, ohne jeden Kunden auf denselben Release-Zug zu zwingen.
Verschiedene Wartungsfenster
Ein Industriekunde führt Patches sonntags um 3 Uhr morgens durch, da dies der einzige Zeitpunkt ist, zu dem die Produktionslinie stillsteht. Ein Einzelhändler führt Patches unter der Woche durch, da am Wochenende die höchsten Umsätze erzielt werden. Eine Arztpraxis kann zwischen 8 und 18 Uhr keinen einzigen Arbeitsplatzrechner neu starten. Jeder Kunde hat ein Zeitfenster, und diese Zeitfenster stimmen nicht überein. Einen einheitlichen Wartungsplan für alle Kunden anzuwenden, ist der schnellste Weg, ein Kundengespräch zu stören und den Kunden zu verlieren. Das Tool muss den Zeitplan pro Kunde in Ortszeit verwalten und Ausnahmen für unvermeidbare Sonderfälle berücksichtigen.
Unterschiedliche SLAs und Genehmigungsabläufe
Manche Kunden möchten, dass jeder kritische Patch innerhalb von 48 Stunden bereitgestellt wird, ohne dass eine manuelle Freigabe erforderlich ist. Andere verlangen, dass ihr CIO seine Zustimmung erteilt, bevor etwas in die Produktionsumgebung gelangt. Eine dritte Gruppe verfügt über Compliance-Rahmenwerke, die einen bestimmten stufenweisen Bereitstellungsansatz mit dokumentierten Testnachweisen vorschreiben. Multitenant-Patching bedeutet, mehrere Genehmigungsworkflows parallel auszuführen, wobei ein Prüfpfad nachweist, welcher Kunde welchen Patch nach welchem Zeitplan und unter wessen Verantwortung erhalten hat.
Berichterstattung und Bescheinigung pro Kunde
Jeder Kunde möchte seinen eigenen Bericht. Das Format muss für den Finanzvorstand des Kunden sinnvoll sein, nicht nur für den Techniker des MSP. Compliance-konforme Berichte für HIPAA, PCI DSS, ISO 27001, NIS2 und Cyber Essentials müssen für jeden Kunden auf Abruf und ohne manuellen Aufwand erstellt werden können. Nachweisunterlagen für Cyberversicherungen, die mittlerweile im Mittelpunkt von Risikoprüfungsgesprächen stehen, müssen den spezifischen Anforderungen des Versicherers entsprechen. White-Label-Berichte, die das Branding des MSP auf einem professionell gestalteten Compliance-Dokument präsentieren, machen aus einer technischen Tätigkeit eine vertretbare Dienstleistung.
Abrechnung und Verpackung
Die interne IT stellt keine Rechnungen aus – das übernimmt ein MSP. Das bedeutet, dass jede zeitaufwändige Patch-Aktivität entweder in eine Pauschalgebühr einfließen, eine abrechnungsfähige Position generieren oder in die Margenberechnung einfließen muss. Das Tool muss mit dem PSA-System kompatibel sein. Zeiteinträge aus fehlgeschlagenen Bereitstellungen müssen in der richtigen Ticket-Warteschlange landen. Die Anzahl der Endpunkte muss mit der Lizenzvereinbarung abgeglichen werden. Nichts davon ist glamourös, und doch entscheidet all dies darüber, ob die Service-Linie rentabel ist oder nicht.
Ein Tool, das diese fünf Dimensionen sauber abdeckt, ist das, was eine mandantenfähige Plattform von einem internen IT-Tool mit einer nachträglich angehängten Mandantenauswahl unterscheidet.
Das Betriebsmodell: Wie ein etablierter MSP „Patching as a Service“ umsetzt
MSPs, die Patch-Prozesse in großem Maßstab durchführen, betrachten diese nicht als eine Reihe von einmaligen Installationen. Sie behandeln sie vielmehr als ein verwaltetes Produkt mit eigenem Lebenszyklus, eigenem Nachweispfad und eigenen Serviceverpflichtungen. Das Modell besteht aus vier Komponenten.
Eine standardisierte Grundrichtlinie
Jeder Kunde beginnt mit derselben Standardrichtlinie, sofern kein besonderer Grund für eine Abweichung vorliegt. Die Standardrichtlinie ist klar definiert: Patches werden täglich gescannt, Sicherheitsupdates werden nach einer 48-stündigen Pilotphase automatisch genehmigt, Neustarts werden außerhalb der Geschäftszeiten geplant, und Anwendungen von Drittanbietern werden im gleichen Zyklus wie das Betriebssystem gepatcht. Abweichungen werden für jeden Kunden mit einer Begründung (Compliance, Abhängigkeit von Legacy-Anwendungen, Anforderungen an die Änderungskontrolle) und einem Überprüfungsdatum dokumentiert. Diese Disziplin macht Skalierbarkeit erst möglich. Eine maßgeschneiderte Patch-Verwaltung für jeden Kunden führt dazu, dass MSPs Techniker haben, die nur bestimmte Konten betreuen können, und eine Dokumentationskette, die niemand überprüfen kann.
Bereitstellungsringe, auch auf MSP-Ebene
Interne IT-Teams nutzen Sicherheitsringe, um den Schadensumfang zu begrenzen. MSPs benötigen diese eher mehr als weniger, denn ein fehlerhafter Patch legt nicht nur ein Unternehmen lahm, sondern gleich zehn oder zwanzig gleichzeitig. Das ausgereifte Modell nutzt die eigene Infrastruktur des MSP als Ring 0, eine kleine Gruppe vertrauenswürdiger Kunden (oft die eigenen Mitarbeiter des MSP) als Ring 1, den breiteren Kundenstamm mit geringem Risiko als Ring 2 und die Kunden mit hohem Risiko (Medizin, Recht, Finanzen, Fertigung/OT) als letzten Ring mit zusätzlicher Wartezeit. Das Tool muss die Aussetzung der Bereitstellung zwischen den Ringen auf Basis von Telemetriedaten aus früheren Ringen unterstützen, nicht nur anhand eines festen Zeiters. Lesen Sie unseren Beitrag zum automatisierten Patch-Management, um mehr über die Funktionsweise der Ringe zu erfahren.
Ein schriftliches Ausnahmeverzeichnis
Jede Entscheidung, dass „dieser Kunde diesen Patch nicht installieren kann“, wird in einem Register erfasst, zusammen mit einem namentlich genannten Verantwortlichen, einem angegebenen Grund, einer Ausgleichsmaßnahme und einem Überprüfungstermin. Das klingt nach Mehraufwand. Tatsächlich schützt es jedoch den MSP, wenn sechs Monate später etwas schiefgeht und der Kunde fragt, warum sein Datenbankserver nicht gepatcht wurde. Das Ausnahmeregister liefert zudem ein nützliches operatives Signal: Kunden mit wachsenden Ausnahmelisten sind Kunden, deren Risikoprofil sich verschiebt – was eher ein Thema für das vierteljährliche Geschäftstreffen (QBR) ist als ein bevorstehender Vorfall.
Nachweis der Compliance für jeden Kunden als kontinuierliches Ergebnis
Das Patch-Programm sollte seine eigenen Prüfnachweise als Nebenprodukt des Betriebs liefern und nicht als vierteljährliche Notübung. Der Patch-Status pro Gerät, die bis zur Behebung verbleibende Zeit nach Schweregrad, ein Ausnahmeregister sowie ein auf die jeweiligen regulatorischen Rahmenbedingungen des Kunden abgestimmter Compliance-Bericht sollten auf Abruf generiert werden können. Hier zeigt sich am deutlichsten der Unterschied zwischen einem Tool, das MSPs unterstützt, und einem Tool, das speziell für MSPs entwickelt wurde. Single-Tenant-Plattformen können zwar Berichte erstellen, doch die Arbeit, diese nach Kunden zu unterteilen, mit einem Branding zu versehen und für einen Versicherer aufzubereiten, erfolgt manuell. Multi-Tenant-Plattformen erzeugen diese Berichte als natürliche Folge ihrer Struktur.
Der springende Punkt: Ein funktionierendes MSP-Patch-Programm ähnelt eher einem Fertigungsprozess als einer IT-Tätigkeit. Standardisierte Eingaben, kontrollierte Abweichungen, Telemetrie in jeder Phase, Nachweise als Nebenprodukt. Die Techniker prüfen die Ausnahmen und Fehler. Den Rest erledigt das System.
Tools: Was ein MSP benötigt, was interne IT-Tools nicht bieten
Die meisten Tools für das Patch-Management wurden ursprünglich für die interne IT entwickelt und erst später an die Anforderungen von MSPs angepasst. Die architektonischen Einschränkungen machen sich schnell bemerkbar. Ein MSP, der eine Plattform evaluiert, sollte insbesondere die folgenden Funktionen prüfen, da genau hier bei für MSPs angepassten Tools häufig Schwachstellen auftreten.
Eine mandantenfähige Konsole, die auch wirklich mandantenfähig ist. Der Techniker sollte alle Kunden in einer Ansicht sehen und die Möglichkeit haben, sich in die Umgebung eines einzelnen Kunden zu vertiefen, ohne sich ab- und wieder anmelden zu müssen, sowie über rollenbasierte Zugriffsrechte verfügen, die einen datenübergreifenden Datenverlust zwischen Kunden verhindern. Eine oberflächliche Mandantenfähigkeit (ein Kundenfilter auf einer Single-Tenant-Konsole) hält einer echten Arbeitslast nicht stand.
Richtlinie pro Client mit globaler Übersteuerung. Der MSP definiert eine Standardrichtlinie auf globaler Ebene. Jeder Client kann für unvermeidbare Ausnahmen Übersteuerungen auf Standortebene vornehmen, ohne dass die globale Richtlinie als Grundlage verloren geht. Datto RMM unterstützt beispielsweise globale Richtlinien für das Patch-Management mit standortspezifischen Übersteuerungen bei Zeitplänen, Stromversorgungs- und Genehmigungsregeln – das richtige Strukturmodell für die Verwaltung im MSP-Maßstab.
Integration des Wartungsmodus mit der Überwachung. Wenn ein Patch-Fenster geöffnet wird, sollten die durch die Patch-Aktivität ausgelösten Warnmeldungen für dieses Fenster automatisch unterdrückt werden, damit das NOC nicht auf Fehlalarme bei Neustarts reagiert und das Warnprotokoll der einzelnen Clients übersichtlich bleibt. Dies ist eine kleine Funktion, die außerhalb der Geschäftszeiten einen erheblichen Arbeitsaufwand einspart.
Abdeckung von Endgeräten außerhalb des Netzwerks und im Roaming. KMU-Kunden verfügen über hybride Belegschaften. Laptops verbinden sich von zu Hause, aus Hotels und aus Cafés. Das Tool muss Patches über das Internet bereitstellen, ohne dass eine VPN-Verbindung erforderlich ist, saubere Wiederholungsversuche durchführen, sobald Geräte wieder online sind, und Transparenz über die Vielzahl von Geräten bieten, die das Zeitfenster verpasst haben.
Ein Katalog mit Anwendungen von Drittanbietern, der MSP-relevante Breite aufweist. Das Patchen von Betriebssystemen ist weitgehend gelöst. Der entscheidende Unterschied liegt in der Tiefe und Aktualität des Drittanbieter-Katalogs, da die meisten im Jahr 2025 ausgenutzten CVEs in Software von Drittanbietern und nicht im Betriebssystem zu finden waren. Ein Katalog mit 200 bis über 300 Anwendungen, der innerhalb weniger Werktage nach der Veröffentlichung durch den Anbieter aktualisiert wird, schließt diese Lücke. Der begleitende Beitrag zum Patch-Management von Drittanbietern geht näher auf die betrieblichen Einzelheiten ein.
Native PSA-Integration. Das Patch-Tool muss die Daten sauber an das PSA-System übermitteln. Fehlgeschlagene Bereitstellungen sollten Tickets in der richtigen Warteschlange, mit der richtigen Priorität und unter dem richtigen Vertrag generieren. Ohne diese Integration müssen Techniker Daten aus einem System doppelt in ein anderes eingeben, wodurch Margen verloren gehen.
White-Label-Berichterstattung. Die Berichte, die der Kunde sieht, sollten wie das Produkt des MSP aussehen, nicht wie das des Anbieters. Logo, Farben, Sprache – das klingt nach einer rein kosmetischen Angelegenheit. Kunden empfinden dies jedoch als Zeichen von Professionalität, und genau diese Professionalität rechtfertigt den Preis.
Integration von Schwachstellendaten. Das Patch-Tool sollte den Inhalt des CISA-KEV-Katalogs kennen und diesen anzeigen. Eine Plattform, die anzeigt: „Sie haben 12 Geräte, auf denen eine Betriebssystemversion mit einer aktiv ausgenutzten CVE läuft – hier ist der Patch, jetzt bereitstellen“, ist grundsätzlich nützlicher als eine, die fehlende Patches lediglich in alphabetischer Reihenfolge auflistet.
Verpackungs- und Preisgestaltungsmodelle
Gerade im Bereich der gewerblichen Netzwerkinfrastruktur lassen die meisten MSPs Geld auf dem Tisch liegen. Die Installation von Patches wird in der Regel ohne zusätzliche Marge in die managed services eingepreist, was bedeutet, dass der MSP das gesamte Risiko trägt, ohne von den Vorteilen zu profitieren. Das ausgereifte Geschäftsmodell trennt diese Leistung davon.
Die Preisgestaltung pro Endgerät nach einem gestaffelten Modell ist die gängigste Struktur. Eine Basisstufe umfasst Patches für das Betriebssystem und wichtige Drittanbieter-Software sowie monatliche Compliance-Berichte. Eine höhere Stufe bietet zusätzlich eine erweiterte Abdeckung des Drittanbieter-Katalogs, ein dokumentiertes SLA bezüglich der Bereitstellungszeit für kritische Patches, Compliance-Berichte im White-Label-Format sowie vierteljährliche Audit-Nachweis-Pakete. Eine Premium-Stufe für regulierte Kunden umfasst beglaubigte SLAs, die Betreuung durch einen namentlich benannten Techniker sowie die Integration in die Compliance-Berichterstattung des Kunden (HIPAA, PCI DSS, NIS2). Jede Stufe ist mit einem anderen Preis pro Endpunkt verbunden, wobei die höheren Stufen deutlich höhere Margen bieten.
Einige MSPs regeln die variablen Kosten, indem sie zusätzlich zur Endpunkt-Gebühr eine Kunden-Gebühr erheben. Die Endpunkt-Gebühr deckt die Bereitstellungskosten ab. Eine monatliche Pauschalgebühr pro Kunde deckt den Aufwand für die Richtlinienverwaltung, das Ausnahmeregister und die Berichterstellung ab, der nicht linear mit der Anzahl der Endpunkte steigt. Ein Kunde mit 10 Endpunkten und ein Kunde mit 200 Endpunkten verursachen einen ähnlichen Aufwand für Richtlinien und Berichterstellung; lediglich die Bereitstellung unterscheidet sich.
Das Anbieten von Patching als eigenständiges Dienstleistungsangebot ist das ehrgeizigste Geschäftsmodell, das manchmal auch als „Patching-as-a-Service“ oder „PMaaS“ bezeichnet wird. Der MSP erbringt Patching-Dienstleistungen für Kunden, die für den Rest ihrer IT einen anderen MSP nutzen, oder für interne IT-Teams, die speziell das Patch-Programm auslagern möchten. Dies ist schwieriger zu vermarkten und zu betreiben, erzielt jedoch einen höheren Preis und trennt die Patch-Arbeiten vom übergeordneten managed services .
Bei allen drei Modellen hängt die Wirtschaftlichkeit der einzelnen Einheiten von der Automatisierung ab. Die MSPs, die mit Patches eine solide Marge erzielen, sind diejenigen, deren Tool die Routinearbeiten ohne Aufsicht durch einen Techniker ausführt, sodass sich das Team auf Ausnahmen, Notfallmaßnahmen und die Kommunikation mit den Kunden konzentrieren kann. Die MSPs, deren Techniker jeden „Patch Tuesday“ Genehmigungen anklicken müssen, sind diejenigen, die mit diesem Dienstbereich Geld verlieren, ohne es zu merken.
Compliance und Haftung: Die eigentliche Absicherung
Beim Patchen ging es jahrelang um Sicherheit. Mittlerweile geht es dabei auch um vertragliche Risiken.
Der Wandel im Bereich der Cyberversicherung ist der auffälligste Aspekt. Die Versicherer geben sich nicht mehr mit bloßen Bestätigungen zufrieden. Sie verlangen Nachweise: dokumentierte und eingehaltene SLAs für Patches, nachgewiesene Abdeckung von Drittanbieteranwendungen sowie einen vertretbaren Prozess für Notfall-Patches. Ein MSP, der diese Nachweise bei einem Audit für jeden Kunden vorlegen kann, unterstützt den Kunden bei der Verlängerung seiner Police. Ein MSP, der dies nicht kann, setzt den Kunden der Gefahr einer Nichtverlängerung aus und sich selbst dem Risiko eines Tech-E&O-Schadensfalls, falls eine Sicherheitsverletzung auf ein nicht gepatchtes System zurückzuführen ist, das unter den MSA fällt.
Compliance-Rahmenwerke, die KMU-Kunden betreffen, werden hinsichtlich der Häufigkeit von Patches immer konkreter. PCI DSS 4.0 schreibt vor, dass kritische Sicherheitspatches innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen. HIPAA verlangt im Rahmen seiner Sicherheitsvorschriften eine zeitnahe Installation von Patches. NIS2 ist nun EU-weit in Kraft und erstreckt sich auch auf Lieferketten im Vereinigten Königreich, während ISO 27001:2022 mittlerweile die De-facto-Grundlage für Kunden darstellt, die an Unternehmensbeschaffungsstellen verkaufen. Jedes dieser Rahmenwerke verlangt Nachweise und nicht nur bloße Aktivitäten.
Die Haltung von MSPs zu all dem ist klar: Patch-Management ist keine Funktion, sondern eine vertretbare Dienstleistung, auf die der Kunde verweisen kann, wenn sein Wirtschaftsprüfer, Versicherer oder Vorstand nach der Cybersicherheitslage fragt. Diese Herangehensweise kommt in der Regel besser an als der Verkauf anhand technischer Funktionen. Finanzvorstände interessieren sich für Prüfungsergebnisse und Versicherungsprämien. Richtig präsentiert, spricht das Patch-Management beide Aspekte an.
Für MSPs, deren Programme noch nicht ganz ausgereift sind, bietet unser Blogbeitrag zum Aufbau einer Patch-Management-Richtlinie einen Überblick über das Dokument, auf dem ein ausgereiftes Programm basiert.
Häufige Fehler bei der Patch-Verwaltung durch MSPs und wie man sie vermeidet
Es gibt einige Muster, die sich bei MSPs wiederholen, deren Patch-Programme auf dem Papier gut aussehen, in der Praxis jedoch Probleme verursachen.
Kunden werden als Varianten der vom MSP bevorzugten Richtlinie behandelt, anstatt vom jeweiligen Risikoprofil des Kunden auszugehen. Die vom MSP bevorzugte Pilotphase mit 48-stündiger Verzögerung eignet sich weder für einen Kunden aus dem Gesundheitswesen, dessen Compliance-Rahmenbedingungen längere Testzeiträume erfordern, noch für einen Kunden aus der Fertigungsindustrie, für den 48 Stunden aufgrund der Ausfallkosten zu kurz sind.
Das pauschale Freigeben von Patches, ohne dabei Server von Workstations, OT-Systemen oder geschäftskritischen Systemen zu trennen. Eine pauschale Freigabe, durch die ein Patch gleichzeitig auf einem Domänencontroller und einem Laptop der Marketingabteilung installiert wird, führt zu Ausfällen.
Man verlässt sich auf die Kennzahl für den Erfolg der Bereitstellung, ohne diese mit einem Schwachstellenscan abzugleichen. Das Patch-Tool meldet, was es gesendet hat. Der Scanner meldet, was tatsächlich behoben wurde. In der Lücke zwischen beiden liegen die Ergebnisse der Prüfung.
Der Katalog der Drittanbieter-Anwendungen wird zum Engpass. Das Problem der Betriebssystem-Patches scheint gelöst zu sein – bei Patches von Drittanbietern ist dies jedoch oft nicht der Fall. MSPs, die ihre Abdeckung durch Drittanbieter in den letzten 12 Monaten nicht überprüft haben, sind in der Regel überrascht von dem, was sie vorfinden.
Die Berichterstellung wird als Nebensache betrachtet. Die Kunden, die Verträge mit umfangreichen Patches verlängern, erhalten jeden Monat ansprechende, markenspezifische und auf Compliance-Vorgaben abgestimmte Berichte. Die Kunden, die beim Preis verhandeln, bekommen lediglich eine CSV-Datei.
Was die grundlegenden Aspekte betrifft, die die meisten dieser Muster verhindern, behandelt unser Beitrag zu Best Practices im Patch-Management die Arbeitsabläufe, die erfolgreiche Programme von solchen unterscheiden, die mit Schwierigkeiten zu kämpfen haben.
Wie Kaseya MSPs beim Patch-Management unterstützt
Ein funktionierendes MSP-Patch-Programm benötigt eine Plattform, die zuverlässig genug ist, damit das Team der Automatisierung vertraut, die mandantenfähig genug ist, damit die Arbeit ohne entsprechenden Personalaufwand skaliert werden kann, und die transparent genug ist, damit der Kunde den Mehrwert erkennen kann. Das ist das Konzept, auf dem das Patch-Management von Datto RMM basiert, und hier verschmelzen das Betriebsmodell und die Tooling-Lösungen zu einer Einheit.
Globale Richtlinien für das Patch-Management mit Standort-spezifischen Ausnahmen hinsichtlich Zeitplan, Neustartverhalten und Genehmigungsregeln bieten MSPs die erforderliche Flexibilität auf Kundenebene, ohne dabei auf eine standardisierte Basis zu verzichten. Der Wartungsmodus unterdrückt Überwachungswarnungen während Patch-Fenstern automatisch und beseitigt so eine häufige Ursache für Störungen außerhalb der Geschäftszeiten. „Patch Now“ kümmert sich um Notfall-Bereitstellungen, die nicht auf den regulären Zyklus warten können. Das Software-Management-Modul deckt Patches von Drittanbietern für über 200 Windows- und macOS-Anwendungen ab, die innerhalb weniger Werktage nach der Veröffentlichung durch den Hersteller bereitgestellt werden. Autotask native Autotask schließt den Kreis bei Tickets, Abrechnung und Compliance-Berichten pro Kunde.
Datto RMM ist ebenfalls Teil von Kaseya 365, dem einheitlichen Abonnement, das RMM, Sicherheit, Backup und Automatisierung zu einem einzigen Preis pro Endpunkt bündelt. Auf diese Weise konsolidieren viele MSPs die Betriebskosten für den Einsatz mehrerer separat lizenzierter Tools.
Die Arbeit an sich ändert sich von Jahr zu Jahr kaum. Was sich ändert, ist der Einsatz. Cyber-Versicherer beobachten die Lage aufmerksam. Kunden in regulierten Branchen benötigen stichhaltige Nachweise. Die Bedrohungslage verschärft sich zunehmend, und die Zeitfenster für Patches werden immer kürzer. Nichts davon spricht dafür, das Patch-Management als reine Abhakaufgabe im Backoffice zu betreiben. All dies spricht dafür, es als eigenständigen Geschäftsbereich zu betreiben, der sich bezahlt macht – auf einer Plattform, die speziell auf die Arbeitsweise von MSPs zugeschnitten ist.
