Was ist Patch-Management?
Patch-Management bringt ein Update kontrolliert in den Betrieb und weist nach, dass die Schwachstelle danach geschlossen ist. Welche Lücke mit welcher Dringlichkeit behandelt wird, entscheidet das vorgelagerte Schwachstellenmanagement. Ohne diese Priorisierung spielt das Patch-Management ein, was die Hersteller ausliefern, und nicht zwingend das, was das größte Risiko trägt.
Ausgangspunkt ist ein Asset-Inventar mit Versionen und Verantwortlichen. Es umfasst auch eingebundene Bibliotheken, Container-Basisimages und Firmware; welche Softwarekomponenten in einem Produkt stecken, zeigt eine SBOM.
| Schritt | Was geschieht |
|---|---|
| Beobachten | Hersteller-Advisories und Warnungen von CERTs und Behörden auswerten |
| Bewerten | prüfen, ob die verwundbare Funktion im Einsatz und erreichbar ist |
| Testen | Auswirkung auf Funktion und Schnittstellen in einer repräsentativen Umgebung prüfen |
| Freigeben | die Änderung im Change-Management beschließen, mit Wartungsfenster und Rückfallplan |
| Ausrollen | gestaffelt verteilen, beginnend mit einer kleinen Gruppe |
| Verifizieren | prüfen, ob die verwundbare Version verschwunden ist |
| Dokumentieren | Stand, Ausnahmen und Fristüberschreitungen festhalten |
Wie dieser Prozess in ein Managementsystem eingebunden wird, zeigt der Ratgeber ISMS einführen.
Welche Fristen gelten für Sicherheitspatches?
Eine feste Stundenzahl schreibt weder das BSIG noch DORA vor. Für zwei Gruppen ist aber geregelt, dass Fristen bestehen und eingehalten werden:
| Wer | Grundlage | Vorgabe |
|---|---|---|
| besonders wichtige und wichtige Einrichtungen | § 30 Abs. 2 Satz 2 Nr. 5 BSIG | Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung „einschließlich Management und Offenlegung von Schwachstellen“; eine Frist nennt die Vorschrift nicht |
| Einrichtungen der Arten nach § 30 Abs. 3 BSIG, etwa Cloud-Anbieter und Managed Service Provider | Anhang Nr. 6.6.1 und 6.10.2 der Durchführungsverordnung (EU) 2024/2690 | Sicherheitspatches „innerhalb einer angemessenen Frist“ nach Verfügbarkeit anwenden und vorher testen; als kritisch eingestufte Schwachstellen „unverzüglich“ beheben |
| Finanzunternehmen außerhalb des vereinfachten Rahmens nach Art. 16 DORA | Art. 10 Abs. 4 Buchst. d der Delegierten Verordnung (EU) 2024/1774 | Fristen für die Installation von Patches festlegen, dazu ein Eskalationsverfahren für den Fall, dass eine Frist nicht zu halten ist |
Für Finanzunternehmen nach DORA gilt § 30 BSIG nicht (§ 28 Abs. 6 Nr. 1 BSIG); Telekommunikations- und Energieunternehmen nach den §§ 5c bis 5e EnWG nimmt § 28 Abs. 5 BSIG grundsätzlich aus.
Staffeln Sie die eigenen Fristen nach Kritikalität der Schwachstelle und Bedeutung des Systems. Diese Kriterien nennt Art. 10 Abs. 2 der Delegierten Verordnung für die Priorisierung: die Kritikalität der Schwachstelle, die Klassifizierung des betroffenen IKT-Assets und sein Risikoprofil.
Wie prüfen Sie, ob ein Patch die Lücke geschlossen hat?
Ein Verteilwerkzeug meldet, dass ein Paket installiert wurde. Behoben ist die Schwachstelle erst, wenn die verwundbare Version nicht mehr läuft, etwa weil der Dienst nach dem Update neu gestartet wurde. Prüfen Sie nach jedem Rollout vier Punkte:
| Prüfung | Erwartetes Ergebnis | Nachweis |
|---|---|---|
| Installationsstatus im Verteilwerkzeug | „installiert“ auf allen Systemen des Rollouts | Statusexport mit Datum |
| laufende Version am System | der Dienst wurde neu gestartet und meldet die korrigierte Version | Versionsabfrage oder Startzeit des Dienstes |
| unabhängiger Schwachstellenscan | die Schwachstelle wird nicht mehr gemeldet | Scanbericht nach dem Rollout |
| Funktionstest | die fachliche Kernfunktion arbeitet | Testprotokoll mit Freigabe des Fachbereichs |
Beispiel (fiktiv): Für eine kritische Schwachstelle in einer Webserver-Bibliothek meldet das Verteilwerkzeug „installiert“ auf 40 von 40 Servern. Der Scan am nächsten Tag findet die Schwachstelle noch auf 6 Servern, weil der Dienst dort nicht neu gestartet wurde. Die Zahlen sind frei gewählt. Der Patchstand lautet damit 34 von 40; für die 6 Server läuft die Frist weiter, und bei Überschreitung greift die Eskalation.
Was gilt, wenn ein System nicht gepatcht werden kann?
Fehlen Herstellerfreigabe oder Zertifizierung, etwa in der Medizintechnik, oder hängt eine Altanwendung an der alten Version, ersetzen kompensierende Maßnahmen den Patch: Netzsegmentierung, strenge Zugriffsbeschränkung, Abschalten der betroffenen Funktion, vorgelagerte Filterung und verstärkte Überwachung. Das verbleibende Restrisiko übernimmt ein benannter Risikoeigentümer mit Begründung und Wiedervorlagedatum. Ohne dieses Datum wird aus der Ausnahme ein Dauerzustand.
Für Einrichtungen nach § 30 Abs. 3 BSIG verlangt Nr. 6.6.1 Buchst. d der Durchführungsverordnung in diesem Fall zusätzliche Maßnahmen und die Akzeptanz der Restrisiken. Auf einen verfügbaren Patch dürfen sie nach Nr. 6.6.2 nur verzichten, wenn die Nachteile seiner Anwendung die Vorteile für die Cybersicherheit überwiegen; die Entscheidung ist zu dokumentieren und zu begründen.
Was bedeutet das Support-Ende eines Produkts?
Für ein System ohne Sicherheitsupdates gibt es nichts mehr einzuspielen. Neu bekannte Schwachstellen bleiben offen, und die Frage wandert in Beschaffung und Lebenszyklusplanung.
Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen, Schwachstellen während des Unterstützungszeitraums wirksam zu behandeln. Dieser beträgt nach Art. 13 Abs. 8 der Verordnung (EU) 2024/2847 mindestens fünf Jahre, sofern das Produkt nicht voraussichtlich kürzer genutzt wird. Die Meldepflichten nach Art. 14 gelten seit dem 11. September 2026, die übrigen Pflichten ab dem 11. Dezember 2027. Auf Produkte, die vor diesem Datum in Verkehr gebracht wurden, erstreckt Art. 69 Abs. 3 nur die Meldepflichten; die Anforderungen an die Schwachstellenbehandlung erfassen sie erst nach einer wesentlichen Änderung.
Tragen Sie deshalb das Ende des Unterstützungszeitraums als Datum in Beschaffungsanforderungen und Asset-Inventar ein und planen Sie die Ablösung vor diesem Datum.
Patch-Management in Rizzqo
In Rizzqo hängen die Anforderungen zum Umgang mit Schwachstellen aus Frameworks wie ISO 27001 an Servern, Datenbanken und Netzkomponenten. Die richtige Person bestätigt je System, ob Patches rechtzeitig eingespielt sind, und lädt den Scanbericht als Nachweis hoch. Lässt sich ein System nicht patchen, bewerten Sie das Risiko in Euro und planen eine Übergangslösung, etwa die Abschottung des Systems, als Aufgabe.