Folgeartikel zu: Lücken offenhalten oder schließen: Schwachstellenmanagement und ein Zero-Day – Offene Fragen an John Doe

201715Z oct 26 · 51.7275 N, 11.5148 E

Folgeartikel zum Artikel Lücken offenhalten oder schließen: Schwachstellenmanagement und ein Zero-Day (BEO-2026-010) und seinem Nachtrag (BEO-2026-022).

Neue Rubrik: Offene Fragen – Experten schlagen vor. Hier lege ich die Fragen auf den Tisch, die in meinen Beiträgen offen geblieben sind, und frage hart nach. Die Fragen sind von mir. Antworten gibt John Doe, mein KI-Assistent, in der Rolle eines erfahrenen Praktikers für IT-Sicherheit und Schwachstellenmanagement. Diesmal geht es um den Artikel Lücken offenhalten oder schließen: Schwachstellenmanagement und ein Zero-Day (BEO-2026-010) und seinen Nachtrag (BEO-2026-022). Wichtig: John Doe ist kein Mensch und kein echter Experte. Er hält sich an die belegten Fakten aus dem Nachtrag und kennzeichnet alles andere als Einschätzung.

Ich: Der Staat sagt, er braucht offene Lücken, um Terroristen zu fangen. Ist das nicht einfach die Wahrheit, und alles andere ist naiv?

John Doe: Dass es Ermittlungsfälle gibt, in denen ein Zugriff über eine Schwachstelle hilft, halte ich für plausibel, aber das ist meine Einschätzung und keine belegte Tatsache. Naiv ist nach meiner Einschätzung eher die Annahme, eine offen gehaltene Lücke ließe sich nur von den „Guten“ nutzen. Wer offenhält, lässt alle anderen Nutzer derselben Software ungeschützt. Deshalb halte ich die Frage „Wahrheit oder naiv“ für falsch gestellt: Es geht um eine Abwägung, und die braucht Regeln.

Ich: GFF und Bitkom wollen, dass Lücken grundsätzlich geschlossen werden. Sind das nicht Lobbyisten, die vor allem ihre Kunden schützen wollen?

John Doe: Wer welche Interessen hat, kann ich aus den Quellen nicht belegen. Meine Einschätzung ist: Selbst wenn ein Verband die eigenen Mitglieder im Blick hätte, wäre die Forderung deshalb nicht falsch. Laut Whitepaper vom 14.10.2026 sollen Lücken grundsätzlich geschlossen werden, Offenhalten soll aber nach einem verpflichtenden, strukturierten Abwägungsprozess mit Kontrolle möglich bleiben. Ein striktes Verbot ist das also nicht. Ich würde die Argumente prüfen und nicht nur fragen, wer sie vorbringt.

Ich: Eine Lücke, die der BND kennt, kennt irgendwann auch ein anderer. Wer haftet, wenn genau diese Lücke dann gegen ein Krankenhaus eingesetzt wird?

John Doe: Wer in so einem Fall haftet, kann ich nicht sicher beantworten, und ich will hier keine Rechtslage erfinden. Meine Einschätzung ist, dass genau diese Haftungs- und Verantwortungsfrage heute kaum greifbar ist. Wenn nicht einmal öffentlich bekannt wird, dass eine Behörde die Lücke kannte, lässt sich auch niemand dafür verantwortlich machen. Das wäre aus meiner Sicht ein Punkt, den die laufende Reform ausdrücklich klären sollte.

Ich: Das Papier verlangt einen „verpflichtenden, strukturierten Abwägungsprozess“. Klingt nach Formular. Wer soll da ernsthaft Nein sagen, wenn ein Dienst Ja will?

John Doe: Die Sorge ist berechtigt: Ein Prozess, in dem am Ende nur die Stelle entscheidet, die die Lücke nutzen will, wäre tatsächlich nur ein Formular. Meine Einschätzung ist, dass es auf die Ausgestaltung ankommt: Wer sitzt mit am Tisch, wer kann ein Veto einlegen, gibt es Fristen für eine erneute Prüfung, und wer kontrolliert das Ganze von außen. Das Whitepaper fordert ausdrücklich eine Kontrolle, aber wie wirksam sie wäre, hängt von Details ab, die man erst noch festlegen muss.

Ich: Was das BSI gemeldet bekommt, soll „unter keinen Umständen“ an die Dienste gehen. Glauben Sie im Ernst, dass das in der Praxis hält?

John Doe: Ob das in der Praxis hält, kann niemand garantieren, und ich werde es auch nicht tun. Meine Einschätzung ist, dass eine so klare Formulierung wie „unter keinen Umständen“ immerhin ein überprüfbarer Maßstab ist, an dem man Verstöße messen kann. Halten wird so eine Regel nach meiner Einschätzung nur, wenn sie gesetzlich verankert ist, unabhängig kontrolliert wird und Verstöße Folgen haben. Ohne das bleibt es ein Versprechen. Das ist umso wichtiger, weil Forscher und Unternehmen dem BSI nur dann weiter melden werden, wenn sie dieser Zusage vertrauen.

Ich: Bei BeyondTrust wurde die Lücke am 29. August ausgenutzt, gepatcht wurde für SaaS-Kunden ab dem 9. Oktober. Sind sechs Wochen nicht eine Ewigkeit?

John Doe: Zwischen dem 29. August und dem 9. Oktober liegen tatsächlich rund sechs Wochen, und für die Betroffenen ist das lang. Man muss aber unterscheiden: Der 29. August ist laut BeyondTrust der Beginn der Ausnutzung, nicht zwingend der Tag, an dem der Hersteller davon erfahren hat. Dazu habe ich keine gesicherte Angabe. Meine Einschätzung ist, dass man den Zeitraum erst fair beurteilen kann, wenn klar ist, ab wann der Hersteller Bescheid wusste.

Ich: BeyondTrust sagt, es kennt nur zwei betroffene Kunden. Muss man einem Hersteller so eine Zahl überhaupt glauben?

John Doe: Glauben muss man das nicht blind, man sollte die Zahl aber genau lesen. „Zwei betroffene Kunden, die BeyondTrust kennt“ heißt nicht, dass es nur zwei Betroffene gibt. Meine Einschätzung ist, dass bei einer Fernwartungssoftware unentdeckte Fälle realistisch sind. Dass CISA die Lücke am 16.10. in den KEV-Katalog aufgenommen hat, zeigt jedenfalls, dass die Ausnutzung als real eingestuft wird.

Ich: Die Zuordnung zu ARMORY CASTLE ist eine Einschätzung mit „mittlerer bis hoher Sicherheit“. Ist Attribution nicht am Ende nur Bauchgefühl mit Logo?

John Doe: Nein, so pauschal stimmt das nicht. Attribution beruht auf technischen Spuren, Infrastruktur und Vorgehensmustern, aber sie bleibt eine Wahrscheinlichkeitsaussage. Genau das bringt die Formulierung „mittlere bis hohe Sicherheit“ ehrlich zum Ausdruck. Problematisch wird es nach meiner Einschätzung erst, wenn andere aus so einer Einschätzung eine Gewissheit machen.

Ich: Ob eine Behörde diese Lücke vorher kannte, steht in keiner Quelle. Würden wir es überhaupt je erfahren?

John Doe: Ehrlich gesagt: Es gibt keine Garantie, dass wir es erfahren. Meine Einschätzung ist, dass solches Wissen ohne Berichtspflichten und unabhängige Kontrolle typischerweise im Verborgenen bleibt. Im Fall von CVE-2026-102764 steht dazu in keiner Quelle etwas, und ich werde nicht darüber spekulieren, ob eine Behörde die Lücke kannte. Gerade deshalb halte ich nachvollziehbare Verfahren und eine Aufsicht für zentral.

Ich: Letzte Frage, ohne Ausweichen: Offenhalten oder schließen?

John Doe: Meine Einschätzung: schließen, als klarer Grundsatz. Offenhalten halte ich nur als eng begrenzte, befristete und kontrollierte Ausnahme für vertretbar, wenn überhaupt. Und Lücken, die dem BSI gemeldet werden, sollten nicht an die Dienste gehen. Das liegt nah an dem, was GFF und Bitkom vorschlagen, und ich halte es für die verantwortbarere Linie.

Quellen

• Both Eyes Open, BEO-2026-010: Lücken offenhalten oder schließen: Schwachstellenmanagement und ein Zero-Day
• Both Eyes Open, BEO-2026-022: Nachtrag: Lücken offenhalten oder schließen: Schwachstellenmanagement und ein Zero-Day
• GFF und Bitkom, 14.10.2026: Whitepaper zur Nachrichtendienstrechtsreform: Staatliches Schwachstellenmanagement klar regeln (PDF)
• BeyondTrust, 15.10.2026: BT26-05
• BeyondTrust, 15.10.2026, zuletzt geändert 16.10.2026: ARMORY CASTLE and BT26-05: What Security Teams Need to Know
• CISA, 16.10.2026: CISA Urges Patching Critical Vulnerability in BeyondTrust Remote Support