Patch-Management durch Drittanbieter: Warum es entscheidend ist und wie man die IT automatisieren kann
Das Dashboard zur Patch-Compliance zeigt 96 % an. Windows ist auf dem neuesten Stand, macOS ist auf dem neuesten Stand, das Sicherheitsteam gibt seine Zustimmung und der Bericht geht an den Prüfer. Das Problem ist, dass sich diese 96 % nur auf das Betriebssystem beziehen. Der Endpunkt, der sich unter dieser grünen Kachel verbirgt, läuft zudem mit einer Chrome-Version aus dem Spätsommer, einer Adobe-Reader-Version, für die drei CVEs veröffentlicht wurden, einem Zoom-Client, der älter ist als die letzte Sicherheitsempfehlung, und einer Java-Laufzeitumgebung, an die seit achtzehn Monaten niemand im Team mehr gedacht hat. Nichts davon fließt in die Bewertung ein.
Genau diese Lücke soll das Patch-Management für Drittanbieter schließen, und für die meisten IT-Teams und MSPs ist dies der Teil des Patch-Programms, der im Verhältnis zum tatsächlichen Risiko stillschweigend unterfinanziert ist. Laut dem Qualys-Unternehmens-Benchmark 2026 beträgt die durchschnittliche Zeit bis zur Behebung bei komplexen Drittanbieteranwendungen fünf Monate und zehn Tage. Angreifer agieren hingegen in einem Zeitfenster, das sich in Tagen, manchmal sogar in Stunden bemisst. Diese beiden Zeitrahmen sind nicht miteinander vereinbar.
Die RMM-Lösungen von Kaseya übernehmen das Patch-Management für Millionen von Endgeräten bei MSPs und internen IT-Teams weltweit und liefern einen klaren Überblick darüber, wo Patch-Programme von Drittanbietern unter Druck bestehen und wo sie versagen. Dieser Leitfaden erläutert, was Patch-Management durch Drittanbieter ist, warum die Abläufe schwieriger sind als beim OS-Patching, welche Prioritäten gesetzt werden sollten, wie das Programm operativ aufgebaut werden sollte und welche Anforderungen an die Automatisierung gestellt werden müssen, um mit dem Release-Rhythmus Schritt zu halten.
Was versteht man unter Patch-Management für Drittanbieter-Software?
Das Patch-Management für Drittanbieter-Software umfasst die Identifizierung, Bewertung, Bereitstellung und Überprüfung von Updates für die auf Ihren Endgeräten ausgeführte Software, die nicht vom Betriebssystemhersteller bereitgestellt wird. Das ist ein weit gefasster Begriff. Dazu gehören Browser, PDF-Reader, Konferenz-Clients, Laufzeitumgebungen wie Java und .NET, Office-Suiten, Entwicklertools, Komprimierungsprogramme und die Vielzahl an Geschäftsanwendungen, die sich im Laufe der Zeit in jeder Umgebung ansammeln.
Es fällt zwar unter denselben übergeordneten Bereich des Patch-Managements wie das Patchen von Betriebssystemen, unterliegt jedoch anderen Rahmenbedingungen. Microsoft, Apple und die großen Linux-Distributionen stellen ihre Updates über standardisierte, gut überwachte Kanäle bereit. Drittanbieter tun dies nicht. Für Slack gibt es keinen „Patch Tuesday“. Es gibt keinen zentralen Katalog, der den Release-Zeitplan von Adobe mit dem von Mozilla, dem von Oracle und der Nischen-Branchenanwendung verknüpft, die das Finanzteam 2019 installiert hat. Jeder Anbieter veröffentlicht Updates in seinem eigenen Rhythmus, in seinem eigenen Format und über seinen eigenen Kanal, und jemand muss den Überblick über alle gleichzeitig behalten.
Der Begriff „Drittanbieter“ deckt hier ein breites Spektrum ab. Er umfasst alles – vom Browser, den jeder Mitarbeiter im Unternehmen nutzt, bis hin zu einem speziell für einen bestimmten Zweck entwickelten Entwicklungstool, das auf drei Rechnern installiert ist. Beide fallen unter denselben betrieblichen Begriff und beide können als Einstiegspunkt für einen Sicherheitsverstoß dienen.
Warum Patches von Drittanbietern wichtiger denn je sind
Jahrelang herrschte die Auffassung vor, dass Sicherheitslücken im Betriebssystem das Hauptproblem darstellten und Anwendungen nur eine untergeordnete Rolle spielten. Das trifft schon seit einiger Zeit nicht mehr zu. Die Daten haben nach und nach aufgeholt, was Angreifern bereits bekannt war.
Die von Adaptiva gemeinsam mit Demand Metric durchgeführte Umfrage „State of Patch Management 2025“ ergab, dass 87 % der Unternehmen im vergangenen Jahr auf Sicherheitslücken in Anwendungen von Drittanbietern gestoßen sind, die durch Patches behoben werden mussten. Das ist kein Ausnahmefall. Es ist der Normalzustand in nahezu jeder IT-Umgebung, in der moderne Software zum Einsatz kommt.
Der „CISA Known Exploited Vulnerabilities“-Katalog beleuchtet dasselbe Phänomen aus einer anderen Perspektive. Die KEV-Liste erfasst Sicherheitslücken, die von Angreifern aktiv ausgenutzt werden – nicht nur theoretische, nach CVSS bewertete Schwachstellen –, und ein stetiger Anteil der neuen Einträge betrifft Anwendungen von Drittanbietern und nicht die Kernbetriebssysteme. Monat für Monat tauchen Browser, Dokumentenleser, Konferenztools und Laufzeitbibliotheken auf. Sie sind weit verbreitet, es werden regelmäßig Sicherheitsupdates veröffentlicht, und genau in der Lücke zwischen der Veröffentlichung durch den Anbieter und der Installation durch den Endnutzer schlagen Angreifer zu.
Das Tempo macht die Sache noch komplizierter. Am „Patch Tuesday“ im April 2026 hat Microsoft allein in seinem eigenen Software-Stack 163 CVEs behoben. Rechnet man Adobe, Oracle, Google, Mozilla, Cisco, Atlassian und ein Dutzend weiterer Anbieter hinzu, sieht das monatliche Volumen, mit dem jedes Patch-Programm Schritt halten soll, schon fast unzumutbar aus. Eine manuelle Überprüfung eines Feeds dieser Größe ist keine Strategie.
Der „Verizon Data Breach Investigations Report 2025“ ermittelte, dass in 20 % der Sicherheitsvorfälle die Ausnutzung von Schwachstellen als erster Zugangsweg diente – ein Anstieg um 34 % gegenüber dem Vorjahr. Dieser Anstieg ist nicht allein auf Zero-Day-Angriffe auf Betriebssystemebene zurückzuführen. Er spiegelt die stetige Ausnutzung von Schwachstellen in Software von Drittanbietern wider, von deren Einsatz die Unternehmen entweder nichts wussten oder für die sie noch keine Patches installiert hatten.
Herausforderungen beim Patch-Management von Drittanbietern
Sobald man weiß, dass das Risiko tatsächlich besteht, stellt sich natürlich die Frage, warum so viele Programme diese Sicherheitslücke dennoch offen lassen. Die Antwort ist technischer Natur und hat nichts mit der Motivation zu tun. Das Patchen von Drittanwendungen ist aus vier miteinander verknüpften Gründen strukturell schwieriger als das Patchen von Betriebssystemen.
Zersplitterung der Anbieter
Die Update-Infrastruktur von Microsoft kümmert sich um Microsoft-Software. Die von Apple um macOS. Für den Rest gibt es keinen vergleichbaren einheitlichen Kanal. Jeder ISV unterhält sein eigenes Release-Portal, sein eigenes Format für Ankündigungen und seinen eigenen Bereitstellungsmechanismus. Um Releases von 50 oder 100 Anwendungen von Drittanbietern manuell zu verfolgen, muss man Dutzende separater Feeds abonnieren und jeden einzelnen in konkrete Maßnahmen umsetzen. Das ist eine Vollzeitaufgabe, für die die meisten Teams keine personellen Ressourcen haben.
Variabilität der Schrittfrequenz
Der „Patch Tuesday“ bietet Ihnen einen festen Rhythmus für Windows. Veröffentlichungen von Drittanbietern folgen keinem solchen Rhythmus. Ein kritischer Browser-Patch kann mitten in der Woche erscheinen. Ein Laufzeit-Update kann ohne Vorankündigung veröffentlicht werden. Ein Konferenztool kann einen Sicherheits-Build veröffentlichen, noch während ein Drucker-Treiberhersteller eine CVE-Meldung veröffentlicht. Weder das Volumen noch der Zeitpunkt sind vorhersehbar, was bedeutet, dass ein auf einem monatlichen Rhythmus basierendes Patch-Programm zeitkritische Updates von Drittanbietern naturgemäß regelmäßig verpasst.
Vielfalt der Installateure
Betriebssystem-Patches werden über standardisierte Mechanismen bereitgestellt. Anwendungen von Drittanbietern nutzen MSI, EXE, MSIX, App-V, herstellerspezifische Updater, webbasierte Installationsprogramme und gelegentlich maßgeschneiderte Bereitstellungsskripte. Jedes Format verfügt über eigene Flags für die unbeaufsichtigte Installation, ein eigenes Neustartverhalten, eine eigene Logik zur Versionserkennung und eigene Fehlermodi. Eine zuverlässige Automatisierung bei dieser Vielfalt erfordert entweder ein Tool mit herstellergeprüfter Unterstützung für jede Anwendung oder benutzerdefinierte Skripte, die von Ihrem Team auf unbestimmte Zeit gepflegt werden müssen.
Entdeckung
Man kann nichts patchen, von dem man nicht weiß, dass es vorhanden ist. Benutzer installieren Anwendungen außerhalb der von der IT genehmigten Kanäle. Durch Übernahmen werden nicht verwaltete Softwarebestände übernommen. Abteilungen standardisieren auf Tools, von denen das Endpunkt-Team nichts weiß. Ohne eine kontinuierliche, agentengestützte Erfassung, die jede installierte Anwendung und Version auf jedem verwalteten Gerät aufdeckt, stützt sich das Patching-Programm auf einen Bestand, der bereits von Anfang an falsch ist.
Diese vier Einschränkungen lassen sich nicht durch zusätzliche Anstrengungen beseitigen. Sie sind Eigenschaften des Ökosystems der Drittanbietersoftware selbst. Ein funktionierendes Programm ist eines, das sich an diese Einschränkungen anpasst, anstatt gegen sie anzukämpfen.
Welche Anwendungen sollten vorrangig behandelt werden?
Nicht jede Drittanbieteranwendung birgt das gleiche Risiko – und wenn man sie alle über einen Kamm schert, sind die Programme am Ende genauso anfällig wie gar keine Programme. Der richtige Ansatz besteht darin, sie nach ihrem Einsatzumfang, ihrer Ausnutzungshistorie und ihrer Nähe zum Netzwerkrand in Stufen einzuteilen und dann die Häufigkeit der Überprüfungen und die SLAs auf die oberste Stufe zu konzentrieren.
Browser stehen ganz oben auf fast jeder Liste. Chrome, Edge, Firefox und Brave sind auf jedem Endgerät installiert, stellen per Definition nicht vertrauenswürdige Inhalte aus dem gesamten Internet dar und erhalten mehrmals im Monat Sicherheitsupdates. Außerdem werden die Updates häufig erst nach einem Neustart angewendet, was bedeutet, dass ein verfügbarer Patch erst dann tatsächlich installiert ist, wenn der Benutzer das Fenster schließt. Ein SLA von 24 bis 48 Stunden für kritische Browser-Updates, dessen Einhaltung durchgesetzt wird, ist eine angemessene Grundvoraussetzung.
Als Nächstes kommen PDF- und Dokumenten-Reader. Adobe Acrobat und Reader weisen eine lange Liste kritischer CVEs auf und sind seit jeher das Ziel bösartiger Dokumente, die per E-Mail versendet werden. Eine aktuelle Version auf jedem Endgerät ist für die meisten Teams die kostengünstigste Möglichkeit, die Erfolgsquote von Phishing-Angriffen sinnvoll zu senken.
Laufzeitumgebungen bilden die dritte Gruppe. Java, OpenJDK, die .NET-Laufzeitumgebungen und verschiedene JavaScript-Engines bilden die Grundlage für Unternehmensanwendungen, die für Sicherheitstools möglicherweise nicht als eigenständige Abhängigkeiten erkennbar sind. Eine Sicherheitslücke in einer Laufzeitumgebung betrifft jede darauf aufbauende Anwendung, und der Schadensumfang kann groß sein, selbst wenn die Laufzeitumgebung selbst eher unbekannt erscheint.
Anwendungsprogramme für Konferenzen und Zusammenarbeit bilden eine vierte Kategorie. Zoom, Teams (als eigenständige Installation), Slack und ähnliche Tools sind überall installiert, interagieren mit nicht vertrauenswürdigen externen Links und Dateien und werden regelmäßig aktualisiert. Ihre Angriffsfläche ähnelt der eines Browsers, auch wenn ihre Sichtbarkeit im Bestandsverzeichnis unterschiedlich ist.
Komprimierungsprogramme, Archivierungstools, Entwicklerabhängigkeiten und die Vielzahl von Geschäftsanwendungen runden das Bild ab. Sie alle tragen einen erheblichen Teil des Risikos, und das richtige Rahmenwerk für ihre Einstufung ist dasselbe risikobasierte Modell, das auch für die Patches des Betriebssystems gelten sollte: Schweregrad (CVSS), Ausnutzungsstatus (KEV-Listung, Threat-Intelligence-Feeds, öffentliche Exploits) und geschäftlicher Kontext (mit dem Internet verbunden, sensible Daten, Potenzial für laterale Bewegung). Weitere Informationen zur Einbindung dieses Rahmens in das übergeordnete Programm finden Sie unter „Best Practices für das Patch-Management“.
Bewährte Verfahren für das Patchen von Drittanbieter-Software: So erstellen Sie ein Programm
Ein funktionierendes Patch-Programm eines Drittanbieters folgt im Großen und Ganzen dem gleichen Ablauf wie der übergeordnete Patch-Management-Prozess, doch bei der Umsetzung in den einzelnen Phasen muss die zusätzliche Komplexität berücksichtigt werden, die durch die Software eines Drittanbieters entsteht.
Die Erfassung muss kontinuierlich, agentengesteuert und lückenlos erfolgen. Ein wöchentliches Software-Audit anhand des Bestandsverzeichnisses reicht nicht aus. Der Agent sollte jede installierte Anwendung, jede Version und jede vom Benutzer installierte Instanz auf jedem verwalteten Endpunkt erfassen und die Daten nahezu in Echtzeit aktualisieren. Wo immer diese Transparenz fehlt, ist das Patch-Programm genau in diesem Umfang blind.
Bei der Überwachung gilt dasselbe Prinzip. Sobald Sie wissen, welche Software installiert ist, benötigen Sie einen Feed, der Sie darüber informiert, wann die einzelnen Anbieter Sicherheitsupdates veröffentlichen – idealerweise nach Schweregrad geordnet. Einen solchen Feed für fünfzig Anbieter intern aufzubauen, ist eine ziemliche Herausforderung. Die realistische Lösung ist ein Patching-Tool, dessen Anbieter neue Versionen innerhalb weniger Stunden nach der Veröffentlichung durch den Hersteller in einen getesteten Katalog aufnimmt, sodass das Team nur einen Feed statt fünfzig nutzen muss.
Gerade bei der Priorisierung weichen Patches von Drittanbietern in der betrieblichen Praxis am häufigsten von den Betriebssystem-Patches ab. Die oben beschriebene Risikoeinstufung fließt direkt in Ihre SLA-Struktur ein, die ausdrücklich in Ihrer Patch-Management-Richtlinie festgeschrieben sein sollte. Eine Richtlinie, die Anwendungen von Drittanbietern namentlich nennt, diese Schweregraden mit festgelegten SLAs zuordnet und dokumentierte Ausnahmen vorschreibt, beseitigt die implizite Priorisierung nach dem Motto „zuerst das Betriebssystem, dann Drittanbieter“, die diese Lücke überhaupt erst entstehen lässt.
Das Testen unterscheidet sich grundlegend. Betriebssystem-Patches werden vor der Veröffentlichung von Microsoft, Apple oder dem jeweiligen Linux-Betreuer validiert. Patches von Drittanbietern werden vom ISV und im Idealfall durch die Katalog-Qualitätssicherung Ihrer Patching-Plattform validiert. Das verbleibende Risiko besteht in der Interaktion zwischen Anwendungen: ein Browser-Update, das das Rendering-Verhalten verändert und eine interne Web-App lahmlegt, ein Java-Runtime-Update, das Kompatibilitätsprobleme mit einem Branchen-Softwarepaket aufdeckt, oder ein Teams-Build, der eine benutzerdefinierte Integration beeinträchtigt. Ein kleiner Pilotring mit repräsentativen Endpunkten, bei dem routinemäßige Updates 24 bis 48 Stunden lang zurückgehalten werden und ein verkürzter Smoke-Test für aktiv ausgenutzte Schwachstellen durchgeführt wird, fängt das meiste davon ab, bevor es in die Produktion gelangt.
Bei der Bereitstellung wird das getestete Update innerhalb der von Ihnen festgelegten Wartungsfenster auf die übrigen Systeme der Infrastruktur übertragen, wobei für Endpunkte, die beim ersten Versuch offline waren, eine Wiederholungslogik zum Einsatz kommt und für den Fall von Fehlern Rollback-Pfade vorgesehen sind. Dies ist der Teil des Programms, bei dem bei manueller Ausführung die meisten Probleme sichtbar werden, da der Umfang die verfügbaren Stunden in Anspruch nimmt und die Ausnahmebehandlung die Routinearbeit verdrängt.
Die Überprüfung schließt den Kreis. Das für Sie relevante Compliance-Signal ist die installierte Version, nicht der Bereitstellungsstatus. Ein Bereitstellungsbericht kann den Status „gesendet“ anzeigen, während ein im Hintergrund aufgetretener Fehler beim Installationsvorgang dazu führt, dass die alte Version auf dem Gerät verbleibt. Erst die anwendungs- und gerätespezifische Überprüfung der aktuell ausgeführten Version gibt Aufschluss darüber, ob der Patch tatsächlich installiert wurde.
Die Berichterstellung erfolgt auf Anwendungsebene und nicht auf Geräteebene. Ein Gerät, auf dem zwar die aktuelle Chrome-Version installiert ist, Java jedoch drei Versionen hinterherhinkt, gilt in keiner Weise als konform, die ein Prüfer akzeptieren würde. Die Berichterstattung sollte nach Anwendung, Schweregrad und SLA-Verstoß gegliedert sein und die Aufschlüsselung nach Kunden enthalten, die MSPs für ihre kundenbezogenen Bescheinigungen benötigen.
Warum ein automatisiertes Patch-Management durch Drittanbieter unverzichtbar ist
Ohne diese Lösung geht die Rechnung nicht auf. Fünfzig Anwendungen von Drittanbietern, Dutzende von Releases pro Monat pro großem Anbieter, Hunderte oder Tausende von Endpunkten, nicht aufeinander abgestimmte Release-Rhythmen der Anbieter und SLAs, die für die Patches mit dem höchsten Risiko in Stunden gemessen werden. Kein Team wird das manuell im Griff behalten können – und diejenigen, die es versuchen, geraten zuerst bei der Software von Drittanbietern ins Hintertreffen, da dort die Kosten eines Rückstands im Tagesgeschäft am wenigsten sichtbar sind.
Das automatisierte Patch-Management entlastet das Team von Routineaufgaben: das Erkennen, dass eine Anwendung ein Update benötigt, das Abrufen des getesteten Pakets aus dem Katalog, die Bereitstellung per stiller Installation während des vereinbarten Wartungsfensters, die Abwicklung von Neustarts und die Wiederholung fehlgeschlagener Vorgänge. Menschen bleiben weiterhin in die Ausnahmebehandlung, die Genehmigung von Änderungsfenstern für sensible Systeme und den kleinen Prozentsatz an Anwendungen eingebunden, die tatsächlich manuelle Eingriffe erfordern.
Zwei Aspekte, die speziell die Automatisierung durch Drittanbieter betreffen, sollten besonders hervorgehoben werden, da ihnen in der allgemeinen Diskussion über Automatisierung nicht genügend Aufmerksamkeit geschenkt wird.
Der erste Punkt ist die Qualität des Katalogs. Die Automatisierung ist nur so gut wie der Anwendungskatalog, aus dem sie gespeist wird. Eine Plattform, die zwei Wochen benötigt, um ein kritisches Browser-Update bereitzustellen, hat während dieser Zeit denselben Sicherheitswert wie gar keine Plattform. Bei der Bewertung der Patch-Fähigkeiten eines Drittanbieters sollten folgende Fragen gestellt werden: Wie viele Anwendungen werden von Haus aus unterstützt, wie schnell spiegelt der Katalog neue Hersteller-Releases wider (insbesondere bei Sicherheitsupdates) und welche Qualitätssicherung wird bei jedem Paket durchgeführt, bevor es die Endgeräte in der Produktion erreicht?
Der zweite Punkt ist die Abhängigkeitsfläche. Ein schlechter Betriebssystem-Patch führt häufig dazu, dass das Betriebssystem nicht mehr funktioniert. Ein fehlerhafter Patch eines Drittanbieters führt häufig dazu, dass die davon abhängige Anwendung nicht mehr funktioniert – dabei kann es sich um einen geschäftskritischen Workflow, eine Integration oder ein Produktivitätswerkzeug handeln, das im gesamten Unternehmen genutzt wird. Die Maßnahmen zur Risikominderung sind dieselben wie bei jedem anderen Patch-Programm: Bereitstellungsringe, Wartezeiten, automatisierte Rollbacks. Die operative Fehlertoleranz ist jedoch geringer, da Nutzer einen Ausfall von Adobe Reader schneller bemerken als ein Kernel-Update.
Der Compliance-Aspekt
Compliance-Rahmenwerke geben nicht mehr vor, dass Software von Drittanbietern ein separates Thema sei. Die Anforderung 6.3.3 des PCI DSS 4.0 umfasst alle Systemkomponenten, darunter auch Anwendungen und nicht nur Betriebssysteme. Anhang A 8.8 der ISO 27001:2022 behandelt das Management technischer Schwachstellen ohne Ausnahmen. Die Sicherheitsvorschrift der HIPAA wurde in Durchsetzungsmaßnahmen so ausgelegt, dass sie das Patchen von Anwendungen als Teil „angemessener und geeigneter“ Sicherheitsmaßnahmen umfasst. NIS2, das in allen EU-Mitgliedstaaten gilt, verlangt den Nachweis einer zeitnahen Behebung von Schwachstellen, ohne dabei zwischen Betriebssystem und Anwendung zu unterscheiden. Das SOC-2-Kriterium CC7.1 für Trust Services umfasst die Überwachung und Behebung neuer Schwachstellen im gesamten System.
Die praktischen Auswirkungen sind in jedem Fall dieselben. Ein Audit, bei dem Ihr Patch-Programm überprüft wird und nicht verwaltete Browser, nicht gepatchte PDF-Reader oder Java-Laufzeitumgebungen am Ende ihrer Lebensdauer festgestellt werden, wird zu Beanstandungen führen – ganz gleich, wie einwandfrei Ihr Windows-Compliance-Bericht auch aussehen mag. Die Verteidigung gegen diese Beanstandung erfolgt durch operative Nachweise: anwendungsbezogene Compliance-Berichte, datierte Bereitstellungsaufzeichnungen, dokumentierte Ausnahmen und SLAs, die in der Praxis und nicht nur auf dem Papier eingehalten werden.
Wie Kaseya die Installation von Patches von Drittanbietern vereinfacht
Das Patchen von Anwendungen von Drittanbietern ist kein Wissensproblem. Jedes IT-Team und jeder MSP weiß, dass Anwendungen gepatcht werden müssen. Es handelt sich um ein operatives Problem, und dieses operative Problem ist struktureller Natur: mehr Anbieter, mehr Aktualisierungsrhythmen, mehr Installationsformate, eine größere Erfassungsfläche und ein Standard-Workflow, der das Patchen von Betriebssystemen bevorzugt, da sich dieses einfacher instrumentieren lässt.
Um diese Lücke zu schließen, muss man aufhören, Drittanbieter-Lösungen als parallele Programme zu behandeln, und sie in dasselbe Framework integrieren wie die bereits laufenden Prozesse. Gleiche Bestandsaufnahme. Gleiche Risikoeinstufung. Gleiche SLAs in der Richtlinie. Gleiche Bereitstellungsringe. Gleiche Automatisierung. Gleiche Compliance-Berichterstattung pro Anwendung. Die zugrunde liegenden Tools müssen einen geprüften Drittanbieter-Katalog in dem Rhythmus unterstützen, in dem die Anbieter tatsächlich neue Versionen veröffentlichen, aber das Programmdesign ist kein separates Programm. Es ist dasselbe Programm, in vollem Umfang.
Genau auf diesem Designprinzip basieren die RMM-Lösungen von Kaseya: Patches für Betriebssysteme, Drittanbieter-Software und Firmware werden über einen einzigen Agenten, ein einziges Richtlinien-Framework, ein einziges Wartungsfenster und eine einzige Compliance-Ansicht verwaltet. Das „Advanced Software Management“-Modul von Datto RMMist die genannte Drittanbieter-Funktion, die die Patch-Abdeckung auf über 200 sofort einsatzbereite Anwendungen erweitert – mit einem Katalog, der vor der Veröffentlichung auf Millionen von Geräten getestet wurde und kontinuierlich wächst.
Das Modul unterstützt zudem die Installation und Deinstallation von Anwendungen über dasselbe Richtlinien-Framework, wodurch eine Lücke geschlossen wird, die die meisten Patching-Tools offen lassen: Anwendungen, deren Lebenszyklus abgelaufen ist und die entfernt – und nicht nur aktualisiert – werden müssen, bevor sie ausgenutzt werden können. Für MSPs bedeutet dies eine Richtlinienkonfiguration und Compliance-Berichterstattung pro Kunde über eine einzige Konsole. Für interne IT-Teams ergibt sich daraus eine einheitliche Übersicht über den Patch-Status von Betriebssystemen und Drittanbieter-Software mit dem von Compliance-Rahmenwerken geforderten Prüfpfad – und zwar als Nebenprodukt des Arbeitsablaufs und nicht als vierteljährliche Maßnahme zur Beweissicherung.
Die Alternative besteht darin, eine dokumentierte Angriffsfläche ungeschützt zu lassen, während das Dashboard für Betriebssystem-Patches weiterhin „grün“ anzeigt. Genau diese Lücke nutzen Angreifer aus – und aktuelle Daten zu Exploits deuten darauf hin, dass sie damit Recht haben.
