Patch-Management: Leitfaden für die Praxis

Warum Patch-Management ein Prozess ist und kein Werkzeug

Viele Sicherheitsvorfälle beginnen mit einer Schwachstelle, für die längst ein Update verfügbar war: ein nicht aktualisiertes VPN-Gateway, ein veralteter Webserver, eine vergessene Fachanwendung. Ein Softwareverteilungs-Tool allein löst das nicht. Entscheidend ist ein Ablauf mit klaren Zuständigkeiten, festen Fristen und einer vollständigen Übersicht darüber, was überhaupt gepatcht werden muss. Der BSI IT-Grundschutz beschreibt die Anforderungen dazu im Baustein OPS.1.1.3 „Patch- und Änderungsmanagement“.

Der Patch-Prozess in sechs Schritten

1. Inventar: Ohne vollständiges Asset-Inventar bleiben Lücken unentdeckt. Erfassen Sie Server, Clients, Netzwerkkomponenten, Cloud-Dienste, Fachanwendungen und Firmware mit Versionsstand und verantwortlicher Person.
2. Informationsbeschaffung: Beobachten Sie Herstellerhinweise, Sicherheitsmeldungen des BSI und CERT-Warnungen. Microsoft veröffentlicht reguläre Updates am Patch Tuesday, dem zweiten Dienstag im Monat; andere Hersteller haben eigene Zyklen oder veröffentlichen anlassbezogen.
3. Bewertung und Priorisierung: Nicht jeder Patch ist gleich dringend. Die Priorität ergibt sich aus Schweregrad, Ausnutzungswahrscheinlichkeit und Bedeutung des betroffenen Systems (siehe unten).
4. Test: Kritische Systeme erhalten Updates zuerst in einer Testumgebung oder auf einer kleinen, repräsentativen Gruppe.
5. Verteilung: Die Installation erfolgt gestaffelt in Rollout-Ringen, mit geplanter Rückfalloption.
6. Verifikation: Ein Schwachstellenscan oder Abgleich mit dem Inventar zeigt, ob der Patch tatsächlich installiert ist. „Verteilt“ heißt nicht „wirksam“ – ein ausstehender Neustart kann den Schutz verhindern.

Priorisierung: CVSS, EPSS und CISA KEV kombinieren

Der CVSS (Common Vulnerability Scoring System) beschreibt den technischen Schweregrad einer Schwachstelle auf einer Skala von 0 bis 10. Er sagt aber nichts darüber, ob die Lücke tatsächlich angegriffen wird. Wer nur nach CVSS priorisiert, hat schnell Hunderte „kritische“ Aufgaben.

Das EPSS (Exploit Prediction Scoring System) von FIRST schätzt die Wahrscheinlichkeit, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Der CISA KEV-Katalog (Known Exploited Vulnerabilities) listet Schwachstellen, deren aktive Ausnutzung belegt ist. Obwohl es sich um eine US-Quelle handelt, ist er auch für europäische Unternehmen ein sehr nützlicher Indikator.

Eine praxistaugliche Reihenfolge lautet: Schwachstellen im KEV-Katalog und aus dem Internet erreichbare Systeme zuerst, danach hohe EPSS-Werte, danach hoher CVSS auf geschäftskritischen Systemen. Legen Sie für jede Stufe eine interne Frist fest, zum Beispiel wenige Tage für aktiv ausgenutzte Lücken an exponierten Systemen und einen Monatszyklus für reguläre Updates.

Test und Rollout-Ringe

Ein bewährtes Muster sind Ringe mit wachsender Reichweite: Ring 0 umfasst IT-eigene Testsysteme, Ring 1 eine Pilotgruppe aus verschiedenen Abteilungen, Ring 2 die breite Masse der Clients, Ring 3 besonders sensible Systeme wie Produktionsserver. Zwischen den Ringen liegen kurze Beobachtungszeiträume. Für Notfall-Patches werden die Ringe verkürzt, aber nicht ganz übersprungen, sofern das Risiko es zulässt.

Drittanbieter-Software und Firmware

Betriebssystem-Updates sind meist gut automatisiert. Die eigentlichen Lücken entstehen oft woanders: Browser-Plug-ins, PDF-Reader, Java-Laufzeitumgebungen, Fachanwendungen mit eigenem Updater, Bibliotheken in selbst entwickelter Software. Auch Firmware von Firewalls, Switches, Druckern, Hypervisoren und BIOS/UEFI muss Teil des Prozesses sein. Für Softwarebibliotheken hilft eine Stückliste (Software Bill of Materials, SBOM), um betroffene Komponenten schnell zu finden.

Besonderheit Produktion und OT

In der Operational Technology (OT) lassen sich Updates oft nicht sofort einspielen: Anlagen laufen durchgehend, Hersteller müssen Patches freigeben, und manche Steuerungen werden gar nicht mehr unterstützt. Hier sind kompensierende Maßnahmen entscheidend – Netzsegmentierung, restriktive Firewall-Regeln, abgesicherter Fernwartungszugang und Überwachung. Patches werden in geplanten Wartungsfenstern eingespielt, und nicht patchbare Systeme werden als bewusstes, dokumentiertes Restrisiko geführt.

Notfall-Patches

Für aktiv ausgenutzte Zero-Day-Lücken braucht es einen vorab definierten Notfallprozess: Wer darf außerhalb des regulären Änderungsprozesses entscheiden? Welche Tests sind mindestens nötig? Welche Übergangsmaßnahmen (Workarounds, Deaktivieren eines Dienstes, Sperren am Perimeter) greifen, bis ein Patch verfügbar ist? Zusätzlich sollte geprüft werden, ob die Lücke vor dem Patch bereits ausgenutzt wurde.

Kennzahlen

• Patch-Latenz: Zeit zwischen Veröffentlichung eines Patches und Installation, getrennt nach Priorität.
• Abdeckungsgrad: Anteil der Systeme mit aktuellem Patchstand, bezogen auf das vollständige Inventar.
• Fristeinhaltung: Anteil der kritischen Schwachstellen, die innerhalb der internen Frist geschlossen wurden.
• Ausnahmen: Anzahl und Alter dokumentierter Ausnahmen mit Risikoakzeptanz.

Bezug zu NIS2

NIS2 (Richtlinie (EU) 2022/2555) verlangt im Risikomanagement ausdrücklich Maßnahmen zu Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen einschließlich Schwachstellenmanagement. In Deutschland ist das über § 30 BSIG n. F. umgesetzt. Betroffene Einrichtungen sollten ihren Patch-Prozess daher dokumentieren und die Kennzahlen als Nachweis nutzen. Auch ISO/IEC 27001:2022 fordert mit dem Control zum Umgang mit technischen Schwachstellen einen solchen Prozess.

Fazit

Wirksames Patch-Management beruht auf einem vollständigen Inventar, einer Priorisierung nach tatsächlicher Ausnutzung und messbaren Fristen. SecTepe unterstützt beim Aufbau des Prozesses und bei der Einbindung in ISMS und NIS2-Nachweise.

Häufige Fragen

Sollten Updates automatisch installiert werden?

Für Clients und Standardsoftware in der Regel ja, kombiniert mit Rollout-Ringen. Bei Servern und Produktionssystemen ist eine kontrollierte Freigabe sinnvoll.

Was tun mit Systemen ohne Herstellersupport?

Ersatz planen, bis dahin isolieren, Zugriffe minimieren und das Restrisiko formal durch die Verantwortlichen akzeptieren lassen.