Ein ungepatchtes System ist nicht automatisch unsicher. Eine bekannte, ausnutzbare Schwachstelle auf einem öffentlich erreichbaren und geschäftskritischen System kann dagegen innerhalb kürzester Zeit zu einem erheblichen Sicherheitsrisiko werden.

Genau deshalb gehört professionelles Patch- und Schwachstellenmanagement zu den zentralen Bausteinen einer widerstandsfähigen IT-Infrastruktur.

Dabei geht es um wesentlich mehr als:

„Jeden Dienstag Windows Updates installieren.“

Organisationen benötigen einen geregelten Prozess, mit dem Schwachstellen erkannt, bewertet, priorisiert, getestet, behoben und dokumentiert werden. Gleichzeitig muss berücksichtigt werden, dass sich nicht jedes Update sofort installieren lässt.

Im Rahmen von NIS-2 wird daraus eine dauerhafte Aufgabe:

Erkennen → Bewerten → Priorisieren → Testen → Patchen → Prüfen → Dokumentieren

Patchmanagement und Schwachstellenmanagement sind nicht dasselbe

Die Begriffe werden häufig synonym verwendet, beschreiben aber unterschiedliche Aufgaben.

Patchmanagement

Patchmanagement beschäftigt sich mit der kontrollierten Bereitstellung und Installation von Aktualisierungen.

Dazu gehören beispielsweise:

• Betriebssystemupdates,
• Sicherheitsupdates,
• Firmwareupdates,
• Anwendungsupdates,
• Treiberupdates,
• Hotfixes,
• Browserupdates,
• Updates von Netzwerkkomponenten.

Schwachstellenmanagement

Schwachstellenmanagement beginnt früher und geht weiter.

Es beschäftigt sich mit der Frage:

Welche Schwachstellen existieren in unserer Infrastruktur und welches Risiko entsteht daraus?

Dazu gehören unter anderem:

• Schwachstellen erkennen,
• CVEs auswerten,
• betroffene Systeme identifizieren,
• Risiken bewerten,
• Maßnahmen priorisieren,
• Patches oder Workarounds einspielen,
• Ergebnisse kontrollieren,
• Ausnahmen dokumentieren.

Patchmanagement ist damit ein wichtiger Bestandteil des umfassenderen Schwachstellenmanagements.

1. Grundlage: Wissen, welche Systeme vorhanden sind

Bevor eine Organisation Schwachstellen verwalten kann, muss sie wissen, welche Systeme überhaupt existieren.

Das klingt selbstverständlich, ist in der Praxis aber häufig eine der größten Herausforderungen.

Ein Asset-Inventar sollte beispielsweise enthalten:

• Server,
• Clients,
• virtuelle Maschinen,
• Netzwerkgeräte,
• Firewalls,
• Switches,
• Access Points,
• Drucker,
• Storage-Systeme,
• Anwendungen,
• Datenbanken,
• Container,
• Cloud-Dienste,
• mobile Geräte,
• Firmwarestände.

Zu jedem Asset sollten mindestens Betriebssystem beziehungsweise Softwareversion, Verantwortlichkeit, Kritikalität und Patchstatus bekannt sein.

Ein Schwachstellenscanner kann schließlich nur bekannte oder erreichbare Systeme überprüfen.

Ein vergessenes System verschwindet deshalb nicht aus der Infrastruktur.

Es verschwindet lediglich aus der Aufmerksamkeit der IT.

2. Einen verbindlichen Patchprozess definieren

Updates sollten nicht ausschließlich nach individuellem Ermessen einzelner Administratoren installiert werden.

Stattdessen benötigt die Organisation einen standardisierten Prozess.

Ein möglicher Ablauf sieht folgendermaßen aus:

Neue Schwachstelle / Update
          │
          ▼
Betroffenheit prüfen
          │
          ▼
Risiko bewerten
          │
          ▼
Priorisieren
          │
          ▼
Patch testen
          │
          ▼
Freigabe
          │
          ▼
Produktiv installieren
          │
          ▼
Funktion kontrollieren
          │
          ▼
Schwachstelle erneut prüfen
          │
          ▼
Dokumentieren

Dabei müssen Verantwortlichkeiten eindeutig geregelt sein.

Beispielsweise:

IT-Security

bewertet Schwachstellen und Bedrohungen.

Systemadministration

testet und installiert Updates.

Anwendungsverantwortliche

prüfen die Funktionsfähigkeit der Anwendung.

Informationssicherheitsverantwortliche

überwachen Prozesse und Ausnahmen.

Je nach Größe der Organisation können mehrere dieser Rollen selbstverständlich von denselben Personen wahrgenommen werden.

Entscheidend ist nicht die Anzahl der Beteiligten, sondern die klare Zuordnung der Verantwortung.

3. CVEs verstehen

Eine zentrale Rolle im Schwachstellenmanagement spielen CVEs.

CVE steht für:

Common Vulnerabilities and Exposures

Bekannte Schwachstellen erhalten eindeutige Kennungen.

Ein Beispiel sieht folgendermaßen aus:

CVE-2026-12345

Dabei bezeichnet 2026 das Jahr der Vergabe beziehungsweise Reservierung im CVE-System und die folgende Nummer identifiziert den Eintrag.

Der große Vorteil:

Hersteller, Sicherheitsforscher, Schwachstellenscanner und Administratoren können eindeutig über dieselbe Schwachstelle sprechen.

Eine CVE-ID bedeutet allerdings noch nicht automatisch, dass ein System akut gefährdet ist.

Dazu müssen weitere Faktoren berücksichtigt werden.

4. CVSS – Wie gefährlich ist eine Schwachstelle?

Zur technischen Bewertung von Schwachstellen wird häufig das Common Vulnerability Scoring System (CVSS) verwendet.

Das Ergebnis liegt grundsätzlich zwischen:

0,0 und 10,0

Je höher der Wert, desto schwerwiegender wird die Schwachstelle technisch bewertet.

Typischerweise werden Werte beispielsweise folgendermaßen kategorisiert:

0,0          Keine
0,1 – 3,9    Niedrig
4,0 – 6,9    Mittel
7,0 – 8,9    Hoch
9,0 – 10,0   Kritisch

Ein CVSS-Wert von 9,8 sorgt deshalb verständlicherweise für Aufmerksamkeit.

Trotzdem sollte daraus nicht automatisch folgen:

„9,8? Sofort alles stehen und liegen lassen!“

CVSS beschreibt technische Eigenschaften einer Schwachstelle. Für die tatsächliche Priorisierung muss zusätzlich der Kontext der eigenen Infrastruktur betrachtet werden.

5. Schwachstellen risikobasiert priorisieren

Stellen wir uns zwei Systeme vor.

System A

Ein interner Testserver besitzt eine Schwachstelle mit CVSS 9,8.

Der Server:

• enthält keine produktiven Daten,
• ist nur aus einem isolierten Testnetz erreichbar,
• besitzt keine Internetverbindung.

System B

Ein öffentlich erreichbarer VPN-Gateway besitzt eine Schwachstelle mit CVSS 8,1.

Für die Schwachstelle:

• existiert bereits Exploit-Code,
• werden aktive Angriffe beobachtet,
• das System stellt einen Zugang zum internen Netzwerk bereit.

Welches System sollte zuerst gepatcht werden?

Sehr wahrscheinlich System B.

Genau hier liegt der Unterschied zwischen reinem Patchmanagement und risikobasiertem Schwachstellenmanagement.

Bei der Priorisierung sollten beispielsweise berücksichtigt werden:

• CVSS-Wert,
• Internet-Erreichbarkeit,
• aktive Ausnutzung,
• vorhandener Exploit,
• Kritikalität des Systems,
• gespeicherte Daten,
• mögliche Auswirkungen,
• vorhandene Schutzmaßnahmen,
• Netzwerksegmentierung,
• Bedeutung für Geschäftsprozesse.

Damit entsteht eine deutlich realistischere Risikobewertung.

6. Aktiv ausgenutzte Schwachstellen besonders beachten

Eine Schwachstelle wird besonders interessant, wenn sie tatsächlich von Angreifern verwendet wird.

Deshalb sollten Organisationen nicht ausschließlich auf CVSS-Werte schauen.

Eine wichtige Informationsquelle ist beispielsweise der von der US-amerikanischen Cybersecurity and Infrastructure Security Agency gepflegte Known Exploited Vulnerabilities Catalog, kurz KEV.

Dort werden Schwachstellen aufgeführt, für die eine tatsächliche Ausnutzung bekannt ist.

Für die Priorisierung kann deshalb eine einfache Regel lauten:

Bekannte aktive Ausnutzung + betroffenes eigenes System = hohe Priorität.

Zusätzlich sollten Herstellerwarnungen, CERT-Meldungen und Informationen nationaler Sicherheitsbehörden in das Schwachstellenmanagement einbezogen werden.

7. Schwachstellenscanner einsetzen

In größeren IT-Infrastrukturen ist eine manuelle Suche nach Schwachstellen kaum realistisch.

Hier kommen Vulnerability Scanner zum Einsatz.

Bekannte Lösungen beziehungsweise Plattformen sind beispielsweise:

• Greenbone/OpenVAS,
• Tenable Nessus,
• Tenable Vulnerability Management,
• Rapid7 InsightVM,
• Qualys VMDR.

Solche Systeme untersuchen Netzwerkgeräte, Server und andere Assets auf bekannte Schwachstellen und Fehlkonfigurationen.

Ein Scan könnte beispielsweise feststellen:

Server: srv-web-01
IP: 10.20.30.15

Kritisch:  1
Hoch:      4
Mittel:   12
Niedrig:  18

Damit beginnt allerdings erst die eigentliche Arbeit.

Denn:

100 gefundene Schwachstellen bedeuten nicht automatisch 100 reale Sicherheitsprobleme gleicher Priorität.

Ergebnisse müssen bewertet und gegebenenfalls auf False Positives geprüft werden.

8. Authentifizierte Scans verwenden

Ein Netzwerk-Scan von außen sieht nur einen Teil eines Systems.

Deutlich mehr Informationen können Schwachstellenscanner erhalten, wenn sie authentifiziert arbeiten dürfen.

Dann können beispielsweise überprüft werden:

• installierte Pakete,
• Softwareversionen,
• Registry-Einstellungen,
• lokale Konfigurationen,
• fehlende Updates,
• Sicherheitsrichtlinien.

Dadurch steigt die Qualität der Ergebnisse erheblich.

Die für solche Scans verwendeten Zugangsdaten müssen allerdings besonders geschützt werden.

Ein Scanner mit administrativen Zugangsdaten zu hunderten Servern ist selbst ein hochwertiges Ziel für Angreifer.

9. Testsysteme und Patch-Ringe

Updates direkt nach Veröffentlichung auf allen Produktivsystemen zu installieren, kann ebenfalls Risiken verursachen.

Ein fehlerhaftes Update kann Anwendungen beeinträchtigen oder ganze Systeme unbrauchbar machen.

Deshalb bietet sich ein gestuftes Verfahren an.

Beispielsweise:

Hersteller veröffentlicht Update
             │
             ▼
        Testsysteme
             │
             ▼
      Pilot-Systeme
             │
             ▼
   Produktivsysteme Gruppe 1
             │
             ▼
   Produktivsysteme Gruppe 2

Dabei spricht man häufig von Deployment Rings beziehungsweise Patch-Ringen.

Ein einfaches Modell könnte aus drei Stufen bestehen:

Ring 0 – Test

IT-Testsysteme und Laborsysteme.

Ring 1 – Pilot

Ausgewählte produktionsnahe Systeme mit überschaubarem Risiko.

Ring 2 – Produktion

Breiter Rollout auf die verbleibenden Systeme.

Damit lassen sich Probleme frühzeitig erkennen.

Aber was passiert bei einer Zero-Day-Lücke?

Ein umfangreicher Testprozess darf nicht dazu führen, dass eine akut ausgenutzte kritische Schwachstelle wochenlang ungepatcht bleibt.

Deshalb benötigt das Patchmanagement einen Emergency-Patch-Prozess.

Dieser könnte beispielsweise greifen bei:

• aktiv ausgenutzten Schwachstellen,
• kritischen Zero-Day-Lücken,
• öffentlich erreichbaren verwundbaren Systemen,
• akuter Ransomware-Gefahr,
• Warnungen der zuständigen Sicherheitsbehörden.

In solchen Fällen können verkürzte Tests und beschleunigte Freigaben erforderlich sein.

Die Entscheidung und das daraus resultierende Risiko sollten dokumentiert werden.

10. Patchfristen definieren

Organisationen sollten interne Fristen für die Behandlung von Schwachstellen festlegen.

Ein beispielhaftes Modell könnte lauten:

Kritisch

Behandlung innerhalb von 72 Stunden.

Hoch

Behandlung innerhalb von 7 Tagen.

Mittel

Behandlung innerhalb von 30 Tagen.

Niedrig

Behandlung innerhalb von 90 Tagen.

Diese Werte sind keine pauschalen NIS-2-Fristen, sondern ein Beispiel für eine interne Richtlinie.

Die tatsächlich angemessenen Fristen hängen von Risiko, Infrastruktur und Organisation ab.

Bei einer aktiv ausgenutzten Schwachstelle können selbst 72 Stunden zu lang sein.

Deshalb sollte zusätzlich eine Eskalationsregel existieren.

11. Wenn kein Patch verfügbar ist

Nicht jede Schwachstelle lässt sich sofort durch ein Update schließen.

Möglicherweise:

• existiert noch kein Patch,
• ist der Patch fehlerhaft,
• unterstützt der Hersteller die Anwendung nicht mehr,
• verhindert eine Fachanwendung das Update,
• würde ein Update den Betrieb gefährden.

Dann sind kompensierende Maßnahmen erforderlich.

Beispiele:

• gefährdeten Dienst deaktivieren,
• Port über Firewall sperren,
• System vom Internet trennen,
• Zugriff auf bestimmte Netze begrenzen,
• WAF-Regel einsetzen,
• gefährdete Funktion deaktivieren,
• zusätzliche Überwachung aktivieren.

Das Risiko verschwindet dadurch möglicherweise nicht vollständig.

Es wird jedoch reduziert, bis eine dauerhafte Lösung verfügbar ist.

12. Rollback vorbereiten

Jedes größere Update kann Probleme verursachen.

Deshalb gehört zu einem professionellen Patchprozess auch die Frage:

Wie kommen wir zurück?

Vor kritischen Updates können beispielsweise notwendig sein:

• aktuelles Backup,
• VM-Snapshot,
• Konfigurationssicherung,
• Datenbanksicherung,
• dokumentierte Deinstallationsmöglichkeit,
• Wiederherstellungsplan.

Dabei ist wichtig:

Ein Snapshot ist kein Ersatz für ein Backup.

Er kann jedoch bei bestimmten Wartungsarbeiten eine schnelle Rückkehr zum vorherigen Zustand ermöglichen.

Vor dem Patch sollte außerdem klar sein:

Wann wird ein Rollback ausgelöst?
Wer entscheidet darüber?
Wie wird zurückgerollt?
Wie lange dauert die Wiederherstellung?

Diese Fragen erst während eines fehlgeschlagenen Updates zu diskutieren, kostet wertvolle Zeit.

13. End-of-Life-Systeme sind ein besonderes Risiko

Ein Server kann vollständig gepatcht sein und trotzdem unsicher werden.

Nämlich dann, wenn der Hersteller keine Sicherheitsupdates mehr veröffentlicht.

Beispiele sind:

• veraltete Windows-Versionen,
• alte Linux-Distributionen,
• nicht mehr unterstützte Appliances,
• alte Datenbanken,
• veraltete Netzwerkgeräte,
• Legacy-Fachanwendungen.

Deshalb sollte das Asset Management auch Informationen über den Supportzeitraum enthalten:

Produkt
Version
Support-Ende
Extended Support
Geplante Ablösung
Verantwortlicher

End-of-Life-Systeme sollten nicht überraschend auftauchen.

Ihre Ablösung sollte möglichst Monate oder Jahre vorher geplant werden.

14. Erfolg des Patchens überprüfen

Ein häufiger Fehler lautet:

Update verteilt = Aufgabe erledigt.

Doch vielleicht ist die Installation auf 15 Prozent der Systeme fehlgeschlagen.

Deshalb muss nach dem Rollout überprüft werden:

• Wurde der Patch installiert?
• Ist die richtige Version vorhanden?
• Funktioniert das System?
• Ist die Schwachstelle tatsächlich geschlossen?
• Gibt es fehlgeschlagene Installationen?

Ein erneuter Schwachstellenscan kann dabei helfen.

Der vollständige Kreislauf lautet deshalb:

Scan
  ↓
Schwachstelle
  ↓
Bewertung
  ↓
Patch
  ↓
Kontrolle
  ↓
Re-Scan
  ↓
geschlossen

Erst dann sollte ein Finding als erledigt gelten.

15. Dokumentation – aus Technik wird ein Prozess

Gerade im Zusammenhang mit NIS-2 ist die Dokumentation entscheidend.

Eine Organisation sollte nachvollziehen können:

Was wurde erkannt?

Wie wurde es bewertet?

Was wurde dagegen unternommen?

Ein Schwachstellenregister könnte beispielsweise folgende Informationen enthalten:

CVE
Betroffenes Asset
Erkennungsdatum
CVSS
Kritikalität des Assets
Aktive Ausnutzung
Risikoeinstufung
Verantwortlicher
Maßnahme
Frist
Status
Abschlussdatum

Damit lässt sich später nachvollziehen, wie mit einer konkreten Schwachstelle umgegangen wurde.

Ausnahmen dokumentieren

Besonders wichtig ist der Umgang mit nicht behobenen Schwachstellen.

Beispiel:

Ein kritischer Server besitzt eine bekannte Schwachstelle. Der Hersteller der eingesetzten Fachanwendung hat den aktuellen Betriebssystem-Patch jedoch noch nicht freigegeben.

Die Lösung sollte nicht sein:

„Dann patchen wir eben nicht.“

Stattdessen sollte dokumentiert werden:

Schwachstelle erkannt
        ↓
Patch aktuell nicht möglich
        ↓
Risiko bewertet
        ↓
Kompensierende Maßnahmen
        ↓
Verantwortlicher benannt
        ↓
Ablaufdatum der Ausnahme
        ↓
Erneute Bewertung

Ausnahmen sollten immer zeitlich begrenzt sein.

Sonst wird aus einer „temporären Ausnahme“ schnell eine fünf Jahre alte Dauerlösung.

Kennzahlen für das Schwachstellenmanagement

Ein gut organisierter Prozess lässt sich messen.

Sinnvolle Kennzahlen können beispielsweise sein:

• Anzahl kritischer Schwachstellen,
• Anzahl überfälliger Schwachstellen,
• durchschnittliche Behebungszeit,
• Patch-Compliance,
• Anteil ungepatchter Systeme,
• Anzahl End-of-Life-Systeme,
• Anzahl aktiver Ausnahmen,
• Erfolgsquote von Patch-Deployments.

Eine besonders interessante Kennzahl ist die Mean Time to Remediate (MTTR).

Sie beschreibt vereinfacht, wie lange eine Organisation benötigt, um erkannte Schwachstellen zu beseitigen.

Die reine Anzahl gefundener Schwachstellen ist dagegen nur begrenzt aussagekräftig.

Ein Scanner, der plötzlich doppelt so viele Schwachstellen findet, muss nicht bedeuten, dass die Infrastruktur unsicherer geworden ist.

Vielleicht scannt er einfach besser.

Praktische NIS-2-Checkliste

Für ein funktionierendes Patch- und Schwachstellenmanagement sollten mindestens folgende Fragen beantwortet werden können:

Organisation

☐ Gibt es einen dokumentierten Patchprozess?

☐ Sind Verantwortlichkeiten definiert?

☐ Gibt es verbindliche Prioritäten und interne Fristen?

☐ Existiert ein Emergency-Patch-Verfahren?

Assets

☐ Sind alle relevanten Systeme inventarisiert?

☐ Sind Betriebssystem- und Softwareversionen bekannt?

☐ Werden Support- und End-of-Life-Zeiträume überwacht?

Schwachstellen

☐ Werden CVEs regelmäßig ausgewertet?

☐ Werden aktiv ausgenutzte Schwachstellen berücksichtigt?

☐ Gibt es regelmäßige Schwachstellenscans?

☐ Werden Findings risikobasiert priorisiert?

Updates

☐ Existieren Test- und Pilotgruppen?

☐ Werden Updates vor dem breiten Rollout getestet?

☐ Gibt es einen Rollback-Plan?

☐ Wird die erfolgreiche Installation kontrolliert?

Ausnahmen

☐ Werden nicht patchbare Systeme dokumentiert?

☐ Wird das verbleibende Risiko bewertet?

☐ Werden kompensierende Maßnahmen definiert?

☐ Haben Ausnahmen ein Ablaufdatum?

Nachweis

☐ Werden Scanergebnisse dokumentiert?

☐ Werden durchgeführte Maßnahmen nachvollziehbar festgehalten?

☐ Werden Systeme nach der Behebung erneut geprüft?

☐ Können Verantwortliche den aktuellen Patchstatus der Infrastruktur feststellen?

Patch- und Schwachstellenmanagement bedeutet im Rahmen von NIS-2 nicht, möglichst schnell jedes verfügbare Update zu installieren.

Entscheidend ist vielmehr ein kontrollierter und risikobasierter Prozess.

Organisationen müssen wissen, welche Systeme sie betreiben, welche Schwachstellen diese Systeme besitzen und welche davon tatsächlich eine Gefahr darstellen.

CVEs und CVSS liefern wichtige technische Informationen. Aktive Ausnutzung, Internet-Erreichbarkeit, Kritikalität eines Systems und mögliche Auswirkungen bestimmen jedoch maßgeblich die tatsächliche Priorität.

Schwachstellenscanner schaffen Transparenz. Testsysteme und Patch-Ringe reduzieren Betriebsrisiken. Rollback-Pläne sorgen dafür, dass fehlgeschlagene Updates beherrschbar bleiben. Und eine saubere Dokumentation macht Entscheidungen später nachvollziehbar.

Der wichtigste Grundsatz lautet:

Nicht jede Schwachstelle ist gleich gefährlich – aber jede bekannte Schwachstelle braucht eine Entscheidung.

Ein funktionierender Prozess endet deshalb nicht beim Patch:

Erkennen → Bewerten → Priorisieren → Testen → Beheben → Kontrollieren → Dokumentieren → erneut prüfen.

Damit entwickelt sich Patchmanagement von einer administrativen Routine zu einem zentralen Bestandteil des kontinuierlichen Cyber-Risikomanagements.