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

Patch-Management-Zyklus (kontinuierlich):

Phase 1: Asset-Inventar (Grundlage)
  → Ohne vollständiges Inventar: blinde Flecken!
  → Server: IP, OS, Patchstand, Kritikalität
  → Clients: Gerät, OS, Software, Benutzer
  → Network Devices: Hersteller, Firmware, Managementzugang
  → Cloud: EC2/VMs, Containers, Managed Services
  → IoT/OT: separate Behandlung (andere Zyklen, Offline-Phasen)
  → Tools: CMDB, Active Directory (Clients), AWS Config, Azure Inventory

Phase 2: Patch-Quellen überwachen
  → Microsoft MSRC:     msrc.microsoft.com (Patch Tuesday: 2. Dienstag/Monat)
  → CISA KEV:           cisa.gov/known-exploited-vulnerabilities (IMMER sofort!)
  → BSI Warnmeldungen:  bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen
  → NVD/CVE:           nvd.nist.gov (RSS-Feed empfohlen)
  → Herstellerportale:  Cisco PSIRT, VMware Security Advisories, etc.
  → Threat Intel Feeds: MISP, OTX, kommerziell

Phase 3: Risikobewertung
  → CVSS Score: technische Schwere (0-10)
  → EPSS Score: Exploitation-Wahrscheinlichkeit (0-100%)
  → CISA KEV:   aktiv in the wild exploited → IMMER Priorität 1!
  → Eigener Kontext:
    - Ist das System im Internet erreichbar? → multipliziert Risiko
    - Enthält das System sensitive Daten?
    - Gibt es eine Workaround/Mitigierung?

Phase 4: Patch-SLA (verbindliche Fristen)
  Critical (CVSS 9-10) + Extern:  24 Stunden
  Critical (CVSS 9-10) + Intern:  72 Stunden
  CISA KEV (beliebiger Score):     SOFORT, unabhängig von CVSS
  High (7-8) + Extern:            7 Tage
  High (7-8) + Intern:            14 Tage
  Medium (4-6):                   30 Tage
  Low (0-3):                      90 Tage oder dokumentierte Akzeptanz

Phase 5: Patch-Testen
  → Nie direkt in Produktion! (außer Emergency-Patches nach Bewertung)
  → Test-Umgebung: representativer Subset der Produktionsumgebung
  → Automated Tests: CI/CD Pipeline prüft Funktionalität nach Patch
  → Rollback-Plan: IMMER vor Patch-Deployment erstellen!

Phase 6: Deployment
  → Patch-Fenster: geplante Wartungsfenster (Produktion: nachts/Wochenende)
  → Staging → Canary (5% der Systeme) → Full Rollout
  → Monitoring: nach Patch-Deployment erhöhte Aufmerksamkeit

Phase 7: Verifikation
  → Rescan nach Patch: CVE tatsächlich behoben?
  → Vulnerability-Scanner: Finding verschwindet?
  → Compliance-Check: Patch-SLA eingehalten?

Windows-Umgebungen patchen

Microsoft WSUS (Windows Server Update Services):

Kostenlos, on-premises, für reine Windows-Umgebungen:

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

  WSUS-Gruppen empfehlen:
  → "Pilot-PCs" (10-20 Geräte)
  → "Produktions-Server"
  → "Domain Controller" (extra Vorsicht!)
  → "Workstations"

WSUS-Policy (GPO):
  Computer Configuration → Administrative Templates →
  Windows Components → Windows Update
  → Configure Automatic Updates: 4 (Download and schedule install)
  → Specify intranet MS update service: http://wsus-server:8530
  → Automatic update schedule: 0200 UTC Sonntag

Deployment-Strategie:
  Woche 1: Pilot-Gruppe (kritische Patches testen)
  Woche 2: Breiterer Test (10% der Workstations)
  Woche 3: Vollständige Workstations
  Woche 4: Server (in Wartungsfenster!)
  Exception: CISA KEV → direkt in Phase Server!

---

Microsoft Endpoint Configuration Manager (MECM/SCCM):
  → Vollständige Enterprise-Lösung (WSUS + Deployment + Reporting)
  → Software Update Point konfigurieren
  → Automatic Deployment Rules (ADR) für monatliche Patches
  → Maintenance Windows per Collection

Microsoft Intune (Cloud-nativ, Hybrid):
  → Managed über Azure Portal
  → Update Rings:
    - Ring 0: IT-Admins (sofort)
    - Ring 1: Pilot-User (7 Tage nach Release)
    - Ring 2: Broad Deployment (21 Tage)
    - Ring 3: Latecomer (35 Tage, noch nicht ausgerollt)
  → Feature Updates: Separate Update-Policy für OS-Versionen

Monitoring Windows Patch Status:
  PowerShell (lokale Überprüfung):
  Get-HotFix | Sort-Object InstalledOn -Descending | Select -First 10

  Systemweite Compliance:
  Get-WmiObject -Class Win32_QuickFixEngineering |
    Where-Object {$_.InstalledOn -lt (Get-Date).AddDays(-30)} |
    Measure-Object

Linux-Umgebungen patchen

Linux Patch Management:

Debian/Ubuntu (apt):
  # Sicherheitsupdates ohne Interaktion:
  apt-get update && apt-get upgrade -y --security-only

  Unattended Upgrades (automatisch):
  apt install unattended-upgrades
  # /etc/apt/apt.conf.d/50unattended-upgrades:
  Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
  };
  Unattended-Upgrade::Automatic-Reboot "false";  # Reboot manuell planen!
  Unattended-Upgrade::Mail "sicherheit@firma.de";

RHEL/CentOS/Rocky (dnf/yum):
  # Nur Security-Patches:
  dnf update --security -y

  # Was würde geupdated werden?
  dnf updateinfo list security

  # Automatisch (dnf-automatic):
  dnf install dnf-automatic
  # /etc/dnf/automatic.conf:
  [commands]
  apply_updates = yes
  upgrade_type = security

---

Ansible für skalierbares Linux-Patching:

# patch-servers.yml
---
- name: Patch Linux Servers
  hosts: all
  become: yes
  tasks:
    - name: Update apt cache (Debian/Ubuntu)
      apt:
        update_cache: yes
        cache_valid_time: 3600
      when: ansible_os_family == 'Debian'

    - 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

    - name: Check if reboot required (Ubuntu)
      stat:
        path: /var/run/reboot-required
      register: reboot_required
      when: ansible_os_family == 'Debian'

  handlers:
    - name: Check if reboot required
      debug:
        msg: "REBOOT REQUIRED on {{ inventory_hostname }}"

# Ausführen:
# ansible-playbook -i inventory.ini patch-servers.yml --limit staging
# ansible-playbook -i inventory.ini patch-servers.yml --limit production

Cloud-Umgebungen patchen

AWS Patch Management (AWS Systems Manager):

SSM Patch Manager:
  1. Patch Baseline erstellen (welche Patches automatisch?):
     aws ssm create-patch-baseline \
       --name "AWARE7-Linux-Security-Baseline" \
       --operating-system "AMAZON_LINUX_2" \
       --approval-rules \
         'PatchRules=[{PatchFilterGroup:{PatchFilters:[
           {Key=SEVERITY,Values=[Critical,High]},
           {Key=CLASSIFICATION,Values=[Security]}]},
           AutoApproveAfterDays=7}]'

  2. Patch Group: EC2-Instanzen via Tag zuordnen
     Tag: "Patch Group" = "production-servers"

  3. Maintenance Window:
     aws ssm create-maintenance-window \
       --name "Sunday-Night-Patching" \
       --schedule "cron(0 2 ? * SUN *)" \
       --duration 4 \
       --cutoff 1

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

Azure Update Manager:
  → Azure Portal: Update Manager → Patch Management
  → Assessment: sofortige Patch-Statusprüfung
  → Maintenance Schedule: Patch-Fenster konfigurieren
  → Compliance Dashboard: welche VMs nicht gepatcht?

Container-Patching (Docker):
  → Basis-Images immer aktuell: FROM ubuntu:22.04 (nie :latest!)
  → Trivy-Scan im CI: verhindert vulnerable Images in Produktion
  → Rebuild-Strategie: Images wöchentlich neu bauen (nicht nur Code-Änderungen)
  → Registry-Scan: AWS ECR Inspector, Google Artifact Analysis

Notfall-Patching (Emergency Patch Process)

Wenn CISA KEV oder CVSS 9-10 + aktiv exploited:

Trigger: BSI-Warnung OR CISA KEV Addition OR Aktiver Angriff

Schritt 1: Exposure-Assessment (0-2h)
  → Haben wir die betroffene Software? (SBOM, Asset-Inventar)
  → Wo ist sie im Einsatz? (Internet-exponiert?)
  → Gibt es Workarounds? (WAF-Rule, Feature-Disable, Firewall-Block)
  → Ist aktiver Exploit im Einsatz? (Threat Intel, BSI)

Schritt 2: Entscheidung (2-4h)
  Option A: Sofort-Patch (Testing verkürzt auf < 2h)
  Option B: Workaround + geplanter Patch (wenn Patch nicht verfügbar)
  Option C: System offline nehmen (wenn Risiko untragbar)
  Genehmigung: CISO (oder Vertreter) muss Entscheidung abzeichnen

Schritt 3: Beschleunigter Rollout
  → Test: minimaler Funktionstest (nicht vollständige Test-Suite)
  → Parallel patchen statt sequentiell
  → Monitoring erhöhen während Deployment

Schritt 4: Dokumentation (immer!)
  → Was war die Schwachstelle (CVE)?
  → Wann erkannt, wann gepatcht?
  → War Exploit aktiv bevor Patch?
  → Abschluss-Bestätigung: Vulnerability im Rescan nicht mehr sichtbar

Kommunikation bei Notfall-Patch:
  → IT-Team: sofortige Slack/Teams-Nachricht
  → Betroffene Fachbereiche: geplante Downtime ankündigen
  → Management: kurze Zusammenfassung (Risiko, Maßnahme, Status)
  → CISO: Genehmigung und Information

Compliance-Anforderungen

Regulatorische Patch-Pflichten:

ISO 27001:
  A.8.8: Management technischer Schwachstellen
  → Schriftliche Patch-Management-Richtlinie
  → Nachweisbare SLAs und Compliance-Tracking
  → 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: Patch- und Änderungsmanagement
  → Patches unverzüglich einspielen
  → Dokumentierte Testverfahren
  → Rollback-Möglichkeit nachweisbar

KRITIS (§8a BSIG):
  → Stand der Technik für kritische Systeme
  → Audit alle 2 Jahre (durch zugelassene Stellen)
  → Patch-Prozess Teil des ISMS-Nachweises

PCI DSS v4 (Anforderung 6.3):
  → Critical patches: within 1 month of release
  → All other patches: within 3 months
  → Formaler Change-Management-Prozess

Dokumentation für Audits:
  □ Patch-Policy-Dokument (SLAs, Prozess, Rollen)
  □ Asset-Inventar mit Patch-Stand
  □ Monatliche Patch-Compliance-Reports
  □ Ausnahmegenehmigungen mit Begründung
  □ Evidence: Vulnerability-Scanner-Reports vor/nach Patch
  □ Emergency-Patch-Protokolle