Autor: DTNK Redaktion
Veröffentlicht:
Ein verlässlicher Patch-Prozess beginnt mit dem Bestand
Ein verlässlicher Patch-Prozess beginnt vor der nächsten Sicherheitsmeldung. Er verbindet technische Dringlichkeit mit den Abläufen Ihres Unternehmens. Dafür müssen Sie wissen, welche Systeme vorhanden sind, welche Aufgaben sie erfüllen und wer über Änderungen entscheidet.
Erfassen Sie für Arbeitsplätze, Server, Netzwerkkomponenten und wichtige Anwendungen mindestens Produkt, Version, verantwortliche Person, betroffenen Geschäftsprozess und Erreichbarkeit. Ordnen Sie außerdem zu, ob ein System direkt aus dem Internet erreichbar ist und ob der Hersteller die eingesetzte Version noch unterstützt. Microsoft weist in seiner Lifecycle-Dokumentation darauf hin, dass Produkte unterschiedlichen Richtlinien und Zeitplänen folgen. Den konkreten Supportstatus müssen Sie deshalb für jedes Produkt und jede Version einzeln prüfen.
Aus dem Bestand entstehen Wartungsgruppen. Geräte mit ähnlicher Technik und vergleichbarer betrieblicher Bedeutung lassen sich gemeinsam planen. Selten erreichbare Notebooks, ausgelagerte Systeme und Spezialanwendungen brauchen einen eigenen Weg, damit sie bei einer zentralen Verteilung nicht übersehen werden.
Priorisieren Sie nach Risiko und betrieblicher Bedeutung
Hersteller veröffentlichen Updates mit unterschiedlichen Zielen. Manche schließen aktiv ausgenutzte Schwachstellen, andere beheben Fehler oder ändern Funktionen. Eine feste Reihenfolge entsteht aus mehreren Informationen: der betroffenen Version, der Erreichbarkeit des Systems, bekannten Angriffen, vorhandenen Schutzmaßnahmen und der Bedeutung für den Betrieb.
Der Known Exploited Vulnerabilities Catalog der CISA sammelt Schwachstellen, für die eine Ausnutzung in der Praxis belegt ist. CISA empfiehlt Organisationen, den Katalog als Eingangssignal für ihre Priorisierung zu verwenden. Die dort genannten Fristen für US-Bundesbehörden werden in diesem Artikel nicht auf deutsche Unternehmen übertragen. Herstellerinformationen und die eigene Systembetroffenheit bleiben ebenfalls erforderlich.
| Prüffeld | Zu klärende Frage |
|---|---|
| Betroffenheit | Ist genau die eingesetzte Produktversion betroffen? |
| Ausnutzung | Gibt es belastbare Hinweise auf aktive Angriffe oder öffentlich nutzbaren Angriffscode? |
| Erreichbarkeit | Ist das System aus dem Internet oder aus wenig vertrauenswürdigen Netzbereichen erreichbar? |
| Betriebswirkung | Welche Arbeitsabläufe wären durch einen Angriff oder durch eine fehlerhafte Aktualisierung betroffen? |
| Alternativen | Gibt es eine vom Hersteller empfohlene Zwischenmaßnahme, falls der Patch noch nicht eingespielt werden kann? |
Dokumentieren Sie die Entscheidung zusammen mit dem nächsten Prüftermin. Ein allgemeiner Schweregrad allein bildet weder Ihre Systemlandschaft noch die Folgen für den jeweiligen Geschäftsprozess vollständig ab.
Testgruppe und Rückfallplan begrenzen die Betriebsgefahr
Der BSI-Baustein OPS.1.1.3 Patch- und Änderungsmanagement fordert, Änderungen zu planen, zu genehmigen und zu dokumentieren. Patches sollen geeignet getestet werden; für die Durchführung müssen Rückfalllösungen vorhanden sein.
Wählen Sie eine kleine Testgruppe, die die spätere Umgebung sinnvoll abbildet. Dazu gehören bei Arbeitsplatzsystemen beispielsweise verschiedene Gerätemodelle und typische Fachanwendungen. Bei Servern zählen Abhängigkeiten wie Datenbanken, Schnittstellen und Anmeldedienste. NIST beschreibt solche zuerst aktualisierten Referenzsysteme als Canary Assets. Ein gestufter Rollout kann Probleme sichtbar machen, bevor weitere Systeme folgen.
Der Rückfallplan hängt vom System ab. Eine Deinstallation, ein vorheriger Systemzustand oder die Wiederherstellung aus einer Sicherung haben unterschiedliche Voraussetzungen und Auswirkungen. Halten Sie fest, wann der Rollout gestoppt wird, wer diese Entscheidung trifft und wie lange die Rückkehr zu einem nutzbaren Zustand voraussichtlich dauert. Der Beitrag Backup planen: RPO, RTO und Wiederherstellungstests erklärt die dazugehörigen Wiederanlaufziele.
Regelbetrieb und Notfallpatches brauchen getrennte Wege
Planbare Updates gehören in vereinbarte Wartungsfenster. Informieren Sie betroffene Fachbereiche über Termin, erwartete Unterbrechung, Ansprechpartner und die anschließende Funktionsprüfung. Ein freigegebener Standardablauf reduziert Rückfragen, ohne die fachliche Prüfung des einzelnen Updates zu ersetzen.
Für dringende Sicherheitsupdates braucht es einen verkürzten, vorab festgelegten Weg. NIST empfiehlt auch beim Emergency Patching eine kleine Testgruppe, sofern die Lage dafür Zeit lässt. Fehlt ein geeigneter Patch, können zeitlich begrenzte Maßnahmen wie das Abschalten einer Funktion oder die Isolation eines Systems nötig sein. Solche Maßnahmen müssen zur Herstellerempfehlung und zur eigenen Risikoentscheidung passen. Sobald eine dauerhafte Lösung verfügbar ist, wird die Zwischenmaßnahme überprüft und kontrolliert zurückgenommen.
DTNK beschreibt die laufende Beobachtung von Update- und Systemzuständen unter Monitoring und proaktive Wartung. Die Einordnung von Schwachstellen, Zugriffen und Schutzmaßnahmen gehört zum Leistungsfeld IT-Sicherheit. Umfang, Zuständigkeiten und Reaktionswege werden für den jeweiligen Betrieb vereinbart.
Erfolgskontrolle prüft Installation und Arbeitsfähigkeit
Eine Meldung über die Verteilung eines Pakets ist noch kein vollständiger Abschlussnachweis. Prüfen Sie, ob die vorgesehene Version auf den relevanten Systemen installiert ist, wichtige Anwendungen funktionieren und erforderliche Sicherheitseinstellungen erhalten geblieben sind. Geräte, die während des Wartungsfensters nicht erreichbar waren, benötigen eine eigene Nachverfolgung.
Erfassen Sie Ausnahmen mit System, Begründung, verantwortlicher Person, Schutzmaßnahme und erneutem Prüftermin. Der BSI-Baustein verlangt eine dokumentierte Entscheidung, wenn ein Patch nicht eingespielt wird. Dauerhafte Ausnahmen ohne erneute Bewertung erschweren die Risikoeinschätzung und den späteren Austausch nicht mehr unterstützter Produkte.
Für die Steuerung helfen Kennzahlen, die den betrieblichen Kontext erhalten. Sinnvoll sind zum Beispiel offene kritische Updates nach Wartungsgruppe, überfällige Ausnahmen und Systeme ohne bestätigten Installationsnachweis. NIST warnt vor zu einfachen Gesamtquoten, wenn diese die Bedeutung der betroffenen Systeme und Schwachstellen ausblenden.
Sieben Punkte für Ihre Patch-Management-Bestandsaufnahme
- Systeme, Versionen, Verantwortliche und Geschäftsbezug vollständig erfassen.
- Herstellerquellen und Supportzeiträume für die konkret eingesetzten Versionen beobachten.
- Betroffenheit, aktive Ausnutzung, Erreichbarkeit und Betriebswirkung gemeinsam bewerten.
- Testgruppe, Freigabe, Wartungsfenster und Abbruchkriterien festlegen.
- Für Regelupdates und dringende Sicherheitsupdates getrennte Abläufe dokumentieren.
- Installation, wichtige Funktionen und erhaltene Sicherheitseinstellungen nach dem Rollout prüfen.
- Ausnahmen mit Begründung, Schutzmaßnahme und erneutem Prüftermin nachhalten.
Die Leistungsbereiche Arbeitsplätze und Geräte sowie Server und IT-Infrastruktur zeigen, wo Patch-Management im laufenden Betrieb ansetzt. Eine Bestandsaufnahme sollte zuerst klären, welche Systeme und Zuständigkeiten bereits dokumentiert sind.
Quellenstand und fachliche Grundlage
Quellenstand: 11. Oktober 2026. Die folgenden Primärquellen wurden für diesen Entwurf abgerufen. Produktstände, Schwachstellenkataloge und Herstellerfristen können sich ändern und werden vor einer Veröffentlichung erneut geprüft.