NIS2-Schwachstellenmanagement: Scans, Patches und Nachweise für Server und VMware-Hosts

Was NIS2 für das Schwachstellenmanagement verlangt

Das NIS2-Schwachstellenmanagement beruht auf Artikel 21 Absatz 2 Buchstabe e der NIS2-Richtlinie, der Richtlinie (EU) 2022/2555. Dieser nennt unter den Mindestmaßnahmen „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen“. Die Durchführungsverordnung (EU) 2024/2690 der Kommission führt das in Nummer 6.10 ihres Anhangs aus. Die betreffenden Einrichtungen im Sinne der Verordnung erlangen Informationen über technische Schwachstellen in ihren Systemen, bewerten ihre Exposition und „ergreifen geeignete Maßnahmen zum Umgang mit diesen Schwachstellen“. Sie verfolgen Sicherheitshinweise, führen soweit angemessen in geplanten Zeitabständen Schwachstellen-Scans durch, zeichnen die Ergebnisse auf und beheben Schwachstellen, die für ihren Betrieb kritisch sind, „unverzüglich“.

Zwei benachbarte Nummern vervollständigen die Anforderung. Nummer 6.6 regelt das Sicherheitspatch-Management, und Nummer 6.5 verlangt ein Konzept und Verfahren für Sicherheitsprüfungen. Keine der drei Nummern legt eine Scan-Häufigkeit oder eine Patch-Frist in Tagen fest. Die Einrichtung legt ihre geplanten Zeitabstände und internen Zielzeiten in ihrem Konzept fest. Nummer 6.5.2 Buchstabe a knüpft die Häufigkeit der Sicherheitsprüfungen an die Risikobewertung.

Alle zehn Maßnahmen behandelt unser Leitfaden zu den Sicherheitsmaßnahmen nach NIS2 Artikel 21; dieser Artikel behandelt Buchstabe e für eine Umgebung mit 10 bis 60 VMware-Hosts und 500 bis 2.000 VMs.

Wen die Durchführungsverordnung 2024/2690 bindet

Die Verordnung bindet nur die „betreffenden Einrichtungen“ ihres Artikels 1. Das sind DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten und Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, von Online-Suchmaschinen und von Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter. Andere wesentliche und wichtige Einrichtungen haben ihre Pflichten aus Artikel 21 über das nationale Gesetz, das die Richtlinie umsetzt, und können den Anhang als detaillierte Referenz auf EU-Ebene nutzen, auch wenn er sie nicht bindet. Die NIS2 Technical Implementation Guidance der ENISA, veröffentlicht am 26. Juni 2025, folgt dem Anhang Anforderung für Anforderung.

Ihr Managed-Service-Anbieter kann unmittelbar gebunden sein. Nummer 5.1.4 Buchstabe f nennt für Verträge mit Lieferanten außerdem „eine Verpflichtung der Anbieter und Diensteanbieter zur Behebung von Schwachstellen“, die ein Risiko für die Systeme der Einrichtung darstellen. Was Kunden von ihren IT-Lieferanten verlangen, beschreibt unser Leitfaden zur Sicherheit der Lieferkette nach NIS2. Ob Ihr Unternehmen eine wesentliche oder wichtige Einrichtung ist, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Nummern 6.10, 6.6 und 6.5: Umsetzung und Nachweise

Jede Zeile nennt eine Anforderung des Anhangs, eine Umsetzung in einer VMware-Umgebung und den Nachweis, den ein Auditor verlangen kann.

Durchführungsverordnung (EU) 2024/2690, Anhang, Nummern 5.1.4, 6.5, 6.6 und 6.10 (eur-lex.europa.eu, abgerufen am 6. und 10. Oktober 2026). Die Spalten Umsetzung und Nachweis sind unsere Zusammenfassung für eine VMware-Umgebung.

Unser Assessment zur Cyber-Resilienz prüft Infrastruktur, Zugriffe, Backups und die Einhaltung der NIS2-Anforderungen und endet mit einer Risikokarte und einem priorisierten Maßnahmenplan. Schreiben Sie uns, wie Sie heute scannen und patchen und welche Aufzeichnungen Sie bereits führen.

Anlageninventar und Scan-Umfang für 10 bis 60 VMware-Hosts

Das Scannen beginnt beim Anlagen- und Werteinventar, das Nummer 12.4.1 als „vollständiges, genaues, aktuelles und kohärentes Inventar“ verlangt. Sicherheitshinweise werden mit diesem Inventar abgeglichen, sodass ein System, das darin fehlt, beim Abgleich unberücksichtigt bleibt. Für eine VMware-Umgebung führt das Inventar jede vCenter-Instanz und jeden ESXi-Host mit seiner Build-Nummer sowie die Management-Controller der Server mit ihrer Firmware. Es enthält außerdem die VMs mit ihren Betriebssystemen und Verantwortlichen, den Backup-Server, die Firewalls und die Switches.

Der Scan-Umfang hat drei Ebenen. Gastbetriebssysteme auf 500 bis 2.000 VMs werden mit Zugangsdaten gescannt, weil ein authentifizierter Scan installierte Pakete und fehlende Patches ausliest, die ein Netzwerkscan von außerhalb des Gastsystems nicht zuverlässig erkennt. Das Verwaltungsnetz, in dem vCenter, die ESXi-Hosts und die Management-Controller liegen, wird per Netzwerkscan von einem Scanner geprüft, der in diesem Netz steht. Für ESXi und vCenter vergleichen Sie jede Build-Nummer mit der Response Matrix jedes relevanten Sicherheitshinweises von Broadcom, unabhängig davon, was der Scanner meldet. Die Konten des Scanners sind privilegierte Konten und unterliegen den Kontrollen, die unser Leitfaden zu Privileged Access Management beschreibt.

Ein Unternehmen dieser Größe kann einen monatlichen authentifizierten Scan aller VMs festlegen, einen wöchentlichen Scan der aus dem Internet erreichbaren Systeme und eine Build-Prüfung von ESXi und vCenter, sobald Broadcom einen Sicherheitshinweis veröffentlicht. Schreiben Sie den Plan in das Konzept und bewahren Sie jeden datierten Bericht auf, denn nach Nummer 6.10.2 Buchstabe b müssen die Einrichtungen „die Ergebnisse der Scans in geplanten Zeitabständen aufzeichnen“.

VMware-Sicherheitshinweise und die Patch-Reihenfolge für vCenter und ESXi

Broadcom veröffentlicht Schwachstellen in VMware-Produkten als VMware Security Advisories (VMSA). Die Vulnerability Response Policy auf der Dokumentationsseite von Broadcom, ein VMware-Dokument vom August 2022, ordnet ihre Schweregrade CVSS-Bereichen zu: Critical umfasst 9,0 bis 10,0, Important 7,0 bis 8,9, Moderate 4,0 bis 6,9 und Low 0,1 bis 3,9. Die Richtlinie fügt hinzu, dass die Einstufungen „nicht nur von der CVSS-Bewertung abhängen“. Jeder Sicherheitshinweis führt die betroffenen unterstützten Produkte in einer Response Matrix auf, mit der korrigierten Version und einem etwaigen Workaround.

VMSA-2025-0004 vom 4. März 2025 zeigt, wie ein Sicherheitshinweis aufgebaut ist. Broadcom stufte ihn als Critical ein, mit einem CVSS-Wert von 9,3 für CVE-2025-22224, und erklärte, es lägen „Informationen vor, die darauf hindeuten, dass CVE-2025-22224 in freier Wildbahn ausgenutzt wurde“. Der korrigierte Build für ESXi 8.0 Update 3 war ESXi80U3d-24585383, und in der Spalte für Workarounds stand „None“. Laut der National Vulnerability Database des NIST nahm die CISA die CVE am 4. März 2025, dem Tag des Sicherheitshinweises, in ihren Katalog bekannter ausgenutzter Schwachstellen auf. Eine ausgenutzte Lücke ohne Workaround würde ein Unternehmen in der Regel als kritisch für seinen Betrieb einstufen, die nach Nummer 6.10.2 Buchstabe c „unverzüglich“ zu beheben ist.

Der Broadcom-Artikel KB 314601 nennt in seinen Beispielen die übliche Reihenfolge: „vCenter muss zuerst aktualisiert werden“ und „Danach folgt die ESXi-Version“. Derselbe KB-Artikel erlaubt, dass ESXi bei kleineren Update-Pfaden vorausgeht, „insbesondere wenn für ESXi ein Express-Patch ohne entsprechenden Pfad für vCenter veröffentlicht wurde“. VMSA-2025-0004 selbst betraf ESXi, Workstation und Fusion, nicht vCenter. KB 308161, die Update-Reihenfolge für vSphere 8.0, setzt vCenter Server auf Schritt 11, ESXi auf Schritt 12, VMware Tools auf Schritt 13 und die virtuelle Hardware auf Schritt 14. Keiner der beiden KB-Artikel zeigte am 10. Oktober 2026 ein Aktualisierungsdatum.

Der Zugang zu Patches hängt vom Supportvertrag ab, und KB 314603 macht Patches für kritische Sicherheitshinweise „mit einem CVSS-Wert (Common Vulnerability Scoring System) von 9,0 oder höher“ für Kunden mit vSphere-8.x-Dauerlizenz und abgelaufenem Supportvertrag verfügbar. Der KB-Artikel gilt nur für diese Art von Patches und nur für vSphere 8.x, daher gehört das Ende des allgemeinen Supports jedes Release in den Schwachstellenplan, wie unser Artikel zum Ende des allgemeinen Supports für vSphere 8 erklärt. Die Einstellungen, die die Exposition zwischen zwei Patches verringern, beschreibt unser Leitfaden zur Härtung von ESXi gegen Ransomware.

Wartungsfenster, Rollback und das Ausnahmeregister

Nummer 6.6.1 verlangt, dass Sicherheitspatches „getestet werden, bevor sie in Produktionssystemen angewendet werden“, und dass sie „aus vertrauenswürdigen Quellen stammen und auf ihre Integrität geprüft werden“. Nehmen Sie eine Umgebung mit 40 Hosts in vier Clustern zu je zehn. Testen bedeutet dort einen Test-Cluster oder zwei Pilot-Hosts, die den Patch zuerst erhalten und eine vereinbarte Zeit laufen, bevor der Rest folgt. Die Produktions-Cluster werden dann Host für Host im Wartungsmodus aktualisiert, nachdem die VMs per vMotion verschoben wurden, sodass jeder Cluster seine Last auf neun Hosts tragen muss. vCenter erhält vor seinem Patch ein Backup, und das Änderungsprotokoll nennt den vorherigen Build, zu dem zurückgekehrt wird.

Manche Patches lassen sich nicht rechtzeitig einspielen, etwa wenn der Hersteller einer Appliance den neuen ESXi-Build noch nicht freigegeben hat. Nach Nummer 6.6.2 darf eine Einrichtung auf einen Patch nur verzichten, „wenn die Nachteile der Anwendung der Sicherheitspatches die Vorteile für die Cybersicherheit überwiegen“, und muss die Gründe dokumentieren. Nummer 6.6.1 Buchstabe d verlangt dann zusätzliche Maßnahmen und akzeptierte Restrisiken. Nach Nummer 6.10.3 erhält eine Schwachstelle einen Plan zu ihrer Minderung, wenn ihre Auswirkungen das rechtfertigen. Andernfalls dokumentiert die Einrichtung, „warum die Schwachstelle keine Abhilfemaßnahmen erfordert“.

Ein Ausnahmeregister deckt alle drei Fälle ab. Jeder Eintrag nennt den Sicherheitshinweis oder die CVE, die betroffenen Systeme, den Grund, die Ausgleichsmaßnahme, den Risikoverantwortlichen, der das Restrisiko akzeptiert hat, und ein Datum für die Überprüfung. Die Tipps der ENISA zu Anforderung 2.1.4 besagen, dass Risiken aus Schwachstellen der höchsten Klasse, etwa „‚kritisch‘ im Common Vulnerability Scoring System (CVSS)“, „nach Möglichkeit nicht akzeptiert“ werden.

Unser Engineering-Partner Vixen.UNO aktualisiert vSphere-Umgebungen in vereinbarten Wartungsfenstern mit Rollback-Plan. Schicken Sie uns Ihre Builds von vCenter und ESXi über das Formular unten, zusammen mit den noch offenen Sicherheitshinweisen.

Sicherheitsprüfungen und NIS2-Penetrationstests nach Nummer 6.5

Nummer 6.5.1 verlangt „ein Konzept und Verfahren für Sicherheitsprüfungen“. Nach Nummer 6.5.2 legt die Einrichtung auf der Grundlage ihrer Risikobewertung „die Notwendigkeit, den Umfang, die Häufigkeit und die Art der Sicherheitsprüfungen“ fest und führt die Prüfungen „nach einer dokumentierten Prüfmethode“ durch. Sie dokumentiert „die Art, den Umfang, den Zeitraum und die Ergebnisse der Prüfungen“ und wendet „im Falle kritischer Feststellungen Risikominderungsmaßnahmen“ an. Nummer 6.5 nennt keine Prüfart, auch keine Penetrationstests.

Für ein Unternehmen mit 10 bis 60 Hosts kann der Prüfplan einen Penetrationstest der aus dem Internet erreichbaren Systeme und des Wegs von einem Benutzernetz in das Verwaltungsnetz enthalten. Befunde laufen in denselben Ticketablauf und dasselbe Ausnahmeregister wie die Ergebnisse der Scans. Die Leitlinie der ENISA sagt außerdem: „Beziehen Sie die Prüfung der Überwachungs- und Protokollierungsverfahren in die Sicherheitsprüfungen ein (Abschnitt 6.5).“ Ein Test zeigt daher auch, ob der Angriffsversuch in den Protokollen erschienen ist. Welche Ereignisse zu protokollieren sind, beschreibt unser Leitfaden zu den NIS2-Anforderungen an Protokollierung und Überwachung.

Ein monatlicher Zyklus für die Behandlung von Schwachstellen

1. Sammeln Sie die Sicherheitshinweise des Monats von Broadcom, den anderen Herstellern im Inventar und den CSIRT-Kanälen, die das Konzept nennt, und eröffnen Sie ein Ticket je relevantem Hinweis.
2. Gleichen Sie jedes Ticket mit dem Inventar und den Build-Nummern ab, und stufen Sie es nach dem Schweregrad des Herstellers, bekannter Ausnutzung und der Exposition der betroffenen Systeme ein.
3. Führen Sie die geplanten Scans durch, hängen Sie die datierten Berichte an die Aufzeichnung des Monats an und eröffnen Sie Tickets für neue Befunde.
4. Patchen Sie den Test-Cluster oder die Pilot-Hosts und die Test-VMs, und halten Sie das Ergebnis in der Änderung fest.
5. Patchen Sie die Produktion in vereinbarten Wartungsfenstern, vCenter vor den ESXi-Hosts, außer der Sicherheitshinweis behebt nur ESXi, mit dem Rollback-Plan im Änderungsprotokoll.
6. Scannen Sie erneut, um jede Korrektur zu bestätigen, und schließen Sie das Ticket mit diesem Nachweis.
7. Überprüfen Sie das Ausnahmeregister, und berichten Sie der Geschäftsleitung offene kritische Punkte und Behebungszeiten.

Eine kritische Schwachstelle, die zwischen zwei Zyklen ausgenutzt wird, läuft über eine Notfalländerung, statt auf das nächste Wartungsfenster zu warten. Für Nummer 7.2, nach der die Einrichtung bestimmt, was sie misst und wer die Ergebnisse bewertet, eignen sich zwei Kennzahlen: die Zeit vom Sicherheitshinweis bis zur Behebung je Einstufung und der Anteil der Systeme, die der letzte Scan erfasst hat.

Allgemeine Information zum EU-Recht mit Stand Oktober 2026, keine Rechtsberatung im Einzelfall.

Was wir tun

Im Rahmen unserer Leistung Cyber-Resilienz auditiert unser Engineering-Partner Vixen.UNO Infrastruktur, Zugriffe, Backups und die Einhaltung der NIS2-Anforderungen. Sie erhalten eine Risikokarte, einen priorisierten Maßnahmenplan und eine NIS2-Compliance-Karte mit Lücken und einem Plan, sie zu schließen. Die Compliance-Karte ist ein technisches Assessment: Die rechtliche Bewertung der Compliance erstellt Ihre Rechtsabteilung, und Compliance-Zertifikate stellen wir nicht aus. Unsere Leistung VMware-Optimierung modernisiert vSphere, vSAN und NSX in vereinbarten Wartungsfenstern, mit einem Rollback-Plan für jede Etappe. Der Support läuft unter einem vereinbarten SLA weiter, mit einem EU-Vertrag und einer Rechnung.

FAQ