Patch-Management-Prozess

Patches einspielen ist nicht einfach „Update-Knopf drücken". Wer das produktiv macht, riskiert Ausfälle: ein Treiber-Update killt den Drucker-Spooler, ein DB-Patch macht die Replikation kaputt, ein Windows-Update legt VPN lahm. Deshalb braucht es einen Patch-Management-Prozess: einen wiederholbaren Ablauf, der Patches systematisch identifiziert, bewertet, testet, ausrollt und nachverfolgt. ITIL behandelt das als Teil des Change Management – jeder Patch ist ein Change. Aber das Patch-Management hat eigene Phasen, die du in einer FISI-Prüfung sicher kennen solltest. Diese Lektion zeigt dir den klassischen 6-Phasen-Prozess (Inventarisierung → Identifizierung → Bewertung → Test → Rollout → Verifikation), die Wellen-Strategie für den Rollout und die typischen Rollen. Mehr Details zu Sicherheits-Bewertung kommen in CVE/CVSS, zu Tools in WSUS und Linux-Patch-Management.

1) Der 6-Phasen-Zyklus

Patch-Management ist kein einmaliger Vorgang, sondern ein wiederkehrender Zyklus – meist monatlich. Klick die Phasen an:

Patch-Management-Prozess – 6 Phasen kontinuierlich

2) Wellen-Rollout – das produktive Vorgehen

Der zentrale Trick im Deployment: nicht alles auf einmal. Patches gehen in Wellen raus – erst Test, dann Pilot, dann breit. Wenn die erste Welle Probleme zeigt, ist die zweite noch nicht betroffen.

Wave-Rollout – typische Wellen-Strategie

Welle 1

Test-Umgebung + IT-Eigene Maschinen (3-5 % der Geräte) – maximal informierte Tester, schnelle Rückmeldungen

Tag 1-3

Welle 2

Pilot-Gruppe – ausgewählte Abteilung mit gemischtem Anwender-Profil (10-15 % der Geräte) – breite Auswahl, Bug-Erkennung

Tag 4-7

Welle 3

Breite Abteilungen – bis 60 % der Geräte. Keine kritischen Systeme, gut beobachtbar.

Tag 8-14

Welle 4

Restliche & kritische Systeme – Server, Geschäftsführung, externe Mitarbeiter. Erst nach klarer Bestätigung aus Welle 3.

Tag 15-21

Bei kritischen Security-Patches wird die Welle verkürzt – z. B. 24 h pro Welle statt 3-7 Tage. Bei Feature-Updates umgekehrt: Wochen pro Welle, lange Pilot-Phase. Wichtig: pro Welle Stop-Kriterien definieren – bei welcher Fehlerquote wird gestoppt?

3) Rollen im Patch-Management

Patch Manager

Verantwortlich für den Prozess. Koordiniert Phasen, stellt sicher, dass Termine eingehalten werden, eskaliert bei Problemen.

System Owner

Verantwortlich pro System (Server, Anwendung). Genehmigt Patches für sein System, koordiniert Tests.

Security Officer

Bewertet Sicherheits-Relevanz von Patches, setzt Prioritäten anhand CVSS.

Change Manager

Bringt Patches in den RFC-Prozess ein – meist als Standard-Change.

Test-Team

Führt funktionale und Regression-Tests in der Test-Umgebung durch.

Operations Team

Setzt Patches in Produktion um. Überwacht Verifikations-Phase und reagiert auf Vorfälle.

4) Wartungsfenster und Geschäftszeiten

Patches landen nicht mittags um 14 Uhr im produktiven CRM. Definiertes Wartungsfenster:

Standard-Wartungsfenster – z. B. jeden 3. Samstag von 22:00-04:00 Uhr. Allen Beteiligten bekannt, mit Vorlauf kommuniziert.
Patch Tuesday → Patch Saturday – Microsoft veröffentlicht dienstags, viele Firmen rollen am folgenden Wochenende aus.
Geschäftszeit-frei bei kritischen Services, Nacht oder Wochenende bei weniger kritischen.
Freeze-Periods – Zeiten ohne Patches: Black Friday im E-Commerce, Jahresabschluss in der Buchhaltung, Wahlzeit bei staatlichen IT-Stellen.

Bei Hochverfügbarkeits-Clustern ist das Wartungsfenster oft entkoppelt: ein Cluster-Knoten wird gepatcht, der andere übernimmt – kein User merkt den Patch.

5) Patch-Inventarisierung – die Basis

Ohne zu wissen, was man hat, kann man nichts gezielt patchen. Die Inventarisierung speist sich aus mehreren Quellen:

CMDB als zentraler Bezugspunkt – siehe CMDB.
Asset-Discovery-Tools – Lansweeper, ManageEngine, Microsoft Endpoint Configuration Manager – scannen Netzwerk und Hosts.
Endpoint-Agents – auf jedem Endgerät, melden installierte Software und Versionen.
Manuell für Spezialfälle – IoT-Geräte, Drucker-Firmware, OT-Komponenten ohne Agent-Möglichkeit.

Eine vollständige Inventarisierung erfasst auch Schatten-IT: Software, die User selbst installiert haben, Cloud-Dienste, die ohne Genehmigung genutzt werden. Patch-Lücken sind hier besonders gefährlich.

6) Tools im Überblick

Tool	Bereich	Stärke
WSUS	Windows Updates	Microsoft-eigen, kostenlos mit Windows Server
Microsoft Endpoint Configuration Manager (MECM)	Windows + macOS + Drittsoftware	Enterprise-Tool, breit
Microsoft Intune	Cloud-basiertes MDM	für moderne, mobile Setups
Red Hat Satellite / Foreman	Linux (RHEL/CentOS-Familie)	RHEL-Welt
Ansible / Puppet / Chef	Cross-Platform, Automation	als-Code-Patch-Management
Tanium / Qualys / Rapid7	Patch + Vulnerability Mgmt	integriert mit CVE-Scanning
Jamf	macOS / iOS	Apple-Welt-Standard
ManageEngine Patch Manager Plus	Cross-Platform	günstige Mittelstands-Lösung

7) KPIs

Patch-Compliance-Quote – Anteil der Systeme mit aktuellen Patches. Ziel: > 95 % für Kritisches innerhalb des SLA-Zeitraums. Mehr in Patch-Compliance.
Mean Time to Patch (MTTP) – Durchschnittliche Zeit von Patch-Verfügbarkeit bis vollständigem Rollout. Bei Critical: Tage. Bei Standard: Wochen.
Patch-Erfolgsrate – Anteil erfolgreich installierter Patches (ohne Rollback). Ziel: > 98 %.
Anzahl ungepatchter CVEs – kritische Schwachstellen, die noch offen sind. Ziel: 0 bei CVSS ≥ 9.
Mean Time to Detect Failed Patch – Zeit, bis ein fehlgeschlagener Patch erkannt wird. Wichtig für Monitoring-Integration.

8) Antipatterns

„Run all updates" als Strategie. Pauschal alle Patches installieren – inklusive Feature-Updates, die UI ändern und Schulungsbedarf erzeugen. Lösung: Patch-Typ-spezifische Pfade.
Auto-Approve auf produktiven Systemen. WSUS oder Auto-Update auf Produktion ohne Test = Glücksspiel. Lösung: Test-Welle pflicht.
Keine Wellen. Big Bang in einer Nacht für 5000 Geräte. Wenn was kaputt geht, sind alle betroffen. Lösung: Wellen-Rollout mit Stop-Kriterien.
Verifikation vergessen. Patch ausgerollt, Häkchen gesetzt – aber niemand prüft, ob er wirklich installiert ist. Reboot fehlt → Patch ist da, aber nicht aktiv. Lösung: Compliance-Scan nach Rollout.
Patch-Backlog wachsen lassen. Kein klares SLA → Tickets sammeln sich → 1000 Patches in der Warteschlange → niemand sieht durch. Lösung: monatlicher Zyklus, alte Patches priorisiert raus.
Schatten-IT ignorieren. Marketing nutzt eigene SaaS, IT weiß nichts → keine Patch-Übersicht. Lösung: Discovery, Cloud-Asset-Inventar.
EOL-Systeme als „bleiben halt". Systeme nach End-of-Life weiterbetreiben → keine Patches mehr, jede neue CVE ist offen. Lösung: Lifecycle-Plan in CMDB.

Zusammenfassung

Patch-Management ist ein zyklischer Prozess in 6 Phasen: (1) Inventarisierung (was haben wir?), (2) Identifizierung (welche Patches gibt's neu?), (3) Bewertung (was ist relevant, wie kritisch?), (4) Test (in Test-Umgebung), (5) Deploy (in Wellen: Test → Pilot → Breit → Kritisches), (6) Verifikation (kontrollieren, dass es überall installiert ist). Wellen-Strategie minimiert Risiko – pro Welle Stop-Kriterien. Rollen: Patch Manager, System Owner, Security Officer, Change Manager, Test-Team, Operations. Standard-Wartungsfenster außerhalb Geschäftszeit (häufig „Patch Saturday" nach Microsoft Patch Tuesday). Inventarisierung über CMDB + Discovery + Agents. Tools: WSUS, MECM/Intune, Red Hat Satellite, Ansible, Tanium/Qualys, Jamf. KPIs: Patch-Compliance-Quote (> 95 %), Mean Time to Patch, Patch-Erfolgsrate, Anzahl ungepatchter CVEs. Antipatterns: Auto-Approve auf Prod, Big Bang ohne Wellen, fehlende Verifikation, EOL-Systeme weiterbetreiben.

Verwandte Lektionen: Patch-Typen · CVE/CVSS · WSUS · und mehrWeitere relevante LektionenLinux apt/yum Test vs. Produktiv Rollback Patch-Compliance Change Management CMDB Ansible