Richtlinie zum Patch-Management: Warum Sie eine brauchen und wie Sie sie erstellen

Die meisten Richtlinien zum Patch-Management scheitern auf dieselbe Weise. Auf dem Papier sehen sie gut aus, liegen in einem SharePoint-Ordner, werden dem Prüfer einmal im Jahr vorgelegt und haben so gut wie nichts mit dem zu tun, was tatsächlich auf den Endgeräten geschieht. Die SLAs sind eher Wunschvorstellungen. In der Rollenliste ist jemand aufgeführt, der schon vor zwei Jahren das Unternehmen verlassen hat. Niemand kann Ihnen sagen, wann die Richtlinie zuletzt überprüft wurde – oder was sich geändert hat, falls dies der Fall war.

Eine Richtlinie zum Patch-Management soll das Dokument sein, das die Durchführung von Patches verbindlich vorschreibt. Sie legt fest, was gepatcht wird, wie schnell, von wem, mit welchen Ausnahmen und wie man nachweist, dass dies geschehen ist. Ist sie gut formuliert, überdauert sie Personalwechsel, erfüllt die Anforderungen von Audits und gibt dem Team eine Handhabe, wenn Geschäftsverantwortliche Einwände gegen ein Wartungsfenster erheben. Ist sie schlecht formuliert, dient sie lediglich als Alibi für die Einhaltung von Vorschriften.

Dieser Leitfaden behandelt die Inhalte einer funktionierenden Richtlinie zum Patch-Management, die SLAs, die den aktuellen Bedrohungslagen standhalten, sowie die Frage, wie das Dokument so strukturiert werden sollte, dass es durchsetzbar ist und nicht nur als Wunschvorstellung bleibt. Die RMM-Lösungen von Kaseya übernehmen für MSPs und interne IT-Teams das Patch-Management für Millionen von Endgeräten. Dadurch ergibt sich ein recht klares Bild davon, welche Richtlinienstrukturen in der Praxis befolgt und welche stillschweigend ignoriert werden.

Was ist eine patch management ?

Eine Richtlinie zum Patch-Management ist das maßgebliche Dokument, das festlegt, wie ein Unternehmen Software-Updates identifiziert, bewertet, bereitstellt und überprüft. Sie legt die Standards, Zeitpläne und Zuständigkeiten für das Patch-Management fest, während der Patch-Management-Prozess den täglichen Arbeitsablauf darstellt, mit dem diese Standards umgesetzt werden. (Wenn Sie zunächst die grundlegende Definition benötigen, bevor Sie weiterlesen, ist unser Leitartikel zum Patch-Management der richtige Ausgangspunkt.)

Diese Unterscheidung ist wichtig, da die meisten Teams beide Begriffe miteinander vermischen. Eine Richtlinie ist kein Runbook. Sie schreibt einem Techniker nicht vor, auf welche Schaltfläche er im RMM-Tool klicken soll. Sie legt dem Unternehmen fest, dass kritische Patches innerhalb eines definierten Zeitfensters installiert werden müssen, dass eine bestimmte Rolle dafür verantwortlich ist und dass Ausnahmen eine dokumentierte Genehmigung erfordern. Die Runbooks setzen die Richtlinie in die Praxis um. Die Richtlinie sorgt dafür, dass die operative Arbeit rechtlich vertretbar ist.

Warum brauchen wir eine Richtlinie zum Patch-Management?

Eine Richtlinie zum Patch-Management ist aus drei Gründen erforderlich, und zwar in etwa in dieser Reihenfolge nach Wichtigkeit:

Der erste Punkt ist die Durchsetzbarkeit. Ohne eine Richtlinie wird jede Patch-Bereitstellung zu einer Verhandlung. Anwendungsverantwortliche plädieren für Verzögerungen, Geschäftsbereiche wehren sich gegen Neustarts, und das Team, das die Patches verwaltet, verfügt über keine formelle Befugnis, sich darüber hinwegzusetzen. Eine von der Führungsebene verabschiedete Richtlinie gibt dem Patch-Team ein dokumentiertes Mandat.

Der zweite Punkt ist die Prüfung. Nahezu jedes moderne Compliance-Rahmenwerk verlangt einen dokumentierten Ansatz für die Installation von Patches, und Prüfer erwarten eine echte Richtlinie, keinen Platzhalter. PCI DSS 4.0 schreibt beispielsweise vor, dass Sicherheitspatches für kritische Systeme innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen. HIPAA verlangt „angemessene und geeignete“ technische Schutzmaßnahmen, was Prüfer als dokumentierte Patch-Installation mit messbaren Ergebnissen auslegen. ISO 27001:2002 Anhang A 8.8 befasst sich ausdrücklich mit dem Schwachstellenmanagement, dessen operatives Herzstück das Patchen ist. NIS2, das EU-weit gilt, verlangt von betroffenen Organisationen den Nachweis des Umgangs mit Schwachstellen. SOC 2 Trust Services Criteria CC7.1 verlangt die Überwachung und Behebung neuer Schwachstellen. Keine dieser Vorschriften akzeptiert „wir patchen, wenn wir können“ als Antwort.

Der dritte Punkt ist Kontinuität. Mitarbeiter wechseln, Tools ändern sich, Prioritäten verschieben sich. Eine schriftlich festgehaltene Richtlinie ermöglicht es einem neuen IT-Leiter, ein Patch-Programm zu übernehmen, ohne es von Grund auf neu aufbauen zu müssen.

Der Compliance-Fall im Detail

Es lohnt sich, genau zu formulieren, was die wichtigsten Rahmenwerke verlangen, denn durch vage Zusammenfassungen verfehlen Richtlinien oft die Anforderungen, die bei Prüfungen abgefragt werden.

PCI DSS 4.0 schreibt vor, dass kritische Sicherheitspatches auf den betroffenen Systemen innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen, wobei für nicht kritische Patches ein dokumentierter risikobasierter Ansatz anzuwenden ist. Mit der Version 4.0 wurden strengere Anforderungen an die risikobasierte Priorisierung eingeführt, was bedeutet, dass ein rein auf dem CVSS basierender Ansatz einen strengen Prüfer möglicherweise nicht mehr zufriedenstellt.

Die HIPAA-Sicherheitsvorschrift legt zwar keine konkreten Fristen fest, verpflichtet die betroffenen Einrichtungen jedoch dazu, „Verfahren zum Schutz vor, zur Erkennung und zur Meldung von Schadsoftware einzuführen“ und „Sicherheitsmaßnahmen zu ergreifen, die ausreichen, um Risiken und Schwachstellen auf ein angemessenes und geeignetes Maß zu reduzieren“. In der Praxis haben die Durchsetzungsmaßnahmen des HHS OCR mehrmonatige Verzögerungen bei der Behebung bekannter Schwachstellen als Verstoß gegen die Sicherheitsvorschrift gewertet.

ISO 27001:2022 Anhang A 8.8 (Management technischer Schwachstellen) schreibt vor, dass Informationen über technische Schwachstellen zeitnah eingeholt, die Risiken für die Organisation bewertet und geeignete Maßnahmen ergriffen werden müssen. Auditoren erwarten eine schriftliche Richtlinie, festgelegte SLAs und Nachweise für die Umsetzung.

Die NIS2-Richtlinie verpflichtet wesentliche und wichtige Einrichtungen in kritischen Sektoren der EU, Schwachstellen und Offenlegungen zu behandeln. Die Umsetzung in den einzelnen Mitgliedstaaten variiert im Detail, doch wird durchweg erwartet, dass Patches dokumentiert und mit messbaren Reaktionszeiten durchgeführt werden.

Das SOC 2 Trust Services-Kriterium CC7.1 verlangt von der Organisation, Sicherheitsvorfälle und Schwachstellen zu erkennen und darauf zu reagieren. Eine Richtlinie zum Patch-Management gehört zu den Standardnachweisen, die von den Prüfern überprüft werden.

Der NIST CSF 2.0 sieht unter der Funktion „Protect“ (PR.PS-02) vor, dass Software entsprechend dem Risiko gewartet, ersetzt und entfernt wird, was in der Praxis ein dokumentiertes Patch-Management bedeutet.

Wenn Sie eine Richtlinie in erster Linie erstellen, um ein Audit zu bestehen, sollten Sie sich dabei an den strengsten Vorgaben orientieren, denen Sie unterliegen. Die übrigen Anforderungen ergeben sich dann von selbst.

Bestandteile einer funktionierenden Richtlinie zum Patch-Management

Eine Richtlinie zum Patch-Management umfasst etwa zehn Abschnitte. Manche Vorlagen gliedern oder fassen diese Abschnitte anders auf, doch der Inhalt bleibt derselbe. Das Auslassen eines dieser Abschnitte führt zu einer Lücke, die ein Prüfer aufdecken wird.

1. Zweck und Geltungsbereich

Geben Sie an, wozu die Richtlinie dient und was sie abdeckt. Der Zweck lässt sich in ein oder zwei Sätzen zusammenfassen: Diese Richtlinie gewährleistet die rechtzeitige Erkennung, Bewertung und Bereitstellung von Software-Updates, um Sicherheit, Stabilität und die Einhaltung von Vorschriften zu gewährleisten. Der Geltungsbereich ist wichtiger und wird häufiger übersehen. Er muss Folgendes festlegen:

• Welche Ressourcen durch die Richtlinie abgedeckt sind (Server, Workstations, Laptops, mobile Geräte, virtuelle Maschinen, Container, Netzwerkgeräte, IoT, Firmware)
• Welche Arten von Software (Betriebssysteme, Anwendungen, Software von Drittanbietern, Firmware)
• Welche Umgebungen (Produktion, Staging, Entwicklung, ggf. BYOD)
• Welche Akteure (Mitarbeiter, Auftragnehmer, von Dritten verwaltete Systeme)

Lücken im Anwendungsbereich sind die Ursache für Prüfungsfeststellungen. Wenn die Richtlinie Netzwerk-Firmware oder Anwendungen von Drittanbietern nicht ausdrücklich abdeckt, kann das Team endlos darüber diskutieren, ob dies überhaupt vorgesehen war.

2. Aufgaben und Zuständigkeiten

Jeder Abschnitt der Richtlinie sollte einer benannten Rolle zugeordnet sein. Allgemeine Richtlinien verwenden allgemeine Rollen; wirksame Richtlinien benennen konkrete Funktionen und legen fest, wofür jede einzelne verantwortlich ist. Eine praktikable Struktur:

• Verantwortlicher für das Patch-Management (in der Regel der CISO oder IT-Leiter). Ist für die Richtlinie verantwortlich. Genehmigt Ausnahmen. Prüft die Compliance-Berichte. Letzte Eskalationsinstanz.
• Leiter des Patch-Management-Teams (ein IT-Betriebs- oder Sicherheitsmanager). Ist für das operative Programm verantwortlich. Legt den Zeitplan für die Patch-Installation fest. Koordiniert die Maßnahmen mit den Anwendungsverantwortlichen.
• Systemadministratoren. Führen Sie Patches auf den ihnen zugewiesenen Systemen durch. Verwalten Sie Testringe. Führen Sie bei Bedarf Rollbacks durch.
• Anwendungsverantwortliche. Identifizieren Sie geschäftskritische Anwendungen. Genehmigen Sie Wartungsfenster. Überprüfen Sie die Funktionsfähigkeit nach der Installation von Patches.
• Sicherheitsteam. Überwachung von Bedrohungsinformationen. Kennzeichnung dringender Sicherheitslücken. Verfolgung von CISA-KEV-Einträgen und Ransomware-relevanten CVEs. Überprüfung der Compliance.
• Anlagenverantwortliche. Führen Sie ein genaues Verzeichnis der in ihrer Verantwortung befindlichen Anlagen.
• Endnutzer. Halten Sie sich an die Neustartpläne. Deaktivieren Sie die Patch-Agenten nicht. Melden Sie Probleme im Zusammenhang mit Patches.

Namen ändern sich, Rollen bleiben bestehen. In der Richtlinie sind die Rollen aufgeführt; ein Anhang enthält eine Zuordnung zu den derzeitigen Personen, falls Ihre Governance-Vorgaben dies erfordern.

3. Patch-Klassifizierung und SLAs

Dies ist der wichtigste Abschnitt, und genau hier sind die meisten Richtlinien gefährlich veraltet. Die Zeitpläne für Bedrohungen, auf denen die fünf Jahre alten Vorlagen basieren, sind nicht mehr zutreffend.

Bei der Klassifizierung werden Patches nach Schweregrad und Ausnutzbarkeit unterteilt, und jede Stufe wird mit einer SLA für die Bereitstellung verknüpft. Ein tragfähiges Modell für 2026 sieht wie folgt aus:

• Dringlichkeit: „Emergency“/aktiv ausgenutzt. Eine im CISA-KEV-Katalog aufgeführte Sicherheitslücke mit einem veröffentlichten Exploit auf einem betroffenen System. Umsetzung innerhalb von 24 bis 48 Stunden. Außerplanmäßige Veröffentlichung, verkürzte Testphase, Neustart erforderlich.
• Kritisch. CVSS 9,0 oder höher oder jede Sicherheitslücke auf Systemen mit Internetanbindung, unabhängig vom CVSS-Wert. Bereitstellung innerhalb von 7 bis 14 Tagen. Standardtests, planmäßige Bereitstellung.
• Hoch. CVSS 7,0 bis 8,9, auf internen Systemen, keine aktive Ausnutzung. Innerhalb von 30 Tagen umsetzen.
• Mittlere Schwere. CVSS 4.0 bis 6.9. Umsetzung innerhalb von 60 bis 90 Tagen, in der Regel im Rahmen der routinemäßigen Zyklen.
• Gering. CVSS unter 4,0. Im Rahmen der regulären Wartung bereitstellen, kein separates SLA erforderlich.

Der Grund für diese verkürzten Zeiträume liegt darin, dass sich die Bedrohungslage verschärft hat. Die Analyse von VulnCheck für das erste Halbjahr 2025 ergab, dass 32,1 % der in der KEV-Liste aufgeführten Schwachstellen innerhalb von 24 Stunden nach ihrer Offenlegung oder sogar schon vorher ausgenutzt wurden – ein Anstieg gegenüber 23,6 % im Vorjahr. Eine Richtlinie, die 30 Tage Zeit für das Patchen von Systemen mit Internetanbindung vorsieht, lässt nach aktuellem Stand der Bedrohungslage wochenlange bekannte Exposition gegenüber aktiv ausgenutzten Schwachstellen zu.

Insbesondere bei Systemen mit Internetanbindung gelten für viele etablierte Programme strengere Service-Level-Vereinbarungen (SLA) als in der obigen Tabelle angegeben. Verizons DBIR 2025 erfasste 17 Schwachstellen von Edge-Geräten auf der KEV-Liste und stellte fest, dass die mittlere Zeit bis zur vollständigen Behebung bei fünf Fällen 209 Tage betrug, während Angreifer diese Schwachstellen massenhaft ausnutzten. Eine Richtlinie, die diese Lücke nicht berücksichtigt, basiert auf einer veralteten Sichtweise.

Unabhängig davon, welche SLAs Sie festlegen: Geben Sie die Fristen in Werktagen an, legen Sie fest, wann die Frist beginnt (Veröffentlichung durch den Anbieter, Aufnahme in die KEV-Liste oder Ihre Erkennung?), und definieren Sie, was unter „gepatcht“ zu verstehen ist (installiert und überprüft, nicht nur an die Verwaltungskonsole gesendet).

4. Anforderungen an die Bestandsaufnahme der Vermögenswerte

Die Richtlinie sollte eine kontinuierliche, automatisierte Bestandsaufnahme aller betroffenen Ressourcen vorschreiben, wobei namentlich festgelegte Verantwortlichkeiten für die Richtigkeit der Bestandsdaten bestehen müssen. Legen Sie die Mindestdaten fest, die pro Ressource erfasst werden müssen (Hostname, Betriebssystem, Version, Patch-Stand, Eigentümer, Zeitpunkt der letzten Überprüfung), die Häufigkeit, mit der die Bestandsdaten abgeglichen werden, sowie den Schwellenwert, unterhalb dessen das Programm als nicht konform mit seinen eigenen Vorgaben gilt. Die meisten Richtlinien lassen diesen Punkt aus und können dann nicht erklären, warum ein Host sechs Monate lang nicht gepatcht wurde. Der Grund ist immer derselbe: Niemand wusste, dass er existierte.

5. Standards für Patch-Tests und die Bereitstellung

Legen Sie fest, wie Patches vor einer flächendeckenden Bereitstellung getestet werden. Die Richtlinie schreibt keine technischen Details vor, sondern legt lediglich die Anforderungen fest. Ein praktikabler Standard:

• Routine-Patches durchlaufen eine festgelegte Ringstruktur (Pilotphase, Validierung, Produktion) mit Wartezeiten zwischen den einzelnen Phasen.
• Notfall-Patches folgen einer gestaffelten Ringstruktur (Smoke-Test in einem repräsentativen Pilotprojekt, anschließend flächendeckende Einführung) mit dokumentierter Risikoakzeptanz.
• Patches, die geschäftskritische Systeme betreffen, bedürfen vor der Bereitstellung in der Produktionsumgebung der ausdrücklichen Genehmigung durch den Anwendungsverantwortlichen.
• Durch Patches erforderliche Neustarts werden in genehmigten Wartungsfenstern geplant, außer in Notfällen, in denen die SLA Vorrang vor dem Zeitfenster hat.
• Fehlgeschlagene Bereitstellungen lösen einen automatischen Wiederholungsversuch aus; sollte auch der zweite Versuch fehlschlagen, wird eine Benachrichtigung an das Patching-Team gesendet.

Der Grund dafür, dass diese als Standards und nicht als Verfahren formuliert sind, liegt darin, dass das operative Team Werkzeuge und Vorgehensweisen anpassen kann, ohne die Richtlinie neu schreiben zu müssen. Solange der Standard eingehalten wird, kann sich die Umsetzung weiterentwickeln. Weitere Einzelheiten dazu, wie Teams diese Phasen konkret umsetzen, finden Sie in unserem Leitfaden zum Patch-Management-Prozess, in dem jede einzelne Phase genau erläutert wird.

6. Ausnahmebehandlung und Risikoakzeptanz

In jeder Umgebung gibt es Systeme, die nicht termingerecht gepatcht werden können. Altanwendungen, die unter neueren Bibliotheken nicht mehr funktionieren. Hersteller-Appliances mit Wartungsvertrag, der die Updates regelt. Air-Gapped-Systeme mit eigenen Änderungsfenstern. Die Richtlinie benötigt einen festgelegten Ausnahmeprozess und keine stillschweigende Übereinkunft, dass „wir schon eine Lösung finden werden“.

Eine funktionierende Ausnahmeregelung umfasst:

• Ein Formular für einen dokumentierten Ausnahmeantrag (Anlage, Schwachstelle, Grund, Ausgleichsmaßnahmen, Verantwortlicher, Ablaufdatum)
• Ein festgelegter Genehmiger (in der Regel die für das Patch-Management zuständige Stelle bei zeitlich begrenzten Ausnahmen, mit Überprüfung durch das Sicherheitsteam)
• Eine maximale Ausnahmedauer (90 Tage sind ein angemessener Standardwert, wobei eine Verlängerung eine erneute Prüfung erfordert)
• Eine Anforderung an Ausgleichsmaßnahmen (Netzwerksegmentierung, zusätzliche Überwachung, virtuelles Patching) für jede Ausnahme, die über das ursprüngliche SLA hinausgeht
• Ein zentrales Ausnahmeregister, das vierteljährlich überprüft und jährlich in einem Bericht erfasst wird

Dieser Abschnitt ist deshalb so wichtig, weil der Ausnahmeprozess ohne ihn darin besteht, dass „das Team aufgibt und weitermacht“. Das führt dazu, dass Systeme jahrelang mit bekannten Schwachstellen betrieben werden, ohne dass festgehalten wird, warum dies geschieht.

7. Berichterstattung und Überprüfung der Einhaltung von Vorschriften

Legen Sie fest, was, an wen und wie oft berichtet wird. Eine nachvollziehbare Berichtsstruktur:

• Betriebs-Dashboards. Echtzeit-Patch-Compliance nach Asset-Gruppe, die dem Patch-Team jederzeit zur Verfügung steht.
• Monatsberichte. Prozentsatz der Patch-Konformität, SLA-Einhaltungsquote, Anzahl der Ausnahmen, durchschnittliche Zeit bis zur Patch-Installation. Geprüft vom Leiter des Patch-Management-Teams und der zuständigen Stelle.
• Vierteljährliche Überprüfungen. Trendanalysen, Berichterstattung über neue Bedrohungen, Überprüfung des Ausnahmeregisters, Wirksamkeit der Richtlinien. Präsentation vor der Sicherheitsleitung.
• Jahresbericht. Überblick über die Compliance-Situation im Gesamtjahr, Zusammenfassung der Rahmenbedingungen, Lücken und Abhilfemaßnahmen. Wird der Geschäftsleitung und den externen Wirtschaftsprüfern vorgelegt.

Die Meldepflicht ist oft der Bereich, in dem Prüfungsfeststellungen am leichtesten vorhersehbar sind. Wenn die Richtlinie vorschreibt, dass vierteljährliche Überprüfungen stattfinden, Sie aber keine Protokolle der letzten vier vorlegen können, ist das die Feststellung.

8. Einbindung des Änderungsmanagements

Patching und Änderungsmanagement überschneiden sich. Die Richtlinie sollte festlegen, wie sich das Patching in den übergeordneten Änderungsmanagementprozess einfügt: Was gilt als Standardänderung (vorab genehmigte Patch-Typen, die in festgelegten Zeitfenstern bereitgestellt werden), was als normale Änderung (einmalige oder außerplanmäßige Bereitstellungen) und was als Notfalländerung (Reaktion auf aktive Sicherheitslückenausnutzung). Das ist kein bürokratischer Aufwand. So verhindert das Patching-Team, dass es von einem Change Board blockiert wird, das wöchentlich tagt, während die Zeit bis zur Bedrohung nur noch in Stunden gemessen wird.

9. Anforderungen an die Automatisierung

Moderne Richtlinien sollten die Automatisierung ausdrücklich vorschreiben, wo dies machbar ist. Die Formulierung ist entscheidend: nicht „Automatisierung wird empfohlen“, sondern „das Patch-Programm nutzt automatisierte Tools für die Erkennung, Überprüfung, Bereitstellung und Berichterstellung, wobei manuelle Eingriffe auf dokumentierte Ausnahmen beschränkt bleiben.“

Die Gründe hierfür sind operativer und sicherheitstechnischer Natur. Manuelles Patchen in Unternehmen, die mehr als ein paar Dutzend Endgeräte umfassen, führt zu Inkonsistenzen und Verzögerungen. Eine Automatisierung mit geeigneten Sicherheitsvorkehrungen ist schneller, konsistenter und besser zu rechtfertigen. Eine ausführlichere Erörterung der Frage, was automatisiert und was manuell durchgeführt werden sollte, finden Sie in unserem Blogbeitrag zum automatisierten Patch-Management. Für die Festlegung von Richtlinien reicht diese Anforderung aus.

10. Überprüfung der Richtlinien und Versionskontrolle

Legen Sie einen Überprüfungsrhythmus fest und halten Sie sich daran. Eine jährliche Überprüfung ist das Minimum; eine vierteljährliche Überprüfung ist angebracht, wenn sich die Bedrohungslage oder die Compliance-Anforderungen wesentlich ändern. Die Richtlinie sollte Folgendes festlegen:

• Überprüfungshäufigkeit (in der Regel jährlich)
• Auslöser für außerplanmäßige Überprüfungen (wesentliche Änderungen am Rahmenwerk, schwerwiegende Sicherheitsvorfälle, organisatorische Umstrukturierungen)
• Anforderungen an die Versionskontrolle (jede Version mit Datumsangabe, Zusammenfassung der Änderungen, Aufbewahrung früherer Versionen)
• Genehmigungsinstanz für Richtlinienänderungen (in der Regel dieselbe Stelle, die die ursprüngliche Richtlinie genehmigt hat)

Eine Richtlinie ohne Versionshistorie ist eine Richtlinie, die niemand überwacht.

Mustervorlage für eine Richtlinie zum Patch-Management

Hier ist ein grober Entwurf, der sich an den zehn oben genannten Abschnitten orientiert. Es handelt sich nicht um ein fertiges Dokument, sondern um eine Struktur, an die konkrete Inhalte angehängt werden können.

VORLAGE FÜR EINE RICHTLINIE ZUM PATCH-MANAGEMENT

1. Zweck

2. Geltungsbereich

   2.1 Erfasste Vermögenswerte

   2.2 Betroffene Softwaretypen

   2.3 Betroffene Umgebungen

   2.4 Nicht erfasste Vermögenswerte und Ausschlüsse

3. Aufgaben und Zuständigkeiten

   3.1 Zuständigkeit für das Patch-Management

   3.2 Leiter des Patch-Management-Teams

   3.3 Systemadministratoren

   3.4 Anwendungsverantwortliche

   3.5 Sicherheitsteam

   3.6 Vermögensinhaber

   3.7 Endnutzer

4. Patch-Klassifizierung und SLAs

   4.1 Einstufung nach Schweregrad

   4.2 SLAs für die Bereitstellung nach Schweregrad

   4.3 SLAs für internetgestützte Systeme

   4.4 Kriterien für Notfallmaßnahmen

5. Bestandsaufnahme der Vermögenswerte

   5.1 Anforderungen an Bestandsdaten

   5.2 Häufigkeit der Abstimmung

   5.3 Deckungsgrenzen

6. Patch-Tests und Bereitstellung

   6.1 Prüfanforderungen

   6.2 Struktur des Bereitstellungsrings

   6.3 Wartungsfenster

   6.4 Neustartverwaltung

   6.5 Umgang mit fehlgeschlagenen Bereitstellungen

7. Ausnahmebehandlung

   7.1 Verfahren zur Beantragung einer Ausnahmegenehmigung

   7.2 Genehmigungsbehörde

   7.3 Laufzeit und Verlängerung der Ausnahmegenehmigung

   7.4 Ausgleichsregelungen

   7.5 Ausnahmeregister und Überprüfung

8. Berichterstattung und Einhaltung von Vorschriften

   8.1 Operatives Berichtswesen

   8.2 Monatliche Compliance-Berichte

   8.3 Vierteljährliche Überprüfungen

   8.4 Jährlicher Compliance-Bericht

   8.5 Rahmenabgleich

9. Integration des Änderungsmanagements

   9.1 Einstufung von Änderungen in Standard-, Normal- und Notfalländerungen

   9.2 Interaktion mit dem Beirat

10. Automatisierung

   10.1 Erforderlicher Automatisierungsumfang

   10.2 Kriterien für manuelle Eingriffe

11. Policy Governance

   11.1 Häufigkeit der Überprüfungen

   11.2 Auslösebedingungen für eine außerplanmäßige Überprüfung

   11.3 Versionskontrolle

   11.4 Genehmigungsbefugnis

Anhänge

A. Abgleich von Compliance-Rahmenwerken (PCI DSS, HIPAA, ISO 27001, NIS2, SOC 2)

B. Rollen für namentlich genannte Personen (aktuell)

C. Ausnahmeregister

D. Glossar

E. Änderungshistorie

In den Anhängen wird die Richtlinie auf dem neuesten Stand gehalten, ohne dass das Hauptdokument ständig überarbeitet werden muss. Namen, Rahmenbedingungen und Ausnahmen ändern sich. Die strukturellen Grundsätze sollten dies jedoch nicht.

Wie eine Richtlinie mit dem übergeordneten Patch-Programm zusammenhängt

Eine Richtlinie ist die übergeordnete Ebene, die die operative Arbeit regelt. Sie schreibt SLAs vor, ohne ein bestimmtes Tool vorzuschreiben. Sie verlangt Tests, ohne die Ringstruktur vorzugeben. Sie legt die Häufigkeit der Berichterstattung fest, ohne die Dashboards zu entwerfen.

In einem gut funktionierenden Programm ist die Richtlinie das Dokument, das den Patch-Management-Prozess unabhängig von Personalwechseln und Änderungen bei den eingesetzten Tools wiederholbar macht. Es ist auch das Dokument, das dafür sorgt, dass Best Practices im Patch-Management nicht nur als Wunschvorstellung bleiben, sondern auch umgesetzt werden. Ein Team kann zwar als Best Practice beschließen, Patches für internetgebundene Systeme schneller zu priorisieren, doch wenn die Richtlinie dies nicht vorschreibt, verschwindet diese Vorgehensweise stillschweigend, sobald das Team das nächste Mal unter Druck steht.

In der Richtlinie wird Automatisierung zudem nicht nur toleriert, sondern verbindlich vorgeschrieben. In Organisationen, in denen Automatisierung nicht offiziell in der Richtlinie verankert ist, muss jeder neue Systemadministrator erneut darüber diskutieren, ob Automatisierung „sicher“ oder „angemessen“ ist, und die daraus resultierende Abweichung untergräbt das Programm im Laufe der Jahre. Eine Richtlinie, die Automatisierung als Standard festlegt und Ausnahmen dokumentiert, beendet diese Debatte.

Bewährte Patch management

Eine Richtlinie zum Patch-Management ist eines der wirkungsvollsten Governance-Dokumente, über die eine IT- oder Sicherheitsorganisation verfügt. Ist sie gut umgesetzt, verleiht sie dem Patch-Team die nötige Handlungsbefugnis, liefert den Prüfern Nachweise, schafft Klarheit für das Unternehmen und gewährleistet die Kontinuität des Programms. Ist sie schlecht umgesetzt, ist sie ein SharePoint-Dokument, über dessen Existenz sich zwar alle einig sind, das aber niemand wirklich befolgt.

Die Richtlinien, die sich bewährt haben, weisen einige gemeinsame Merkmale auf. Sie sind in ihrem Anwendungsbereich konkret formuliert und nicht nur als Zielvorstellung gedacht. Ihre SLAs spiegeln die aktuellen Bedrohungslagen wider und nicht Vorlagen von vor fünf Jahren. Sie benennen Rollen und nicht einzelne Personen. Sie machen Ausnahmen zu einem dokumentierten Prozess und nicht zu einer stillschweigenden Umgehungslösung. Sie schreiben Automatisierung vor, anstatt manuelle Ausuferungen zu tolerieren. Und sie werden in regelmäßigen Abständen überprüft, was durch eine Versionskontrolle belegt wird.

Wenn Sie eine Richtlinie von Grund auf neu erstellen, orientieren Sie sich an der oben genannten Struktur mit zehn Abschnitten und verfassen Sie jeden Abschnitt unter Berücksichtigung der strengsten Compliance-Vorgaben, denen Sie unterliegen. Wenn Sie eine bestehende Richtlinie aktualisieren, beginnen Sie mit den SLAs. Diese sind am ehesten unbemerkt veraltet und haben den unmittelbarsten Einfluss darauf, ob die Richtlinie noch immer widerspiegelt, wie das Programm funktionieren sollte. Von dort aus kann der Rest des Dokuments Abschnitt für Abschnitt auf den neuesten Stand gebracht werden.

Wie Kaseya helfen kann

Eine Richtlinie ist nur dann durchsetzbar, wenn Ihre Tools tatsächlich umsetzen und nachweisen können, was die Richtlinie vorschreibt. Genau hier scheitern die meisten Patch-Programme: Im Dokument steht, dass kritische Patches innerhalb von 14 Tagen bereitgestellt werden müssen, doch das Tool kann Ihnen nicht sagen, welche Patches im letzten Monat die SLA-Frist verpasst haben – und diese Lücke wird bei der Prüfung sichtbar.

Die RMM-Lösungen von Kaseya sind darauf ausgelegt, die Patch-Verwaltung an die betrieblichen Anforderungen anzupassen, die sich aus einer strengen Patch-Richtlinie ergeben. Die kontinuierliche Erfassung von Assets speist die Bestandsliste. Richtliniengesteuertes Scannen und Bereitstellen verwandeln Klassifizierung und SLAs in automatisierte Arbeitsabläufe, anstatt sie in Tabellenkalkulationen zu erledigen. Die integrierte Abdeckung von Drittanbieteranwendungen schließt die Lücke im Anwendungsbereich, die in den meisten Richtlinien zwar vorgesehen ist, von den meisten Tools jedoch nicht abgedeckt wird. Ausnahmebehandlung, Bereitstellungsringe und Rollback sind vollwertige Funktionen und nicht nur benutzerdefinierte Skripte.

Für interne IT-Teams bedeutet dies eine Richtlinie, die sie erstellen, verbindlich vorschreiben und deren Einhaltung nachweisen können, ohne manuell Nachweise sammeln zu müssen. Für MSPs, die Richtlinien für mehrere Kunden verwalten, erweitert Datto RMM das Modell um kundenbezogene Patch-Richtlinien, kundenbezogene SLA-Berichte und die Art von Nachweisen, die den Prüfer eines Kunden zufriedenstellen, ohne dass für jeden Auftrag ein individueller Bericht erstellt werden muss.

Der entscheidende Punkt ist die operative Umsetzung. Eine Richtlinie, die von der Lösung nicht durchgesetzt werden kann, ist lediglich ein Dokument. Eine Richtlinie, die von der Lösung durchgesetzt, überwacht und deren Einhaltung gemeldet wird, ist eine Kontrollmaßnahme.