MSP-Patch-Management: So sorgen Sie für die Sicherheit jedes einzelnen Clients
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 – bei guter Vermarktung – still und leise für wiederkehrende Umsätze. Außerdem 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 Satz von Stacks, einem Satz von Wartungsfenstern und einem Genehmigungsworkflow. Ein MSP führt dasselbe Playbook fünfzig oder hundert Mal parallel aus – und zwar in fünfzig oder hundert verschiedenen Umgebungen, die keine einzige gemeinsame Regel teilen. Das ist keine skalierte Version der internen IT-Patch-Verwaltung. Es handelt sich um 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 Endgeräten ihrer Kunden zu installieren. Sie bietet einen klaren Überblick darüber, wo die Patch-Programme der MSPs auch unter hoher Auslastung standhalten und wo sie versagen.
In diesem Artikel wird untersucht, 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 erfahrene MSPs diese Dienstleistung bündeln und bepreisen.
Warum Patch-Management ein eigenständiger MSP-Dienstleistungsbereich ist und keine bloße Aufgabe
Für die meisten MSPs begann die Patch-Verwaltung als ein Punkt auf der Checkliste im „ managed services “-Vertrag. Sie war in der Gebühr pro Endpunkt enthalten, lief irgendwo im Hintergrund und tauchte in den Monatsberichten als Prozentsatz auf. Es handelte sich um einen 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.
Der erste Punkt ist 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 Angriffsflächen-Scan gehören mittlerweile standardmäßig zu den Angaben 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 Cyber-Prämien für gewerbliche Versicherungen in Folge, was zum Teil darauf zurückzuführen ist, dass sich die Kontrollmaßnahmen in der gesamten Versichertenbasis verbessert haben. Versicherer führen zudem während der Vertragslaufzeit strengere Prüfungen durch, wobei die Häufigkeit der Patches zu den besonders wichtigen Kontrollmaßnahmen zählt, die darüber entscheiden, ob ein Schadenfall bezahlt wird. Ein MSP, der auf Anfrage nachweisbare Patch-Daten für jeden einzelnen Kunden vorlegen kann, bietet ein wesentlich anderes Produkt 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 genutzt. 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 kosteneffizientesten Schutz, den der Kunde erwerben kann.
Der dritte Punkt ist die Haftung. Der MSP-Versicherungsmarkt berichtet, dass in den letzten Jahren ein erheblicher Anteil der MSPs Cyber-bezogene Schadensfälle gemeldet hat, wobei fehlgeschlagene Patch-Installationen und nicht gepatchte Kundennetzwerke zu den wiederkehrenden Schadensarten zählen. Das vertragliche Risiko ist real. Ein MSA, der das Aufspielen von Patches als Teil der Dienstleistung verspricht, gepaart 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 verwandeln diese Faktoren das Patch-Management von einer nebensächlichen operativen Aufgabe in ein eigenständiges 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 nachweisbaren Patch-Status) abrechnen.
Für einen tieferen Einblick in das zugrunde liegende Fachgebiet behandelt der Leitfaden von Kaseya zum Thema „Patch-Management“ die grundlegenden Konzepte, auf denen der Rest dieses Beitrags aufbaut.
Was das MSP-Patch-Management wirklich auszeichnet
In allgemeinen Darstellungen zum Patch-Management wird das Problem der Mandantenumgebung als „Patching, nur mit mehr Mandanten“ behandelt. Diese Sichtweise verkennt jedoch, was sich tatsächlich ändert. Der Arbeitsaufwand ist nicht größer. Er unterscheidet sich strukturell in den folgenden fünf Punkten:
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 KMU betreut, unterstützt fünfzig verschiedene Anwendungsumgebungen – vom Augenarzt, der ein spezialisiertes 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 dieser Vielfalt gerecht werden, ohne jeden Kunden in denselben Release-Zyklus zu zwingen.
Unterschiedliche Wartungsfenster
Ein Kunde aus der Fertigungsindustrie führt Patches am Sonntag 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 Arbeitsplatz-PC neu starten. Jeder Kunde hat ein Zeitfenster, und diese Zeitfenster stimmen nicht überein. Die Anwendung eines einheitlichen Wartungsplans für alle Kunden ist der schnellste Weg, ein Kundengespräch zu stören und den Auftrag 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
Einige 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, mit einem Prüfpfad, der belegt, 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 verständlich 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 der Gespräche mit den Versicherern stehen, müssen den spezifischen Anforderungen des Versicherers entsprechen. White-Label-Berichte, bei denen das Branding des MSP auf einem professionell gestalteten Compliance-Dokument erscheint, machen aus einer technischen Tätigkeit eine vertretbare Dienstleistung.
Abrechnung und Verpackung
Die interne IT stellt keine Rechnungen aus – ein MSP hingegen schon. 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 zusammenarbeiten. Zeiteinträge aus fehlgeschlagenen Bereitstellungen müssen in die richtige Ticket-Warteschlange gelangen. Die Endpunktzahlen müssen mit der Lizenzvereinbarung abgeglichen werden. Nichts davon ist besonders glamourös, und doch entscheidet all dies darüber, ob die Dienstleistungssparte 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
Die MSPs, die Patch-Installationen in großem Umfang durchführen, betrachten diese nicht als eine Reihe von einmaligen Bereitstellungen. 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 spezifischer 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üfungstermin 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 Kunden betreuen können, und eine Dokumentationskette, die niemand überprüfen kann.
Bereitstellungsringe, auch auf MSP-Ebene
Interne IT-Teams nutzen Ringe, um den Ausbruchbereich zu begrenzen. MSPs benötigen sie 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, operative Technik in der Fertigung) 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 weitere Details zur Funktionsweise der Ringe zu erfahren.
Ein schriftliches Ausnahmeverzeichnis
Jede Entscheidung nach dem Motto „Dieser Kunde kann diesen Patch nicht installieren“ wird in einem Register erfasst, mit Angabe eines Verantwortlichen, eines Grundes, einer Ausgleichsmaßnahme und eines Überprüfungstermins. 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 immer länger werdenden Ausnahmelisten sind Kunden, deren Risikoprofil sich verschiebt – was eher ein Thema für das vierteljährliche Geschäftstreffen (QBR) ist als ein bevorstehender Vorfall.
Nachweise zur Einhaltung der Vorschriften 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 Installation verbleibende Zeit nach Schweregrad, ein Ausnahmeregister sowie ein auf die jeweiligen regulatorischen Rahmenbedingungen des Kunden abgestimmter Compliance-Bericht sollten auf Abruf generiert werden. 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 der Aufwand, diese nach Kunden aufzuschlüsseln, 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 entscheidende Punkt: Ein funktionierendes MSP-Patch-Programm ähnelt eher einem Fertigungsprozess als einer IT-Aktivität. Standardisierte Eingaben, kontrollierte Abweichungen, Telemetrie in jeder Phase, Nachweise als Nebenprodukt. Die Techniker überprüfen die Ausnahmen und Fehler. Den Rest erledigt das System.
Tools: Was ein MSP benötigt, was interne IT-Tools jedoch nicht bieten
Die meisten Patch-Management-Tools wurden ursprünglich für die interne IT entwickelt und erst später für MSPs angepasst. Die architektonischen Einschränkungen zeigen sich schnell. Ein MSP, der eine Plattform evaluiert, sollte insbesondere die folgenden Funktionen testen, da genau hier bei für MSPs angepassten Tools häufig Probleme 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, detaillierte Einblicke in die Umgebung eines beliebigen Kunden zu gewinnen, ohne sich ab- und wieder anmelden zu müssen – und das mit rollenbasierten Zugriffsrechten, 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 Kunde mit globaler Übersteuerung. Der MSP definiert eine Standardrichtlinie auf globaler Ebene. Für jeden Kunden können auf Standortebene Übersteuerungen für unvermeidbare Ausnahmen festgelegt werden, ohne dass die globale Richtlinie als Grundlage verloren geht. Datto RMM unterstützt beispielsweise globale Richtlinien für das Patch-Management mit standortbezogenen Übersteuerungen hinsichtlich Zeitplan, Leistung und Genehmigungsregeln – das richtige Strukturmodell für die Verwaltung im MSP-Maßstab.
Integration des Wartungsmodus mit der Überwachung. Wenn sich ein Patch-Fenster öffnet, sollten die durch die Patch-Aktivität ausgelösten Warnmeldungen für dieses Fenster automatisch unterdrückt werden, damit das NOC nicht auf Fehlalarme im Zusammenhang mit 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 stellen von zu Hause, aus Hotels und Cafés eine Verbindung her. Das Tool muss Patches über das Internet bereitstellen, ohne dass eine VPN-Verbindung erforderlich ist, bei der Wiederherstellung der Internetverbindung die Installation sauber wiederholen und Transparenz über die zahlreichen Geräte bieten, die das Zeitfenster verpasst haben.
Anwendungskatalog von Drittanbietern mit MSP-relevanter Breite. Das Patchen von Betriebssystemen ist weitgehend ein gelöstes Problem. Das Unterscheidungsmerkmal ist die 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 für Drittanbieter-Software 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 – und genau hier schwindet die Marge.
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 zwar nach einer rein kosmetischen Angelegenheit. Kunden nehmen dies jedoch als Zeichen von Professionalität wahr, 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. Patches werden in der Regel ohne zusätzliche Marge in die Gebühr für die „ managed services “ eingebunden, was bedeutet, dass der MSP das gesamte Risiko trägt, ohne von den Vorteilen zu profitieren. Das ausgereifte Modell trennt diese Leistungen voneinander.
Die Preisgestaltung pro Endpunkt 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 zur Bereitstellungszeit kritischer Patches, Compliance-Berichte im White-Label-Format sowie vierteljährliche Audit-Nachweis-Pakete. Eine Premium-Stufe für regulierte Kunden umfasst zusätzlich 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 handhaben die variablen Kosten so, dass sie zusätzlich zur Endpunkt-Gebühr eine Kundengebühr erheben. Die Endpunkt-Gebühr deckt die Bereitstellung 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 Patchen als eigenständiger Dienstleistungsbereich ist das ehrgeizigste Modell, das manchmal auch als „Patching-as-a-Service“ oder „PMaaS“ bezeichnet wird. Der MSP erbringt Patch-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 umfassenderen „ managed services “-Vertrag.
Bei allen drei Modellen hängen die Wirtschaftlichkeitskennzahlen 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. Versicherer geben sich nicht mehr mit bloßen Ankreuz-Erklärungen 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 zum Zeitpunkt des Audits für jeden Kunden vorlegen kann, unterstützt den Kunden bei der Verlängerung seiner Police. Ein MSP, der dazu nicht in der Lage ist, setzt den Kunden dem Risiko einer Nichtverlängerung aus und sich selbst dem Risiko eines Tech-E&O-Schadensfalls, falls sich eine Sicherheitsverletzung auf ein nicht gepatchtes System zurückführen lässt, 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 der De-facto-Standard für Kunden ist, die im Rahmen von Unternehmensbeschaffungen 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, sein Versicherer oder sein 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 dargestellt, 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
Bei einigen MSPs lassen sich bestimmte Muster erkennen: Ihre Patch-Programme sehen auf dem Papier zwar gut aus, führen in der Praxis jedoch zu Problemen.
Kunden werden als Varianten der vom MSP bevorzugten Richtlinie behandelt, anstatt vom jeweiligen Risikoprofil des Kunden auszugehen. Die vom MSP bevorzugte Pilotverzögerung von 48 Stunden 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, bei der 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 diesen beiden Angaben liegen die Ergebnisse des Audits.
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 ihre Verträge mit umfangreichen Patches verlängern, erhalten jeden Monat ausgefeilte, mit ihrem Branding versehene und den Compliance-Anforderungen entsprechende Berichte. Die Kunden, die beim Preis verhandeln, erhalten 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 betrieblichen Vorgehensweisen, 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 sich der Arbeitsaufwand ohne entsprechenden Personalaufbau skalieren lässt, 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 genau hier hören das Betriebsmodell und die Tools auf, getrennte Themen zu sein.
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 Basislinie zu verzichten. Der Wartungsmodus unterdrückt automatisch Überwachungswarnungen während der Patch-Fenster 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 Modul „Software Management“ 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. Die native PSA-Integration von „ Autotask “ schließt den Kreis bei Tickets, Abrechnung und Compliance-Berichten pro Kunde.
Datto RMM ist zudem 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 selbst ändert sich von Jahr zu Jahr kaum. Was sich jedoch ä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.
