Kritische Lücken im Wochentakt und was NIS-2 und KRITIS von Ihrer IT verlangen

Was das Gesetz zu Patches sagt

Entfernen wir uns an dieser Stelle mal von der Technik und schauen auf die gesetzlichen Grundlagen. Seit Dezember 2025 gilt das NIS-2-Umsetzungsgesetz in Deutschland. Ob Ihr Unternehmen darunter fällt, lässt sich mit der Betroffenheitsprüfung des BSI einschätzen. Das Ergebnis ist rechtlich nicht bindend, und die Einstufung gilt für jede Einrichtung einzeln, nicht automatisch für den ganzen Konzern. Es gibt aber einen guten ersten Einblick, wie Ihr Unternehmen einzuordnen ist.

Der Paragraph 30 des BSI-Gesetzes (BSIG) verlangt von Ihnen geeignete, verhältnismäßige und wirksame Maßnahmen nach dem Stand der Technik, und dass Sie deren Umsetzung dokumentieren. Für den Umgang mit Sicherheitslücken zählen in diesem Paragraphen vier der zehn Mindestinhalte:

• die Sicherheit der Lieferkette (Nr. 4),
• das Management von Schwachstellen bei Erwerb, Entwicklung und Wartung (Nr. 5),
• die Bewertung der Wirksamkeit der Maßnahmen (Nr. 6)
• und die Kryptografie (Nr. 8).

Genaue Fristen, wann z. B. verwundbare Systeme zu patchen sind, stehen dort allerdings nicht. Was angemessen ist, hängt vom wirklichen Risiko ab. Eine Lücke, die ohne Anmeldung Codeausführung erlaubt und aktiv angegriffen wird, verlangt sicher mehr Aufmerksamkeit als eine ohne bereits bekannte Ausnutzung. Bei Brotli (CVE-2026-111497) zum Beispiel stufte Ubuntu die Lücke nur als mittel ein, die CISA sah am 23. Oktober noch keine Ausnutzung, aber die CVSS-Bewertung liegt bei 9,2. Seit dem 27. Oktober steht die Lücke nun doch im CISA-Katalog ausgenutzter Schwachstellen. Bei manchen Systemen reichte ein Update. 

Wo der Hersteller noch kein korrigiertes Image geliefert hatte, half übergangsweise eine Regel am Reverse Proxy, die Anfragen mit gesetztem Header Content-Encoding abweist. Normale Browser senden solche komprimierten Anfragen nicht, über sie ließe sich aber ein präparierter Brotli-Datenstrom an eine Anwendung schicken, deshalb halte ich das für den wahrscheinlichsten Angriffsweg.

Solche Widersprüche in der Bewertung von Lücken sind allerdings normal. Entscheidend ist, dass Sie selbst die Bewertung getroffen und festgehalten haben, auch wenn das Ergebnis „nicht betroffen“ lautet. Das gehört zum Risikomanagement, für das Sie als Geschäftsleitung verantwortlich sind.

Meldepflicht gilt für Vorfälle, nicht für Lücken

Eine ungepatchte Lücke ist dabei noch lange kein meldepflichtiger Vorfall. Wird daraus allerdings ein „erheblicher Sicherheitsvorfall“, verlangt § 32 BSIG eine Erstmeldung an das BSI spätestens nach 24 Stunden, eine Meldung mit erster Bewertung nach 72 Stunden und einen Abschlussbericht spätestens einen Monat danach. Sind personenbezogene Daten betroffen, kommen auch noch die Artikel 32 und 33 der DSGVO hinzu. Wer nachts um drei erst noch den Meldeweg suchen muss, hat die erste Frist schon halb verbraucht.

Geschäftsleitung und Bußgelder

Kommen wir jetzt mal zu den Verantwortlichkeiten, und ich weiß, das möchte niemand gern hören. Der § 38 BSIG verpflichtet die Geschäftsleitung, die entsprechenden Maßnahmen umzusetzen und zu überwachen, nicht die IT-Abteilung. Die Geschäftsleitung muss darüber hinaus auch regelmäßig an Schulungen teilnehmen. Bei schuldhafter Pflichtverletzung haftet sie nach dem Gesellschaftsrecht der jeweiligen Rechtsform. Paragraph 65 sieht für Verstöße gegen die Risikomanagement- und Meldepflichten Bußgelder bis 10 Millionen Euro bei besonders wichtigen und bis 7 Millionen Euro bei wichtigen Einrichtungen vor. Bei einem Gesamtumsatz über 500 Millionen Euro gelten stattdessen Obergrenzen von 2 beziehungsweise 1,4 Prozent des Umsatzes. Das heißt nicht, dass diese extremen Summen auch tatsächlich als Bußgeld verhängt werden, aber gerade für kleinere Unternehmen kann ein hoher fünfstelliger Betrag durchaus fällig werden.

Was zusätzlich für KRITIS gilt

Betreiber kritischer Anlagen müssen nach § 31 BSIG für die maßgeblichen Systeme Angriffserkennung einsetzen, die Parameter aus dem laufenden Betrieb kontinuierlich und automatisch erfasst und auswertet. NIS-2 unterscheidet dabei zwischen „besonders wichtigen Einrichtungen“ und „wichtigen Einrichtungen“, während „KRITIS“ im engeren Sinne die betroffenen physischen, kritischen Infrastrukturen beschreibt.

Die Umsetzung müssen sie dem BSI nach § 39 BSIG alle drei Jahre nachweisen. Das BSI hat ein direktes Einforderungsrecht für Nachweise über die Mängelbehebung, wenn Audits Schwachstellen oder Mängel ergeben. Hier reicht ein einfaches Patchen allein nicht aus, es muss auch überprüft werden, ob vor dem Patch bereits ein Angriff stattgefunden hat und das System kompromittiert wurde (IoC, Indicators of Compromise). Auch das gehört zur Mängelbeseitigung.

Die Lieferkette gehört dazu

Paragraph 30 Absatz 2 Nummer 4 BSIG verlangt Maßnahmen zur Sicherheit der Lieferkette, einschließlich der sicherheitsbezogenen Aspekte der Beziehungen zu unmittelbaren Anbietern und Dienstleistern. Konkreter wird die EU-Richtlinie dahinter (Artikel 21 Absatz 3 der NIS-2-Richtlinie). Sie verlangt, dass Sie jeden Lieferanten und Dienstleister einzeln bewerten. Dabei zählt, wie anfällig er für Angriffe ist, wie gut seine Produkte sind und wie sicher er entwickelt und arbeitet. Im Gesetzestext steht das so allerdings nicht, ich gehe aber davon aus, dass sich die Aufsicht daran orientiert.

Die Lieferkette hat dabei zwei Ebenen. Die eine sind Dienstleister wie Hoster, Agenturen und der IT-Betrieb. Eine ungepatchte Webseite bei einem Dienstleister ist ein Einfallstor in Ihr eigenes Netz, auch wenn Sie selbst alles richtig gemacht haben. Die andere Ebene ist die Software. Brotli zeigt das gut. Sie können die Bibliothek nicht selbst patchen, weil sie in Node.js und in Container-Images von Herstellern steckt. Sie können aber wissen, wo sie steckt und wann der Hersteller liefert.

Beides gilt auch in die andere Richtung. Wer selbst Hoster, Agentur oder IT-Betrieb ist, muss damit rechnen, dass Kunden diese Anforderungen vertraglich weitergeben und Patchstand und Reaktionszeiten schriftlich sehen wollen. Wer den Betrieb auslagert, gibt die Aufgabe ab, die Verantwortung bleibt im Haus, denn die Geschäftsleitung muss die Umsetzung nach § 38 BSIG überwachen. Deshalb gehören konkrete Punkte in den Vertrag:

• Patchfristen nach Schweregrad
• Meldepflicht des Dienstleisters innerhalb weniger Stunden (zur Einhaltung der eigenen 24-Stunden-Frist)
• Schriftliches Auskunftsrecht zum Patchstand
• Verbindlicher Umgang mit Unterdienstleistern
• Sonderkündigungsrecht bei wiederholten Verstößen

Was ich empfehle

Die ganzen Sicherheitslücken waren sicher unschön und zogen jede Menge Arbeit nach sich. Allerdings müssen wir uns in Zeiten von KI daran gewöhnen, dass solche Lücken deutlich schneller gefunden werden als noch vor ein paar Jahren. Die PHP-Lücke war zum Beispiel nicht neu, sondern wurde jetzt erst gefunden. Dieser Beitrag ist natürlich keine Rechtsberatung, aber die nachfolgenden Hinweise sind sicher ein guter erster Schritt.

• Führen Sie eine Inventarisierung durch, die auch Container und eingebundene Bibliotheken sowie Zertifikate einschließt, nicht nur Server.
• Legen Sie interne Fristen je nach Schweregrad und Ausnutzungsstand fest und begründen Sie Abweichungen schriftlich.
• Bewerten Sie jede kritische Meldung innerhalb eines Tages und halten Sie das Ergebnis fest.
• Haben Sie kein eigenes SOC (Security Operations Center), investieren Sie in ein SOC-as-a-Service. Das ist deutlich billiger als das Bußgeld.
• Fragen Sie Ihre Dienstleister nach Patchstand und Meldeweg, halten Sie die Antwort schriftlich fest und überprüfen Sie das auch regelmäßig.
• Klären Sie vorab, wer die 24-Stunden-Meldung in Richtung BSI auslöst und über welchen Weg.
• Prüfen Sie nach dem Patch, ob vorher jemand das System kompromittiert hat. Sind Sie sich nicht sicher oder existieren noch keine IoCs, nehmen Sie die Systeme vom Netz und tauschen sicherheitskritische Informationen (Passwörter, Zertifikate, Schlüssel etc.). Seien Sie besonders aufmerksam bei Systemen mit personenbezogenen Daten.
• Stellen Sie sicher, dass Backups gegebenenfalls wiederhergestellt werden können.
  Informieren Sie die Geschäftsleitung regelmäßig, nicht erst bei einem Vorfall.

Vergessen Sie dabei die Cloud nicht. Microsoft 365 ist für die meisten Unternehmen der wichtigste Dienstleister in der Lieferkette, und eine falsch konfigurierte Umgebung ist eine Schwachstelle, für die es keinen Patch gibt.

Wenn Sie wissen möchten, wo Ihre Microsoft-365-Umgebung heute steht, prüft unser Microsoft 365 Tenant Check sie in über 500 Tests. Über die Seite erreichen Sie uns direkt, oder Sie schreiben mir über LinkedIn.