Enterprise Patch Management: Systematische Schwachstellenbehebung

Patch Management ist eine der wirksamsten und gleichzeitig unterschätztesten Sicherheitsmaßnahmen. Die meisten erfolgreichen Angriffe nutzen bekannte, gepatchte Schwachstellen - weil das Patchen schlecht organisiert ist. Ein strukturiertes PM-Programm schließt dieses Fenster.

Der Patch-Management-Prozess

Der Patch-Management-Zyklus besteht aus sieben kontinuierlichen Phasen:

Phase 1: Asset-Inventar ist die Grundlage - ohne vollständiges Inventar entstehen blinde Flecken. Zu erfassen sind Server (IP, OS, Patchstand, Kritikalität), Clients (Gerät, OS, Software, Benutzer), Netzwerkgeräte (Hersteller, Firmware), Cloud-Ressourcen (EC2/VMs, Container, Managed Services) sowie IoT/OT-Geräte, die separate Behandlung mit anderen Zyklen erfordern. Geeignete Tools: CMDB, Active Directory, AWS Config, Azure Inventory.

Phase 2: Patch-Quellen überwachen. Wichtige Quellen sind Microsoft MSRC (msrc.microsoft.com, Patch Tuesday am 2. Dienstag des Monats), CISA KEV (cisa.gov/known-exploited-vulnerabilities, immer sofort priorisieren), BSI-Warnmeldungen sowie Herstellerportale (Cisco PSIRT, VMware Security Advisories u.a.).

Phase 3: Risikobewertung. Der CVSS-Score bewertet die technische Schwere (0-10), der EPSS-Score die Exploitation-Wahrscheinlichkeit. CISA-KEV-Einträge haben immer höchste Priorität. Im eigenen Kontext ist entscheidend: Ist das System im Internet erreichbar? Enthält es sensitive Daten? Gibt es einen Workaround?

Phase 4: Patch-SLA (verbindliche Fristen):

Schweregrad	Kontext	Frist
Critical (CVSS 9-10)	extern exponiert	24 Stunden
Critical (CVSS 9-10)	intern	72 Stunden
CISA KEV	beliebiger Score	sofort, unabhängig von CVSS
High (7-8)	extern exponiert	7 Tage
High (7-8)	intern	14 Tage
Medium (4-6)	alle	30 Tage
Low (0-3)	alle	90 Tage oder dokumentierte Akzeptanz

Phase 5: Patch-Testen. Nie direkt in Produktion patchen (außer Emergency-Patches nach Bewertung). Eine repräsentative Testumgebung ist Pflicht, automatisierte Tests prüfen die Funktionalität nach dem Patch, und ein Rollback-Plan muss vor jedem Deployment erstellt sein.

Phase 6: Deployment. Rollout über Staging → Canary (5% der Systeme) → vollständiges Rollout. Geplante Wartungsfenster für Produktion (nachts oder am Wochenende), erhöhtes Monitoring nach dem Deployment.

Phase 7: Verifikation. Rescan nach dem Patch bestätigt, dass die CVE behoben ist. Das Vulnerability-Scanner-Finding muss verschwinden. Compliance-Check: wurde die Patch-SLA eingehalten?

Windows-Umgebungen patchen

Microsoft WSUS (Windows Server Update Services) ist kostenlos und geeignet für reine Windows-Umgebungen. Empfohlene WSUS-Gruppen sind "Pilot-PCs" (10-20 Geräte), "Produktions-Server", "Domain Controller" (extra Vorsicht) und "Workstations".

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools
& 'C:\Program Files\Update Services\Tools\wsusutil.exe' postinstall `
  CONTENT_DIR=D:\WSUS

Die Deployment-Strategie verteilt sich über 4 Wochen: Woche 1 Pilot-Gruppe, Woche 2 breiterer Test (10% der Workstations), Woche 3 vollständige Workstations, Woche 4 Server im Wartungsfenster. CISA-KEV-Einträge werden direkt in Phase Server behandelt.

Microsoft Intune (Cloud-nativ) nutzt Update Rings: Ring 0 für IT-Admins (sofort), Ring 1 für Pilot-User (7 Tage nach Release), Ring 2 für breites Deployment (21 Tage), Ring 3 für Nachzügler (35 Tage).

# Lokale Patch-Compliance prüfen:
Get-HotFix | Sort-Object InstalledOn -Descending | Select -First 10

Linux-Umgebungen patchen

# Debian/Ubuntu - nur Sicherheitsupdates:
apt-get update && apt-get upgrade -y --security-only

# RHEL/CentOS/Rocky - nur Security-Patches:
dnf update --security -y
dnf updateinfo list security  # Was würde geupdated werden?

Für skalierbares Linux-Patching über viele Systeme bietet Ansible einen strukturierten Ansatz:

# patch-servers.yml
- name: Patch Linux Servers
  hosts: all
  become: yes
  tasks:
    - name: Install security updates (Debian/Ubuntu)
      apt:
        upgrade: dist
        update_cache: yes
      when: ansible_os_family == 'Debian'
      notify: Check if reboot required

    - name: Update packages (RHEL)
      dnf:
        name: '*'
        security: yes
        state: latest
      when: ansible_os_family == 'RedHat'
      notify: Check if reboot required

Cloud-Umgebungen patchen

# AWS SSM Patch Baseline erstellen:
aws ssm create-patch-baseline \
  --name "Linux-Security-Baseline" \
  --operating-system "AMAZON_LINUX_2" \
  --approval-rules \
    'PatchRules=[{PatchFilterGroup:{PatchFilters:[
      {Key=SEVERITY,Values=[Critical,High]},
      {Key=CLASSIFICATION,Values=[Security]}]},
      AutoApproveAfterDays=7}]'

# Compliance prüfen:
aws ssm describe-instance-patch-states-for-patch-group \
  --patch-group production-servers

Azure Update Manager bietet im Azure Portal unter "Update Manager → Patch Management" Assessment-Funktionen, konfigurierbare Maintenance-Schedules und ein Compliance-Dashboard.

Container-Patching: Basis-Images immer explizit versionieren (FROM ubuntu:22.04, nie :latest). Trivy-Scans im CI/CD verhindern vulnerable Images in der Produktion. Images sollten wöchentlich neu gebaut werden, nicht nur bei Code-Änderungen.

Notfall-Patching (Emergency Patch Process)

Ausgelöst wird ein Emergency-Patch durch BSI-Warnung, CISA-KEV-Eintrag oder aktiven Angriff.

Schritt 1: Exposure-Assessment (0-2 Stunden): Ist die betroffene Software im Einsatz? Wo ist sie eingesetzt (internet-exponiert)? Gibt es Workarounds (WAF-Rule, Feature-Disable, Firewall-Block)? Wird der Exploit aktiv ausgenutzt?

Schritt 2: Entscheidung (2-4 Stunden): Option A ist Sofort-Patch mit verkürztem Testing (unter 2 Stunden). Option B ist Workaround plus geplanter Patch wenn der Patch noch nicht verfügbar ist. Option C ist System offline nehmen wenn das Risiko untragbar ist. Der CISO muss die Entscheidung genehmigen.

Schritt 3: Beschleunigter Rollout. Minimaler Funktionstest statt vollständiger Test-Suite. Systeme parallel statt sequentiell patchen. Erhöhtes Monitoring während des Deployments.

Schritt 4: Dokumentation (immer). Welche CVE? Wann erkannt, wann gepatcht? War der Exploit aktiv vor dem Patch? Abschluss-Bestätigung: Vulnerability im Rescan nicht mehr sichtbar.

Compliance-Anforderungen

ISO 27001 (A.8.8): Schriftliche Patch-Management-Richtlinie, nachweisbare SLAs und Compliance-Tracking sowie regelmäßiges Auditing.

NIS2 (Art. 21): "Angemessene technische und organisatorische Maßnahmen" - Patch Management explizit adressiert. 72h Meldepflicht bei Incidents durch ungepatchte Vulnerabilities.

BSI IT-Grundschutz (OPS.1.1.3): Patches unverzüglich einspielen, dokumentierte Testverfahren und nachweisbare Rollback-Möglichkeit.

PCI DSS v4 (Anforderung 6.3): Critical Patches innerhalb 1 Monat nach Release, alle anderen Patches innerhalb 3 Monate, formaler Change-Management-Prozess.

Für Audits sind folgende Dokumente erforderlich: Patch-Policy mit SLAs, Prozess und Rollen; Asset-Inventar mit Patchstand; monatliche Patch-Compliance-Reports; Ausnahmegenehmigungen mit Begründung; Vulnerability-Scanner-Reports vor und nach Patch; Emergency-Patch-Protokolle.