Patch-Management: Checkliste mit Fristen, Rollen und Nachweis

NIST beschreibt Patch-Management als das Erkennen, Priorisieren, Beschaffen, Installieren und Überprüfen von Patches, Updates und Upgrades im ganzen Unternehmen und ordnet es als vorbeugende Wartung ein (NIST SP 800-40 Rev. 4). Ein Update einzuspielen oder auf eine Version ohne die Lücke umzusteigen, ist die einzige Reaktion, die eine Schwachstelle vollständig beseitigt, ohne Funktionen wegzunehmen (Abschnitt 2.1). NIST nennt vier Reaktionen auf das Risiko: akzeptieren, mindern, übertragen und vermeiden; das Patchen zählt zum Mindern.

Die Checkliste ist eine Empfehlung von TOMORIS. NISG 2026, NISV 2026 und DVO nennen für das Einspielen von Patches keine Fristen in Tagen: Verlangt sind eine angemessene Frist (Anhang Nr. 6.6.1 lit. a) und die unverzügliche Behebung von Schwachstellen, die die Einrichtung als kritisch einstuft (Nr. 6.10.2 lit. c).

NIST empfiehlt, Software-Inventare für physische und virtuelle Systeme einschließlich OT, IoT und Container ständig aktuell zu halten und dafür Automatisierung zu nutzen. Ein Inventar, das nur monatlich oder vierteljährlich über einen Schwachstellen-Scan entsteht, soll nicht mehr genügen (Abschnitt 3.2). Statt Ausnahmen zu sammeln, ordnet NIST jedes System einer Wartungsgruppe mit gleichen Bedürfnissen zu (Abschnitt 3.4).

• Server, Arbeitsplätze, Notebooks, Smartphones, Netzwerk- und Sicherheitsgeräte, Cloud-Dienste und Anwendungen mit Version erfasst, möglichst automatisch aktualisiert (NIST 3.2).
• Je System festgehalten: Plattform, wer es verwaltet, womit es verwaltet wird, Netzanbindung, vorhandene Schutzmaßnahmen, Nutzer und ihre Rechte (NIST 3.2).
• Je System auch: Bedeutung für den Betrieb, gesetzliche oder vertragliche Vorgaben zum Patchen und Einschränkungen, etwa Neustart nur im monatlichen Wartungsfenster (NIST 3.2).
• Wartungsgruppen gebildet, z. B. Notebooks der Mitarbeitenden, Server im eigenen Rechenzentrum, Smartphones, Container in der Cloud, nicht mehr patchbare OT-Systeme (NIST 3.4).
• Für jede eingesetzte Software festgelegt, wie mit integrierten Autoupdates umzugehen ist und wie sie abgesichert und konfiguriert werden; neue Komponenten auf ihre Update-Mechanismen geprüft (OPS.1.1.3.A3).
• Supportende je Produkt erfasst, damit rechtzeitig geprüft wird, ob es noch sicher betrieben werden kann (abgeleitet aus OPS.1.1.3.A15).
• Schwachstellen-Scans mit Anmeldung (authentifiziert), weil Scans ohne Anmeldung weniger Lücken finden (NIST 3.6).
• Angaben der Hersteller zur Softwarezusammensetzung (SBOM) genutzt, wo vorhanden (NIST 3.2).

OPS.1.1.3.A15 verlangt, Patches zeitnah nach Veröffentlichung zu bewerten und zu priorisieren; dabei soll geprüft werden, ob es zu dem Patch bekannte Schwachstellen gibt. Drei frei verfügbare Quellen helfen bei der Einstufung.

Die CISA hat ihre Vorgaben für US-Bundesbehörden am 10.06.2026 mit BOD 26-04 neu gefasst; sie ersetzt BOD 22-01 und BOD 19-02. Die Fristen der Tabelle gelten für die Behörden spätestens 180 Tage nach Erlass (Phase III). Die Frist hängt von vier Fragen ab: Ist das System öffentlich erreichbar? Steht die Lücke im KEV-Katalog? Kann ein Angreifer alle Schritte der Ausnutzung automatisieren? Erlangt er teilweise oder vollständige Kontrolle? Die Antworten zu den letzten drei Fragen veröffentlicht die CISA für jede CVE, etwa über ihr Programm Vulnrichment.

„Forensik“ heißt: innerhalb der drei Tage beheben oder abschwächen und das System auf eine Kompromittierung untersuchen. „Bei Erneuerung“ heißt: bei der nächsten geplanten größeren Aktualisierung oder Neuinstallation. Die Frist beginnt, sobald die CISA die Lücke in den KEV-Katalog aufnimmt oder die Behörde sie auf einem System findet, je nachdem, was früher eintritt. Nimmt man ein System vom Internet, verlängert sich die Frist meist; kommt die Lücke in den KEV-Katalog, verkürzt sie sich.

Die DVO verlangt eine angemessene Frist, nennt aber keine Tage. TOMORIS empfiehlt, die Fristen der CISA-Tabelle als Obergrenze zu übernehmen, weil sie Erreichbarkeit, Ausnutzung und Auswirkung zusammenführen. Legen Sie Fristen und Verfahren im Konzept nach OPS.1.1.3.A1 fest und lassen Sie es von der Geschäftsleitung freigeben.

Das monatliche Sicherheitsupdate von Microsoft für Windows erscheint am zweiten Dienstag jedes Monats, in der Regel um 10:00 Uhr Pacific Time; außerplanmäßige Updates kommen nach Bedarf (Microsoft Learn). Planen Sie das reguläre Wartungsfenster danach und halten Sie das Notfallverfahren für außerplanmäßige Updates bereit.

1. 1

   Meldungen verfolgen

   Sicherheitsmeldungen von Herstellern, CSIRTs und Behörden über feste Kanäle beziehen und diese Kanäle in geplanten Abständen überprüfen (DVO Anhang Nr. 6.10.2 lit. a, Nr. 6.10.4). Neue Einträge im KEV-Katalog können Sie bei der CISA per E-Mail abonnieren.

2. 2

   Bewerten und priorisieren

   Jeden Patch zeitnah nach Veröffentlichung bewerten: Welche Systeme sind betroffen, ist die Lücke ausgenutzt, ist das System aus dem Internet erreichbar? Daraus folgt die Frist (OPS.1.1.3.A15).

3. 3

   Entscheiden und begründen

   Entscheiden, ob der Patch eingespielt wird. Wird er nicht eingespielt, Entscheidung und Gründe dokumentieren und zusätzliche Maßnahmen festlegen (OPS.1.1.3.A15, DVO Anhang Nr. 6.6.1 lit. d, 6.6.2).

4. 4

   Herkunft und Integrität prüfen

   Updates nur aus vertrauenswürdigen Quellen beziehen und vorhandene Prüfsummen oder digitale Signaturen vor der Installation prüfen (OPS.1.1.3.A10, DVO Anhang Nr. 6.6.1 lit. c).

5. 5

   Testen

   Vor dem Einsatz in Produktionssystemen testen (DVO Anhang Nr. 6.6.1 lit. b). NIST rät, eine gestaffelte Verteilung zu erwägen: zuerst wenige Systeme, etwa von Administratoren, dann eine größere Gruppe, dann alle (Abschnitt 3.5.1).

6. 6

   Mit Rückfall-Lösung ausrollen

   Für jede Installation eine Rückfall-Lösung bereithalten (OPS.1.1.3.A1). Reguläre Updates nach einer Schonfrist erzwingen, wie es NIST empfiehlt, statt sie beliebig verschieben zu lassen.

7. 7

   Erfolg kontrollieren

   Prüfen, ob der Patch auf allen relevanten Systemen erfolgreich eingespielt wurde (OPS.1.1.3.A15). Geräte, die zeitweise nicht erreichbar sind, gesondert nachverfolgen (OPS.1.1.3.A14, bei erhöhtem Schutzbedarf).

8. 8

   Dokumentieren

   Patches und Änderungen geplant, genehmigt und dokumentiert halten (OPS.1.1.3.A1, A11). Die Dokumentation dient auch als Grundlage für Nachweise nach § 33 NISG 2026.

NIST nennt Gründe, warum sofortiges Patchen nicht immer möglich ist: Der Patch ist noch nicht verfügbar, der Hersteller unterstützt die Software nicht mehr, oder das System muss lange ohne Unterbrechung laufen. Für diese Fälle sollen Notfall-Abschwächungen und langfristige Schutzmaßnahmen vorab geplant sein (Abschnitte 2.1, 3.3, 3.5.3 und 3.5.4).

• Notfall-Abschwächungen vorbereitet: verwundbare Funktion abschalten, System isolieren; Abläufe und Werkzeuge dafür vorab festgelegt (NIST 3.5.3).
• Für jede Abschwächung ein Termin, bis wann der dauerhafte Patch eingespielt und die Abschwächung wieder entfernt ist (NIST 3.5.3).
• Nicht patchbare Systeme isoliert, etwa durch Segmentierung, und die Schutzmaßnahmen regelmäßig neu bewertet (NIST 3.5.4).
• Ist kein Patch verfügbar oder wird er bewusst nicht eingespielt: zusätzliche Maßnahmen umgesetzt und das Restrisiko bewusst akzeptiert (DVO Anhang Nr. 6.6.1 lit. d).
• Produkte ohne Herstellersupport geprüft: Können sie noch sicher betrieben werden? Wenn nicht, dürfen sie nicht mehr verwendet werden (OPS.1.1.3.A15).
• Kann eine NIS2-pflichtige Einrichtung eine Anforderung vorübergehend nicht erfüllen: kompensierende Maßnahmen umsetzen, begründet dokumentieren, Wirksamkeit mindestens jährlich prüfen (§ 4 NISV 2026).
• Ausnahmen von den Wartungsplänen zentral erfasst, überwacht und regelmäßig darauf geprüft, ob der Plan jetzt umsetzbar ist (NIST 3.5.5).

Geräte am Netzrand, etwa Firewalls, Router, Switches und WLAN-Zugangspunkte, sind ein attraktives Ziel; die CISA beobachtet breit angelegte Angriffe auf solche Geräte ohne Herstellersupport. Mit BOD 26-02 vom 05.02.2026 verpflichtet sie US-Bundesbehörden, sie innerhalb von 12 bis 18 Monaten außer Betrieb zu nehmen und durch unterstützte Geräte zu ersetzen. Für andere Organisationen ist das eine Orientierung.

NIST rät von zu einfachen Kennzahlen ab, etwa dem Anteil gepatchter Lücken im ganzen Unternehmen: Sie sagen nichts darüber, ob die wichtigen Systeme und die gefährlichen Lücken behoben sind. Besser ist eine Matrix nach Bedeutung des Systems und der Schwachstelle mit dem Anteil, der innerhalb der Frist behoben wurde, sowie mittlerer und medianer Dauer (Abschnitt 3.6, Tabelle 1).

• Konzept für Patch- und Änderungsmanagement mit Fristen, Rollen und Umgang mit Ausnahmen schriftlich festgelegt und befolgt (OPS.1.1.3.A1).
• Je Patch nachvollziehbar: Bewertung, Entscheidung, Test, Installationszeitpunkt und Kontrolle (OPS.1.1.3.A1, A15).
• Liste der Ausnahmen mit Begründung, Ersatzmaßnahme, Verantwortlichen und nächstem Prüftermin (DVO Anhang Nr. 6.6.2, § 4 Abs. 3 NISV 2026).
• Ergebnisse der Schwachstellen-Scans in geplanten Abständen aufgezeichnet (DVO Anhang Nr. 6.10.2 lit. b).
• Kennzahl „innerhalb der Frist behoben“ je Wartungsgruppe und Fristenstufe, dazu mittlere und mediane Dauer (NIST 3.6).
• Wirksamkeit der Maßnahmen nach einem festgelegten Verfahren bewertet (DVO Anhang Nr. 7.1).
• Für NIS2-pflichtige Einrichtungen: Angaben zu den umgesetzten Risikomanagementmaßnahmen für die Selbstdeklaration vorbereitet, fällig innerhalb von zwölf Monaten nach Eintritt der Registrierungspflicht (§ 33 Abs. 1 NISG 2026).

• Reguläre Updates werden verschoben, weil sie nicht dringend wirken. Das öffnet Angreifern zusätzliche Zeitfenster und macht Notfall-Patches schwerer, weil erst ältere Patches nachgezogen werden müssen (NIST 3.3).
• Nur der KEV-Katalog wird beachtet. Auch Lücken außerhalb des Katalogs können dringend sein: BOD 26-04 setzt etwa für automatisierbar ausnutzbare Lücken an Systemen im Internet 3 oder 14 Tage.
• Priorisiert wird nur nach der CVSS-Punktzahl, ohne Erreichbarkeit, Ausnutzung und Bedeutung des Systems zu berücksichtigen (CVSS-Spezifikation, BOD 26-04).
• Notfall-Abschwächungen bleiben dauerhaft bestehen, weil kein Termin für Patch und Rückbau festgelegt wurde (NIST 3.5.3).
• Nicht entschiedene oder nicht dokumentierte Ausnahmen: Für jeden nicht eingespielten Patch braucht es Entscheidung und Begründung (OPS.1.1.3.A15).
• Netzwerkgeräte, Firmware und Fachanwendungen fehlen im Inventar und damit im Patch-Zyklus (NIST 3.2).