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 keinen Bezug zu dem, 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 nachgewiesen wird, dass dies geschehen ist. Wenn sie gut formuliert ist, ü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 Bedrohungsentwicklungen 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 Richtlinie zum 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 muss. Sie legt dem Unternehmen fest, dass kritische Patches innerhalb eines definierten Zeitfensters bereitgestellt werden müssen, dass eine bestimmte Rolle dafür verantwortlich ist und dass Ausnahmen eine dokumentierte Freigabe 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 und 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 von Prüfern als dokumentierte Patch-Verfahren mit messbaren Ergebnissen interpretiert wird. ISO 27001:2002, Anhang A 8.8, befasst sich ausdrücklich mit dem Schwachstellenmanagement, dessen operatives Herzstück das Patching ist. NIS2, das EU-weit gilt, verlangt von den betroffenen Organisationen den Nachweis des Umgangs mit Schwachstellen. Das SOC-2-Kriterium CC7.1 für Trust Services schreibt die Überwachung und Behebung neuer Schwachstellen vor. Keine dieser Vorschriften akzeptiert „Wir patchen, wenn wir können“ als Antwort.

Der dritte Punkt ist die Kontinuität. Mitarbeiter wechseln, Tools ändern sich, Prioritäten verschieben sich. Eine schriftlich festgelegte 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 beschreiben, was die wichtigsten Rahmenwerke vorschreiben, denn durch vage Zusammenfassungen kommt es häufig dazu, dass Richtlinien die Anforderungen verfehlen, die bei Audits geprüft 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, während für nicht kritische Patches ein dokumentierter risikobasierter Ansatz anzuwenden ist. Mit der Version 4.0 wurden strengere Anforderungen hinsichtlich der risikobasierten Priorisierung eingeführt, was bedeutet, dass ein ausschließlich auf dem CVSS-Wert basierender Ansatz für einen strengen Prüfer möglicherweise nicht mehr ausreichend ist.

Die HIPAA-Sicherheitsvorschrift legt 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, das Risiko für die Organisation bewertet und geeignete Maßnahmen ergriffen werden müssen. Auditoren erwarten eine schriftliche Richtlinie, festgelegte SLAs und Nachweise über die Umsetzung.

Die NIS2-Richtlinie verpflichtet wesentliche und wichtige Einrichtungen in kritischen Sektoren der EU, Schwachstellen zu beheben und Offenlegungen zu handhaben. 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-Kriterium „Trust Services“ 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.

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 eine Prüfung zu bestehen, orientieren Sie sich dabei an den strengsten Vorgaben, 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 diese Abschnitte anders auf oder fassen sie anders zusammen, doch der Inhalt bleibt derselbe. Wird einer dieser Abschnitte ausgelassen, entsteht eine 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 Police 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 Prüfungsumfang 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 Patch-Installationen auf den ihnen zugewiesenen Systemen durch. Verwalten Sie Testumgebungen. Führen Sie bei Bedarf Rollbacks durch.
• Anwendungsverantwortliche. Identifizieren Sie geschäftskritische Anwendungen. Genehmigen Sie Wartungsfenster. Überprüfen Sie die Funktionalität nach der Installation von Patches.
• Sicherheitsteam. Überwachung von Bedrohungsinformationen. Kennzeichnung dringender Sicherheitslücken. Verfolgung der CISA-KEV-Listen und der für Ransomware relevanten CVEs. Überprüfung der Compliance.
• Anlagenbesitzer. Führen Sie ein genaues Verzeichnis der in ihrem Besitz befindlichen Anlagen.
• Endbenutzer. Halten Sie sich an die Neustartzeitplä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 dies im Rahmen Ihrer Governance erforderlich ist.

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 basierten, treffen nicht mehr zu.

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

• Notfall/aktiv ausgenutzt. Eine im CISA-KEV-Katalog aufgeführte Sicherheitslücke mit einem veröffentlichten Exploit auf einem betroffenen System. Bereitstellung innerhalb von 24 bis 48 Stunden. Außerplanmäßige Veröffentlichung, verkürzte Testphase, Neustart zwingend 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, betrifft interne Systeme, keine aktive Ausnutzung. Innerhalb von 30 Tagen umsetzen.
• Mittel. 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 verändert 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 – für Angriffe genutzt wurden; im Vorjahr lag dieser Anteil noch bei 23,6 %. Eine Richtlinie, die 30 Tage Zeit für das Patchen von Systemen mit Internetanbindung vorsieht, lässt nach aktuellem Stand der Bedrohungslage eine wochenlange bekannte Gefährdung durch aktiv ausgenutzte Schwachstellen zu.

Insbesondere bei Systemen mit Internetanbindung gelten für viele ausgereifte Programme strengere SLAs als in der obigen Tabelle angegeben. Der DBIR 2025 von Verizon erfasste 17 Schwachstellen in Edge-Geräten auf der KEV-Liste und stellte fest, dass die mediane Zeit bis zur vollständigen Behebung bei fünf Fällen, in denen Angreifer die Schwachstellen massenhaft ausnutzten, 209 Tage betrug. Eine Richtlinie, die diese Lücke nicht berücksichtigt, basiert auf einer statischen Weltanschauung.

Unabhängig davon, welche SLAs Sie festlegen: Geben Sie diese 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 (bereitgestellt 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 Genauigkeit der Bestandsaufnahme bestehen müssen. Legen Sie die Mindestdaten fest, die pro Ressource erfasst werden müssen (Hostname, Betriebssystem, Version, Patch-Stand, Eigentümer, letzter Check-in), die Häufigkeit, mit der die Bestandsaufnahme abgeglichen wird, sowie den Schwellenwert, unterhalb dessen das Programm als nicht konform mit den eigenen Vorgaben gilt. Die meisten Richtlinien lassen diesen Punkt außer Acht und können dann nicht erklären, warum ein Host sechs Monate lang nicht gepatcht wurde. Der Grund ist immer derselbe: Niemand wusste, dass es ihn gab.

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:

• Routinemäßige Patches durchlaufen eine festgelegte Ringstruktur (Pilotphase, Validierungsphase, Produktionsphase) mit Wartezeiten zwischen den einzelnen Ringen.
• Notfall-Patches folgen einer komprimierten Ringstruktur (Smoke-Test in einem repräsentativen Pilotprojekt, anschließend breit angelegte Einführung) mit dokumentierter Risikoakzeptanz.
• Patches, die geschäftskritische Systeme betreffen, bedürfen vor der Bereitstellung in der Produktionsumgebung der ausdrücklichen Freigabe durch den Anwendungsverantwortlichen.
• Durch Patches erforderliche Neustarts werden in genehmigten Wartungsfenstern eingeplant, außer in Notfällen, in denen die SLA Vorrang vor dem Wartungsfenster hat.
• Fehlgeschlagene Bereitstellungen lösen einen automatischen Wiederholungsversuch aus; sollte auch der zweite Versuch fehlschlagen, wird eine Warnmeldung an das Patching-Team gesendet.

Der Grund dafür, diese als Standards und nicht als Verfahren zu formulieren, liegt darin, dass das operative Team Werkzeuge und Vorgehensweisen anpassen kann, ohne die Richtlinie neu verfassen zu müssen. Solange der Standard erfüllt 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 detailliert beschrieben wird.

6. Ausnahmebehandlung und Risikoakzeptanz

In jeder Umgebung gibt es Systeme, die nicht termingerecht gepatcht werden können. Legacy-Anwendungen, die unter neueren Bibliotheken nicht mehr funktionieren. Hersteller-Appliances mit einem Wartungsvertrag, der die Updates regelt. Air-Gapped-Systeme mit eigenen Änderungsfenstern. Die Richtlinie benötigt einen festgelegten Ausnahmeprozess und keine stillschweigende Vereinbarung, dass „wir das schon irgendwie hinbekommen werden“.

Eine wirksame Ausnahmeregelung umfasst:

• Ein Formular für einen dokumentierten Ausnahmeantrag (Asset, 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 Dauer der Ausnahmeregelung (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 dargestellt wird

Dieser Abschnitt ist deshalb so wichtig, weil ohne ihn der Ausnahmeprozess 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 der Vorschriften

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

• Operative Dashboards. Echtzeit-Übersicht über die Patch-Compliance nach Asset-Gruppen, 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.

Bei der Berichtspflicht lassen sich Prüfungsfeststellungen oft am einfachsten vorhersagen. Wenn die Richtlinie vorschreibt, dass vierteljährliche Überprüfungen stattfinden, Sie aber keine Protokolle der letzten vier Überprüfungen vorlegen können, ist das die Feststellung.

8. Integration 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)? Dies ist kein bürokratischer Mehraufwand. So verhindert das Patching-Team, dass es von einem Änderungsgremium 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, sofern 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 betrieblicher und sicherheitstechnischer Natur. Manuelles Patchen in einer Organisation, die mehr als ein paar Dutzend Endgeräte umfasst, führt zu Inkonsistenzen und Verzögerungen. Eine Automatisierung mit geeigneten Sicherheitsvorkehrungen ist schneller, konsistenter und besser zu rechtfertigen. Eine ausführlichere Erläuterung dazu, was automatisiert und was manuell durchgeführt werden sollte, finden Sie in unserem Blogbeitrag zum automatisierten Patch-Management. Für Richtlinienzwecke 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 eine außerplanmäßige Überprüfung (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 Änderungen an Richtlinien (in der Regel dieselbe Stelle, die auch die ursprüngliche Fassung genehmigt hat)

Eine Richtlinie ohne Versionshistorie ist eine Richtlinie, die von niemandem überwacht wird.

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 unter den Anwendungsbereich fallende 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. Klassifizierung von Patches 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. Anlagenverzeichnis

   5.1 Anforderungen an Bestandsdaten

   5.2 Häufigkeit der Abstimmung

   5.3 Deckungsschwellen

6. Patch-Tests und Bereitstellung

   6.1 Prüfanforderungen

   6.2 Struktur des Deployment-Rings

   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 Dauer der Ausnahmeregelung und Verlängerung

   7.4 Ausgleichsregelungen

   7.5 Ausnahmeregister und Überprüfung

8. Berichterstattung und Compliance

   8.1 Operative Berichterstattung

   8.2 Monatliche Compliance-Berichte

   8.3 Vierteljährliche Überprüfungen

   8.4 Jährlicher Compliance-Bericht

   8.5 Zuordnung der Rahmenwerke

9. Integration des Veränderungsmanagements

   9.1 Einstufung von Änderungen in Standard-, Normal- und Notfallkategorien

   9.2 Interaktion mit dem Change-Beirat

10. Automatisierung

   10.1 Erforderlicher Automatisierungsumfang

   10.2 Kriterien für manuelle Eingriffe

11. Strategische Steuerung

   11.1 Häufigkeit der Überprüfungen

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

   11.3 Versionsverwaltung

   11.4 Genehmigungsbefugnis

Anhänge

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

B. Zuweisung von Rollen an namentlich genannte Personen (aktuell)

C. Ausnahmeregister

D. Begriffsverzeichnis

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 Vorgaben sollten jedoch unverändert bleiben.

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 festzulegen. Sie legt die Berichtsintervalle 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 durchgesetzt werden. Ein Team kann zwar im Sinne einer Best Practice beschließen, Patches für internetexponierte Systeme schneller zu priorisieren, doch wenn die Richtlinie dies nicht vorschreibt, verschwindet diese Vorgehensweise still und leise wieder, sobald das Team das nächste Mal unter Druck steht.

In der Richtlinie wird Automatisierung zudem vorgeschrieben und nicht nur toleriert. 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 Diskussion.

Bewährte Verfahren für Richtlinien zum 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 Befugnisse, liefert den Prüfern Nachweise, sorgt für Klarheit im 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 tatsächlich befolgt.

Die Richtlinien, die sich bewährt haben, weisen einige gemeinsame Merkmale auf. Sie sind hinsichtlich ihres Geltungsbereichs konkret formuliert und nicht nur als Zielvorstellungen gedacht. Ihre SLAs spiegeln die aktuellen Bedrohungsszenarien wider und nicht die Vorlagen von vor fünf Jahren. Sie benennen Rollen und keine Einzelpersonen. 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 die beabsichtigte Funktionsweise des Programms widerspiegelt. 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 die darin festgelegten Anforderungen tatsächlich umsetzen und nachweisen können. 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-Vorgaben verfehlt haben – und diese Lücke wird bei der Prüfung deutlich.

Die RMM-Lösungen von Kaseya sind darauf ausgelegt, das Patch-Management so zu gestalten, dass es den betrieblichen Anforderungen einer strengen Patch-Richtlinie gerecht wird. Die kontinuierliche Erfassung von Assets speist die Bestandsliste. Richtliniengesteuertes Scannen und die Bereitstellung verwandeln Klassifizierung und SLAs in automatisierte Arbeitsabläufe, anstatt sie manuell 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 Sie 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.