IHK-Vorbereitung · Fachinformatiker Systemintegration
Prüfungsrelevanz
AP1 + AP2
Patchmanagement ist Bestandteil von Systemadministration und IT-Sicherheit
Kerndefinition
CVE → Patch
Vom bekannten Sicherheitsproblem zur kontrollierten Behebung im Betrieb
Patchmanagement bezeichnet den geregelten Prozess, mit dem Software-Updates, Sicherheitskorrekturen (Patches) und Hotfixes für Betriebssysteme, Anwendungen und Firmware identifiziert, bewertet, getestet, verteilt und dokumentiert werden. Ziel ist es, bekannte Schwachstellen zeitnah zu schließen, ohne den laufenden Betrieb zu gefährden.
⚠️ Prüfungshinweis: Patchmanagement ist nicht nur ein technisches Thema – Wartungsfenster, Rollback-Planung und Dokumentationspflicht sind gleichwertige Prüfungsinhalte.
Security Patch (Sicherheitspatch)
Behebt eine konkrete Sicherheitslücke (CVE). Höchste Priorität. Zeitkritisch – je nach CVSS-Score innerhalb von Stunden bis wenigen Tagen einzuspielen.
Hotfix / Bugfix
Behebt einen kritischen Fehler außerhalb des regulären Releasezyklus. Oft ungeplant, erfordert schnelle Testphase vor dem Rollout.
Kumulatives Update / Rollup
Bündelt mehrere vorherige Patches. Bei Windows üblich (monatlicher „Patch Tuesday"). Erleichtert das Auf-den-Stand-Bringen neu aufgesetzter Systeme.
Feature Update / Service Pack
Fügt neue Funktionalität hinzu oder modernisiert das System grundlegend. Aufwändigere Tests notwendig. Längere Wartungsfenster einplanen.
Der Common Vulnerability Scoring System (CVSS)-Score (0–10) bestimmt, wie dringend ein Patch eingespielt werden muss:
| CVSS-Score | Einstufung | Reaktionszeit (Best Practice) | Beispiel |
|---|---|---|---|
| 9,0 – 10,0 | Kritisch | 24–72 Stunden (Notfallpatch) | Log4Shell (CVE-2021-44228) |
| 7,0 – 8,9 | Hoch | 7–14 Tage | Privilege Escalation im Kernel |
| 4,0 – 6,9 | Mittel | 30 Tage (regulärer Zyklus) | Informationsleck in Webdienst |
| 0,1 – 3,9 | Niedrig | Nächster regulärer Zyklus | Fehler in Fehlermeldungstext |
WSUS ist ein kostenloser Microsoft-Dienst zur zentralen Verwaltung und Verteilung von Windows-Updates im Unternehmensnetz. Patches werden einmalig vom Microsoft-Server heruntergeladen und intern an alle Clients verteilt – das spart Bandbreite und ermöglicht Kontrolle über den Rollout-Zeitpunkt.
WSUS Microsoft / Windows
⚠️ Prüfungsfalle: WSUS verteilt Updates nur – er installiert sie nicht automatisch. Installation erfolgt über die Client-seitige GPO-Einstellung (Automatische Updates konfigurieren).
Der Microsoft Endpoint Configuration Manager (MECM, früher SCCM) ist eine umfassende Enterprise-Lösung für Software-Deployment, Patchmanagement, Inventarisierung und Geräteverwaltung. Er baut auf WSUS auf und erweitert dessen Fähigkeiten erheblich.
SCCM / ConfigMgr Enterprise
In Linux-Umgebungen erfolgt das Patchmanagement über Paketmanager, die Software aus zentralen oder selbst gehosteten Repositorys beziehen. Das Prinzip ähnelt WSUS: ein internes Mirror-Repository statt direkter Internetverbindung pro Client.
APT (Debian / Ubuntu)
Befehle: apt update (Paketliste aktualisieren), apt upgrade (Pakete aktualisieren), apt dist-upgrade (inkl. Kernel). Repositorys in /etc/apt/sources.list. Für Unternehmen: eigener APT-Mirror via Apt-Cacher NG oder Spacewalk.
YUM / DNF (RHEL / CentOS / Fedora)
Befehle: yum update / dnf update. Security-only: dnf update --security. Interne Repositorys mit Satellite (Red Hat) oder Foreman/Katello verwalten.
Unattended Upgrades (Automatisierung)
Debian-Paket für automatische Sicherheitsupdates. Konfiguration in /etc/apt/apt.conf.d/50unattended-upgrades. Nur Security-Repository aktivieren, unkontrolliertes Upgrade aller Pakete vermeiden.
💡 Internes Repository: Im Unternehmensumfeld werden Repositorys gespiegelt (Mirror), sodass Clients keine direkte Internetverbindung benötigen. Updates können vor dem Rollout geprüft werden.
| Merkmal | WSUS | ConfigMgr/SCCM | Linux-Repo |
|---|---|---|---|
| Betriebssystem | Windows | Windows (+ Android/macOS optional) | Linux |
| Drittanbieter-Software | ❌ Nein | ✅ Ja (SCUP) | ✅ Ja (eigene Repos) |
| Lizenzkosten | Kostenlos | Lizenzpflichtig (CAL) | Kostenlos / Subscription |
| Reporting / Compliance | Einfach | Umfangreich (SSRS) | Manuell / Tools |
| Wartungsfenster | GPO-basiert | Nativ in ConfigMgr | Cron / Systemd Timer |
Neben Betriebssystem und Anwendungen müssen auch Firmware-Updates in das Patchmanagement einbezogen werden. Firmware ist die unterste Software-Schicht eines Geräts und direkt auf dem Chip gespeichert.
🚨 Kritisches Risiko: Ein fehlgeschlagener Firmware-Flash kann ein System dauerhaft unbrauchbar machen (Brick). Firmware-Updates erfordern besondere Sorgfalt – immer Backup & Rollback-Strategie planen.
BIOS / UEFI (Motherboard-Firmware)
Steuert den Boot-Vorgang und Hardwarezugriff. Updates schließen Lücken wie Spectre/Meltdown (CPU-Microcode) oder verbessern Hardware-Kompatibilität. Verteilung über Hersteller-Tools (z.B. Dell Command Update, HP BIOS Flash Utility) oder SCCM.
NIC / Switch / Router Firmware
Netzwerkgeräte haben eigene Firmware. Kritisch bei bekannten Exploits (z.B. Cisco IOS-Lücken). Updates über Hersteller-Konsole oder zentrale Netzwerkmanagementsysteme.
SSD / HDD Firmware
Selten, aber relevant (z.B. Samsung SSD-Datenkorruptionsfehler). Update via Hersteller-Tool. Datensicherung zwingend vor dem Update.
Drucker / IoT / Embedded Geräte
Oft vergessen, aber angreifbar. Firmware-Updates über Weboberfläche oder herstellerspezifische Tools. Im Unternehmensumfeld über Asset-Management erfassen und regelmäßig prüfen.
Bestandsaufnahme
Aktuelle Firmware-Versionen aller Geräte inventarisieren. In ConfigMgr/SCCM über Hardware-Inventory oder WMI abfragen. Bei Netzwerkgeräten: SNMP-Abfrage oder Netzwerk-Scanner.
Herstellerinformationen prüfen
Release Notes lesen: Welche Fehler werden behoben? Sind Voraussetzungen zu erfüllen (z.B. erst auf Version X updaten, dann auf Z)? Gibt es bekannte Probleme mit dem neuen Release?
Datensicherung & Snapshot
Vor dem Flash: vollständige Datensicherung, bei VMs einen Snapshot anlegen. Bei physischen Geräten: aktuelles BIOS-Image sichern, falls Downgrade-Option besteht.
Test in isolierter Umgebung
Firmware-Update zuerst auf einem Testgerät (nicht produktiv) durchführen. Funktionalität nach Update vollständig prüfen, insbesondere Boot-Verhalten, Treiber-Kompatibilität und angeschlossene Hardware.
Rollout im Wartungsfenster
Firmware-Flashes erfordern Neustart – immer in vereinbartem Wartungsfenster durchführen. Stabile Stromversorgung sicherstellen (USV). Bei Laptops: Netzteil angeschlossen, nicht per Akku flashen.
Schwachstellen identifizieren
Quellen: Herstellermeldungen, BSI-Warnungen, CVE-Datenbank (NVD), CERT-Bund, Vulnerability Scanner (z.B. Nessus, OpenVAS). Ziel: lückenloses Bild des eigenen Patch-Stands.
Bewerten & priorisieren
CVSS-Score bestimmen. Ist das eigene System überhaupt betroffen? (Exposure Assessment) Welche Systeme sind kritisch für den Betrieb? Risikobewertung dokumentieren.
Patches beschaffen
Download aus offizieller Quelle (Hersteller, WSUS, Repository). Integrität prüfen: Hash-Wert vergleichen (SHA-256), digitale Signatur validieren. Nie Patches aus inoffiziellen Quellen!
Testen (Testumgebung)
Patch in einer vom Produktivbetrieb isolierten Testumgebung installieren. Funktionstest: Läuft die Software noch? Gibt es neue Fehler (Regressionen)? Kompatibilität mit anderen Anwendungen prüfen.
Change-Request genehmigen lassen
Formeller Änderungsantrag nach ITIL Change Management. Wer genehmigt? Wer wird informiert? Bei kritischen Systemen: Change Advisory Board (CAB). Rückfall-Plan (Rollback) muss dokumentiert sein.
Rollout im Wartungsfenster
Gestaffelte Verteilung: zuerst Pilotgruppe → dann breiter Rollout. Monitoring während der Installation. Bei Fehlern sofort Rollback einleiten. Benutzer vorab informieren.
Verifizieren
Compliance-Check: Wurden alle Systeme gepatcht? Vulnerability Scanner erneut ausführen – ist die Lücke geschlossen? Abweichungen dokumentieren und nachbearbeiten.
Dokumentieren & abschließen
Alle Schritte im Ticketsystem/Change-Log festhalten. Patch-Datenbank aktualisieren. Abschlussbericht für Audit-Trail erstellen.
Ein Wartungsfenster (Maintenance Window) ist ein vertraglich oder organisatorisch definierter Zeitraum, in dem Änderungen am IT-System vorgenommen werden dürfen, ohne als ungeplante Unterbrechung zu gelten.
Jeder Patch-Rollout muss einen dokumentierten Rollback-Plan besitzen. Dieser legt fest, wie das System in den vorherigen Zustand versetzt wird, wenn der Patch Probleme verursacht.
VM-Snapshot (vor dem Patch)
Bei virtuellen Maschinen: Snapshot vor dem Patchen anlegen. Bei Problemen: Snapshot wiederherstellen. Snapshots sind kurzfristige Sicherungen – nicht als dauerhafte Datensicherung geeignet.
Windows: Update deinstallieren
Über Einstellungen → Update → Updateverlauf → Updates deinstallieren oder per Kommandozeile: wusa /uninstall /kb:XXXXXXX. Nicht alle Updates sind rückgängig zu machen.
Linux: Paket-Downgrade
APT: apt install paket=version – ältere Version aus Paketcache installieren. YUM/DNF: dnf downgrade paket. Voraussetzung: ältere Version im Repository oder lokalem Cache vorhanden.
Bare-Metal-Restore aus Backup
Letztes Mittel bei nicht rückgängig zu machenden Fehlern. Setzt aktuelles Backup und dokumentierten Restore-Prozess voraus. Verantwortlicher und Kontakt müssen im Rollback-Plan vermerkt sein.
Eine lückenlose Patchmanagement-Dokumentation ist Grundlage für Audits (ISO 27001, BSI IT-Grundschutz) und nachweisliche Compliance:
| Dokument | Inhalt | Zweck |
|---|---|---|
| Patch-Inventar | CVE, Patch-ID, Priorität, betroffene Systeme, Status | Überblick offener und abgeschlossener Patches |
| Change Record | Antragsteller, Genehmiger, Datum, Systeme, Rollback-Plan | ITIL-konformer Änderungsnachweis |
| Testprotokoll | Testergebnis, festgestellte Probleme, Tester, Datum | Nachweis der Qualitätssicherung vor Rollout |
| Rollout-Log | Durchgeführte Maßnahmen, Zeitstempel, Ergebnis pro System | Nachvollziehbarkeit, Fehleranalyse |
| Compliance-Bericht | Anteil gepatchter vs. ungepatchter Systeme, Ausnahmen (Exceptions) | Nachweis für Auditor, Geschäftsführung |
💡 Exceptions: Systeme, die aus technischen Gründen nicht gepatcht werden können (z.B. Legacy-Software ohne Patch), müssen mit Begründung, Risikobewertung und kompensierende Maßnahmen dokumentiert werden.
Lern_Apps
AP2_Lernplan
FISI_Tools
Cherry_Apps
Arcade_Tresor
Magic_Apps