Patch Management

Bekannte, gepatchte Schwachstellen sind für die überwiegende Mehrheit erfolgreicher Cyberangriffe verantwortlich. Das klingt paradox: Wenn ein Patch verfügbar ist, sollte das Problem doch gelöst sein. Die Realität in Unternehmensumgebungen sieht anders aus. Patch-Zyklen dauern Wochen oder Monate. Systemabhängigkeiten verzögern Updates. OT-Systeme können nicht einfach neu gestartet werden. Legacy-Systeme werden nicht mehr unterstützt. Und in vielen Organisationen fehlt der vollständige Überblick, welche Systeme überhaupt existieren.

Die Zahlen sind eindeutig: Laut Verizon Data Breach Investigations Report werden 40-60 % aller Datenpannen durch bekannte Schwachstellen verursacht, für die Patches bereits verfügbar waren. Das bedeutet: Ein erheblicher Teil der Security-Investitionen wird durch fehlende Grunddisziplin beim Patch Management aufgezehrt. Wer Sicherheit wirklich verbessern will, muss hier beginnen.

Die Herausforderung ist nicht mangelndes Bewusstsein, sondern fehlende Prozesse. In den meisten Unternehmen fehlt die strukturierte Kombination aus: vollständiger Asset-Inventarisierung, automatisiertem Schwachstellenscan, risikobasierter Priorisierung, definierten SLAs, Staging-Umgebungen für Tests, kontrolliertem Rollout und Nachverfolgung. Einzelne dieser Elemente existieren oft – das strukturelle Zusammenspiel fehlt.

Der Patchstand ist die Momentaufnahme des aktuellen Patch-Status aller Systeme in einer IT-Umgebung: Welche Systeme haben welche Patches installiert, welche stehen aus, wie lange sind bekannte Lücken bereits offen? Ohne vollständige Sichtbarkeit über den Patchstand ist strukturiertes Patch Management nicht möglich – und Risikobewertungen bleiben spekulativ. Die erste Aufgabe in jedem Patch-Management-Projekt ist deshalb die Erhebung des Ist-Zustands: ein vollständiges Asset-Inventar kombiniert mit einem Schwachstellenscan, der für jeden Asset den aktuellen Patchstand ausweist.

Die Methoden zur Patchstand-Erhebung unterscheiden sich nach Infrastruktur und Betriebsmodell. Agentenbasiertes Scanning (Tenable Agent, Qualys Cloud Agent, Rapid7 Insight Agent) liefert kontinuierliche Patchstand-Daten direkt vom Endpunkt – auch für Systeme, die nicht dauerhaft im Netzwerk erreichbar sind (Laptops, Remote-Geräte, Cloud-Instanzen). Agentenloses Scanning via Netzwerkscans erfasst Systeme nach Erreichbarkeit, setzt aber offene Ports und entsprechende Credentials voraus. In heterogenen Umgebungen kombinieren wir beide Ansätze: agentenbasiert für Endgeräte und kritische Server, netzwerkbasiert für OT-Systeme, Netzwerkkomponenten und externe Assets. Das Ergebnis ist ein konsolidierter Patchstand-Report mit vollständiger Asset-Abdeckung.

Aus dem Patchstand lassen sich die zentralen Steuerungsmetriken eines Patch-Management-Programms ableiten: Mean Time to Remediate (MTTR) – wie lange dauert es durchschnittlich, eine bekannte Schwachstelle zu beheben? Patch Compliance Rate – welcher Anteil der Systeme erfüllt den definierten Patchstand für kritische, hohe und mittlere Schwachstellen? Vulnerability Age – wie viele Tage sind Schwachstellen im Durchschnitt offen? Diese Metriken sind nicht nur für das interne Reporting relevant, sondern explizit in regulatorischen Rahmenwerken verankert: ISO 27001 Annex A.8.8 fordert dokumentiertes Management technischer Schwachstellen, NIS2 Artikel 21 schreibt risikobasierte Maßnahmen vor, die eine messbare Patchstand-Überwachung voraussetzen. Auditoren fragen nicht nach dem Prozess – sie fragen nach dem Nachweis.

Ein wirksamer Patch-Management-Prozess beginnt mit vollständiger Asset-Sichtbarkeit: Man kann nicht patchen, was man nicht kennt. Wir stellen sicher, dass Ihre Systeminventarisierung vollständig und aktuell ist – ein kritischer Schritt, der in vielen Projekten mehr Aufwand erfordert als erwartet. Auf dieser Grundlage wird ein kontinuierlicher Schwachstellenscan aufgebaut, der neue CVEs in Ihrer Umgebung innerhalb von Stunden identifiziert.

Die Priorisierung der identifizierten Schwachstellen ist das Herzstück des Prozesses. CVSS-Scores alleine sind nicht ausreichend: Eine kritische Schwachstelle (CVSS 9.8) in einem System ohne Netzwerkzugang ist weniger dringlich als eine mittlere Schwachstelle (CVSS 6.5) in einem öffentlich erreichbaren Webserver. Wir priorisieren nach Kombination aus CVSS-Score, Verfügbarkeit von Exploits (EPSS), Asset-Kritikalität und tatsächlicher Erreichbarkeit.

Auf Basis dieser Priorisierung definieren wir SLA-Klassen: Kritisch (CVSS 9+, aktiv exploitiert): 24-72 Stunden. Hoch (CVSS 7-9): 7-14 Tage. Mittel: 30 Tage. Niedrig: 90 Tage. Diese SLAs werden in einem Patch-Governance-Prozess verankert, der Verantwortlichkeiten, Eskalationswege und Ausnahmegenehmigungen definiert.

Die Wahl der richtigen Tools ist abhängig von Ihrer Infrastruktur und Ihrem Betriebsmodell. Für Windows-lastige Umgebungen bieten Microsoft Endpoint Configuration Manager (MECM/SCCM) oder Intune strukturierte Patch-Verteilung mit Gruppen-basierten Rollout-Ringen. Für heterogene Linux/Windows-Umgebungen sind Ansible oder Puppet leistungsstarke Automatisierungsplattformen. Für kontinuierliches Schwachstellen-Scanning setzen wir je nach Anforderung auf Tenable, Qualys, Rapid7 oder OpenVAS.

Entscheidend ist die Integration dieser Tools in einen kohärenten Workflow: Schwachstellenscanner identifiziert neue CVEs, liefert Ergebnisse an eine zentrale VM-Plattform, diese priorisiert und erstellt Tickets (Jira, ServiceNow), Patch-Management-Tool verteilt Updates nach definierten Ring-Gruppen (Test, Pilot, Produktion), Scanner verifiziert nach Deployment die erfolgreiche Behebung. Dieser Kreislauf soll ohne manuelle Eingriffe laufen – Ausnahmen für Risikoentscheidungen ausgenommen.

Notfall-Patch-Prozesse sind ein oft vergessenes Element. Wenn Zero-Day-Schwachstellen oder aktiv ausgenutzte kritische CVEs bekannt werden – wie bei Log4Shell, ProxyLogon oder PrintNightmare –, reichen normale Patch-Zyklen nicht aus. Wir definieren klare Eskalationsprozesse und Notfall-Rollout-Verfahren, die eine Reaktionszeit von wenigen Stunden ermöglichen.