Das Drei-Tage-Fenster bricht Ihren Änderungsprozess

Die CISA gibt Bundesbehörden jetzt drei Kalendertage, um die riskantesten Schwachstellen zu schließen. Nicht vierzehn. Drei. Die Direktive, die diese Uhr stellt, Binding Operational Directive 26-04, nennt ihren eigenen Grund: KI-gestützte Schwachstellensuche hat den Abstand zwischen Veröffentlichung und funktionierendem Exploit zusammengeschoben. Wenn Ihr Change Advisory Board wöchentlich tagt, liegt es damit außerhalb des Fensters, das eine Behörde öffentlich für angemessen erklärt hat.

Das ist kein US-Bundesproblem, das man ablegen kann. Niemand wird einen deutschen Mittelständler für eine verpasste amerikanische Frist belangen. Was stattdessen passiert, ist leiser und teurer: Wenn ein Prüfer, ein Versicherer oder ein NIS2-Assessor eine Zahl hinter der Formel „unverzüglich“ braucht, greift er zur konkretesten veröffentlichten Angabe. Seit Juni 2026 sind das drei Tage.

Was BOD 26-04 tatsächlich ändert

Die Direktive erschien am 10. Juni 2026 und bindet die zivilen US-Bundesbehörden. Sie ersetzt die pauschale Frist, die der KEV-Katalog bekannter ausgenutzter Schwachstellen bisher implizierte, in dem allein die Aufnahme in den Katalog über die Dringlichkeit entschied und jede gelistete CVE gleich behandelt wurde. Dringlichkeit ist jetzt eine Funktion von vier Variablen:

• Öffentlich exponiert. Ist das System von außen über eine routbare Adresse erreichbar?
• Im KEV-Katalog. Ist die Ausnutzung in freier Wildbahn bereits bestätigt?
• Automatisierbar. Kann ein Angreifer jeden Schritt automatisieren, von der Zielsuche bis zum Payload?
• Technische Auswirkung. Führt die Ausnutzung zur vollständigen Kontrolle über das System oder nur zu teilweiser?

Daraus entsteht eine gestaffelte Frist. Eine KEV-Schwachstelle mit vollständiger Kontrolle bekommt drei Tage mit forensischer Vorprüfung. Eine Schwachstelle, die öffentlich exponiert, automatisierbar und vollständig kontrollierend ist, bekommt drei Tage auch dann, wenn sie noch gar nicht im KEV-Katalog steht, und das ist der wirklich neue Gedanke des Dokuments. Die meisten anderen KEV-Einträge bekommen vierzehn Tage, risikoärmere Kombinationen sechzig, und alles, was keines der Kriterien erfüllt, wird beim nächsten System-Upgrade behoben.

Die Begründung der CISA lohnt sich im Klartext. Die Wirksamkeit der Behebung sinkt: 2025 wurden nur 26 Prozent der KEV-Schwachstellen tatsächlich geschlossen, nach 38 Prozent im Jahr davor. Gleichzeitig verkürzt KI-gestützte Schwachstellensuche den Abstand zwischen Advisory und lauffähigem Exploit weiter. Die Direktive verlangt nicht, härter zu arbeiten. Sie räumt ein, dass der alte Abstand nicht mehr existiert.

Die alte Uhr und die neue Uhr

Die letzte Zeile ist die, die Geld kostet. Alles darüber ist eine Änderung an einem Richtliniendokument. Diese Zeile ist eine Änderung am Betriebsmodell.

Drei Tage sind kürzer als die meisten Genehmigungswege

Rechnen Sie das an einer echten Organisation durch. Ein Hersteller veröffentlicht ein Advisory an einem Freitagnachmittag, denn dann veröffentlichen Hersteller. Ihr Change Advisory Board tagt am Dienstag. Sie sind bei Tag vier, bevor überhaupt jemand etwas genehmigt hat, und das unter der Annahme, dass das Ticket noch am selben Nachmittag aufgemacht wurde und der zuständige Ingenieur nicht im Urlaub ist.

Den Notfallweg gibt es natürlich. Die meisten Unternehmen haben einen. In der Praxis braucht er einen namentlich benannten Genehmiger, der erreichbar ist, ein abgestimmtes Wartungsfenster, einen Rollback-Plan und jemanden, der bereit ist, an einem Samstag einen ungeplanten Ausfall zu verantworten. Das ist ein Prozess für zwei oder drei Anwendungen im Jahr. BOD 26-04 beschreibt Bedingungen, die deutlich häufiger eintreten werden.

Die Direktive sagt also gar nicht „patcht schneller“. Sie sagt, die Entscheidung muss vorher gefallen sein. Wenn die vier Variablen erfüllt sind, ist die Änderung bereits genehmigt, und der Nachweis entsteht um sie herum statt vor ihr. Das ist eine andere Governance-Form als die, die die meisten Häuser fahren, und dieselbe, für die wir beim Notfall-Änderungsmanagement für Firewalls argumentiert haben: Der Notfallweg ist nur glaubwürdig, wenn er Monate vorher in Ruhe entworfen wurde, von Leuten ohne Zeitdruck.

Die vCenter-Kampagne hat die Uhr bewiesen

Falls die Drei-Tage-Zahl theoretisch klingt, haben Juli und August das Gegenbeispiel geliefert. Broadcom veröffentlichte CVE-2026-59310 am 29. Juli, eine Directory-Traversal-Lücke im Syslog-Server von VMware vCenter, die zu Remote Code Execution führt, mit CVSS 9.8 bewertet und zusammen mit vier weiteren Fehlern in derselben Advisory-Runde gepatcht.

Die Ausnutzung begann rund fünf Tage nach der Veröffentlichung. Das deutsche Incident-Response-Haus Quirso fand die Kampagne in einem Mandat und veröffentlichte am 10. August: 361 betroffene IP-Adressen in 47 Ländern, mehr als die Hälfte davon konzentriert auf Deutschland, die USA, die Türkei, den Iran und Frankreich. Die Angreifer verankerten sich über einen Cronjob mit einem quelloffenen Reverse-SSH-Werkzeug, in mindestens einem beobachteten Fall gefolgt von Ransomware. Die CISA nahm die CVE am 18. August in den KEV-Katalog auf; unter BOD 26-04 hatten die Bundesbehörden damit bis zum 21. August Zeit.

Die Zahl, auf die es in diesem Absatz ankommt, ist nicht 9,8 und nicht 361. Es ist die Fünf. Fünf Tage zwischen einem öffentlichen Advisory und den ersten Einbrüchen sind kürzer als die Zeit, die die meisten Organisationen allein zur Terminierung der Arbeit brauchen. Viele der Opfer waren nicht nachlässig. Sie standen noch in der Warteschlange.

Deutschland trug den größten Anteil dieser Kampagne, was daraus eine inländische Governance-Frage macht und keinen amerikanischen Import.

Was das speziell mit Firewall-Änderungen macht

Schauen Sie sich an, welche Systeme die Drei-Tage-Kriterien tatsächlich erfüllen, und das Bild verengt sich schnell. Öffentlich exponiert, automatisierbar, vollständige technische Kontrolle: Das ist der Perimeter. Firewalls, VPN-Konzentratoren, Load Balancer, Reverse Proxies, Management-Ebenen von Hypervisoren. Die Geräte in der Drei-Tage-Stufe sind überproportional genau die Geräte, die Ihr Firewall-Team betreut.

Daraus folgt ein zweites Problem, das die Direktive nicht behandelt, weil es nicht ihr Problem ist. Das Patchen einer Perimeter-Appliance ist selten ein in sich abgeschlossener Vorgang. Es bedeutet ein Verfügbarkeitsereignis, meist ein Failover, manchmal eine vorübergehende Regeländerung, damit der Verkehr weiterläuft, während ein Knoten fehlt. Eine Drei-Tage-Frist auf den Patch ist auch eine Drei-Tage-Frist auf all das, weshalb ein tatsächlich geprobter Failover-Test aufhört, eine Reifegrad-Nettigkeit zu sein, und zu dem Faktor wird, der über die Einhaltung der Frist entscheidet.

Es setzt außerdem voraus, dass Sie zu jeder Tageszeit eine Frage beantworten können: Welche Regeln, Objekte und Abhängigkeiten verweisen auf das betroffene Gerät? Eine Organisation, die ihr Regelwerk in einer Tabellenkalkulation führt, kann das nicht binnen drei Tagen beantworten, und die Tabelle fällt beim Audit durch, aus genau dem Grund, aus dem sie auch die Frist reißt. Sie ist ein Protokoll der Absicht, kein abfragbares Modell des Zustands. Die Vorarbeit ist gewöhnlich und unspektakulär: ein aktuelles, geprüftes Regelwerk gemäß einer echten Regel-Audit-Disziplin, und Drift-Erkennung, damit das Vermutete mit dem Ausgerollten übereinstimmt, gemäß Policy-Drift-Erkennung. Nichts davon ist ein neuer Ratschlag. Neu ist, dass die Frist sein Fehlen jetzt unmittelbar bestraft.

Europa erbt die Zahl, ohne die Direktive zu übernehmen

NIS2 Artikel 21 und DORA verlangen beide einen zeitnahen Umgang mit Schwachstellen, und keines von beiden nennt eine Zahl. Diese Unschärfe war bequem, solange niemand eine konkrete veröffentlicht hatte. Sie ist es jetzt weniger.

Der Mechanismus ist nicht juristisch, sondern beweisrechtlich. Ein Prüfer, der einen KRITIS-Betreiber auffordert nachzuweisen, dass seine Behebungsfristen angemessen sind, musste bislang aushandeln, was angemessen bedeutet. Seit Juni 2026 liegt ein veröffentlichtes, begründetes Vier-Variablen-Modell einer nationalen Cyberabwehrbehörde öffentlich vor. Es wird zitiert werden, in Versicherungsfragebögen früher als in Verordnungen. Wer bereits an NIS2-Firewall-Nachweisen arbeitet oder KRITIS-Pflichten abarbeitet, sollte davon ausgehen, dass sich die Frage verschiebt: weg von „patchen Sie zeitnah“ hin zu „wie lautet Ihre definierte Frist, und wo ist der Nachweis, dass Sie sie eingehalten haben“.

Vier Dinge für dieses Quartal

• Schreiben Sie die stehende Ausnahme, bevor Sie sie brauchen. Verankern Sie den Vier-Variablen-Auslöser in der Change-Richtlinie selbst, benennen Sie die Person, die um zwei Uhr nachts entscheidet, und legen Sie fest, welche Nachweise im Nachgang entstehen. Eine Vorabgenehmigung, die niemand aufgeschrieben hat, ist keine Kontrolle.
• Bauen Sie die Expositionskarte vorher. Sie müssen von „Hersteller X hat ein Advisory veröffentlicht“ binnen Stunden auf „diese sieben Geräte, diese Regeln, dieser Wirkungsbereich“ kommen. Diese Zuordnung ist ein Datenproblem, das man an einem ruhigen Dienstag löst, nicht während eines Vorfalls.
• Proben Sie den Failover, nicht nur den Patch. Steht die Appliance in einem Hochverfügbarkeitspaar, entscheidet nicht die Verfügbarkeit des Binaries über die Frist, sondern ob die Umschaltung funktioniert. Testen Sie das nach Ihrem Kalender, sonst erfahren Sie es nach dem eines anderen.
• Erfassen Sie den Nachweis im selben Tempo. Die Audit-Antwort lautet nie „wir haben gepatcht“. Sie lautet „wir haben an Tag zwei gepatcht, hier ist der Auslöser, die geerbte Genehmigung, das Konfigurations-Diff und die Verifikation“. Wochen später erzeugte Nachweise sind Rekonstruktionen, und Prüfer merken das. Automatisierte Prüfungen direkt gegen das Gerät machen aus einer Behauptung einen Beleg.

Warum das zählt

Das Drei-Tage-Fenster ist keine Zielvorgabe, in die sich ein Gremium hineingeredet hat. Es ist eine Vermessung des Angreifers, veröffentlicht von einer Behörde, die zusehen musste, wie ihre eigene Behebungsquote sank, während die Ausnutzung schneller wurde. Die Organisationen, die damit Schwierigkeiten bekommen, sind nicht die mit langsamen Ingenieuren. Es sind die, deren Genehmigungsprozess für einen menschlichen Angreifer entworfen wurde, der eine Woche brauchte, um einen Exploit zu schreiben, und den es in dieser Form nicht mehr gibt.

Die Lösung ist nicht Dringlichkeit. Dringlichkeit ist das, was Sie ausgeben, wenn der Prozess versagt hat. Die Lösung besteht darin, vorher und schriftlich festzulegen, welche Änderungen bereits genehmigt sind, wer sie verantwortet und welcher Nachweis während der Arbeit entsteht. Das ist Änderungsmanagement, das die Aufgabe erfüllt, für die es immer gedacht war, im Tempo, das die Frist jetzt verlangt.

Wollen Sie wissen, ob Ihr Änderungsprozess eine Drei-Tage-Frist übersteht? Machen Sie den kostenlosen NIS2-Check und erhalten Sie eine schriftliche Einschätzung, wo Ihre Firewall-Nachweise heute stehen.