Da mir einige Details zum Ablauf und zu den Inhalten der Offenlegung der Webex-Schwachstellen der letzten Wochen fehlen, ist unklar, was genau nicht gut gelaufen ist. Dass es nicht gut gelaufen ist, sieht man jedoch unter anderem daran, dass die Vermittlerin selbst anzweifelt, wie koordiniert der von ihr initiierte “Prozess” war, dass das Bundesamt für Sicherheit in der Informationstechnik erst weit nach der öffentlichen Berichterstattung eine Warnung herausgeben konnte und dass es keinen entsprechenden Eintrag der Schwachstelle in einer Common Vulnerabilities and Exposures (CVE) Datenbank gibt. Zwar ist ein solcher Eintrag, gerade bei Schwachstellen in Cloud-Produkten, nicht verpflichtend. Trotzdem hilft er oft bei einer besseren Risikobewertung. Wie aber hätte die Offenlegung optimalerweise ablaufen sollen?
Die Debatte darüber, wie mit einer Schwachstelle verantwortungsbewusst umgegangen werden sollte, nachdem sie gefunden worden ist, hat vor mehr als zwei Jahrzehnten angefangen. Mittlerweile wird statt von verantwortungsvoller Schwachstellen-Offenlegung („Responsible Disclosure”) immer häufiger von koordinierter Schwachstellen-Offenlegung („Coordinated Vulnerability Disclosure”) gesprochen. Im Kern geht es darum, wie man gefundene Schwachstellen so offenlegt, dass ein möglichst hohes Maß an IT-Sicherheit für alle Betroffenen gewährleistet wird. Da es sich hierbei um einen Vorgang handelt, bei dem meist verschiedene Akteure mit unterschiedlichen Interessen involviert sind, besteht der ideale Weg darin, gemeinsam und koordiniert vorzugehen.
Das andere elementare Merkmal von Schwachstellen-Offenlegung ist das Anreizsystem. Menschen, die Schwachstellen finden, müssen a) dazu motiviert werden, mit Herstellern, Projektbetreuern und Betreibern [im Weiteren als „Verantwortliche“ zusammengefasst] in einen koordinierten Prozess einzutreten und b) nicht entmutigt werden, dies zu tun. Ersteres geschieht unter anderem durch Anerkennung in Communities und Danksagungen (Bundeswehr „Hall of Fame”), nicht käuflich erwerbbare Produkte („I hacked the Dutch government …”-T-Shirt) oder (monetäre) Entlohnung („Vulnerability Rewards Programme” in Singapur). Letzteres geschieht unter anderem durch einen klaren rechtlichen Rahmen, der Sicherheitsforschenden, die in guter Absicht Schwachstellen finden, Rechtssicherheit und Schutz vor gegenstandslosen Anzeigen bietet.
Wenn das Anreizsystem und die Würdigung nicht funktionieren, behalten diese Menschen das Wissen um die Schwachstellen für sich, legen sie unkoordiniert offen („Full Disclosure” oder „Limited Disclosure”) oder verkaufen entsprechende Informationen auf dem Schwachstellenmarkt, wo sie dann ihren Weg in Überwachungs- und Schadsoftware finden. All das schwächt die IT-Sicherheit, statt sie zu stärken. Wobei die unkoordinierte Offenlegung in Ausnahmefällen noch der beste Weg sein kann – vor allem dann, wenn die Koordinierung an den Verantwortlichen scheitert. Denn dadurch wird Druck auf die Verantwortlichen ausgeübt, die Schwachstelle zu schließen. Leider kann die Schwachstelle dann bereits von Kriminellen und Nachrichtendiensten analysiert und zum Schaden verwundbarer IT-Infrastrukturen und der dadurch betroffenen Menschen ausgenutzt werden.
Von „Information Anarchy” zu „Coordinated Vulnerability Disclosure”
Im Gegensatz zu anderen Baustellen der IT-Sicherheit und Cybersicherheitspolitik konnten Regierungen, Sicherheitsforschende und Industrie hier einige Fortschritte erzielen. Diese Entwicklung spiegelt sich in konkreten Konzepten wider, deren Umsetzung der von Scott Culp (damals Microsoft) als „Information Anarchy” bezeichneten, unkoordinierten Offenlegung von Schwachstellen entgegenwirken soll. Das fängt an bei den „Normen für ein verantwortungsvolles Verhalten der Staaten im Cyberraum” der Vereinten Nationen und Standardisierungsveröffentlichungen wie „ISO/IEC TR 5895 – Cybersecurity — Multi-party coordinated vulnerability disclosure and handling” oder „ISO/IEC 30111 – Information technology — Security techniques — Vulnerability handling processes” und wird konkreter mit Handreichungen von Carnegie Mellon University’s „CERT® Guide to Coordinated Vulnerability Disclosure” und FIRST’s „Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure”.
Hinzu kommen ganz konkrete Schwachstellen-Policies von Unternehmen wie Google’s Project Zero, sowie technische Handreichungen, wie dem „RFC 9116 – A File Format to Aid in Security Vulnerability Disclosure”. Letztere besagt, dass Verantwortliche für Hardware und Software eine einfach zugängliche security.txt-Datei auf ihrem Webserver ablegen sollen. In dieser wird beschrieben, an wen und wie man eine gefundene Schwachstelle meldet und wie man diese verantwortungsvoll und koordiniert offenlegt. Ein Beispiel dafür ist aus gegebenem Anlass der Schwachstellen in Webex-Software Cisco selbst: https://www.cisco.com/.well-known/security.txt.
Quelle: https://www.cisco.com/.well-known/security.txt.
Wie sollte koordinierte Schwachstellen-Offenlegung ablaufen?
Eine oft genutzte Definition von koordinierter Schwachstellen-Offenlegung steht im internationalen Standard ISO/IEC 29147. Darin heißt es: „Vulnerability disclosure is a process through which vendors and vulnerability finders may work cooperatively in finding solutions that reduce the risks associated with a vulnerability. It encompasses actions such as reporting, coordinating, and publishing information about a vulnerability and its resolution. The goals of vulnerability disclosure include the following: a) ensuring that identified vulnerabilities are addressed; b) minimizing the risk from vulnerabilities; c) providing users with sufficient information to evaluate risks from vulnerabilities to their systems”.
Das bedeutet: Im Idealfall entscheidet sich ein Mensch, der eine Schwachstelle findet – motiviert von dem bestehenden Anreizsystem – diese koordiniert offenzulegen, damit IT-Sicherheit gestärkt wird. Er tritt dann direkt oder über vermittelnde Instanzen (“Intermediaries” oder “Reporter”) in Kontakt mit den Verantwortlichen. Vermittelnde Instanzen können andere Sicherheitsforschende sein, Organisationen wie der Chaos Computer Club oder BugBounty-Plattformen, zum Beispiel HackerOne. Die Verantwortlichen ermöglichen die Kontaktaufnahme durch leicht zu findende Kontaktdaten, zum Beispiel in einer security.txt. Zudem sollte es eine gut zugängliche Schwachstellen-Policy geben, die Findenden und Vermittelnden alle wichtigen Informationen mitteilt, etwa zum Ablauf und zu etwaigen Anreizen. Die Kontaktaufnahme sollte im Idealfall auch verschlüsselt und anonym möglich sein.
Der zweite Teil des Prozesses ist die größte Herausforderung. Hier koordinieren sich Findende, vermittelnde Instanzen und Verantwortliche. Die Aufgabe der Findenden ist es, ermittelte Informationen zur Verfügung zu stellen, damit die anderen Parteien die Schwachstelle verstehen und einen Patch oder andere risikominimierende Maßnahmen bereitstellen können. Die Aufgabe der Verantwortlichen ist es, zeitnah, verbindlich und klar mit den anderen Parteien zu kommunizieren und sich an ihre eigene Schwachstellen-Policy zu halten. Der Prozess wird mit der gemeinsamen Offenlegung abgeschlossen. Während also die Verantwortlichen einen Patch und entsprechende Informationen bereitstellen – in denen nach Abstimmung auch auf die Findenden hingewiesen wird –, veröffentlichen Findende parallel oder im Nachgang dazu ihre technische Analyse beispielsweise in (Fach-)artikeln, auf einem Blog oder stellen sie auf einer Konferenz vor.
Typischerweise hinterlegen die Findenden oder vermittelnde Instanzen, bei betroffenen großen Herstellern sie selbst und in Ausnahmefällen auch die Koordinatoren, technische Details in einer Schwachstellen-Datenbank – zum Beispiel in MITRE’s CVE-Datenbank. Diese dient unter anderem dazu, dass Betreiber die bereitgestellten, standardisierten Schwachstellen-Informationen bessere Risikoabschätzungen (automatisiert) für ihre IT-Infrastrukturen vornehmen können. Gleichzeitig gibt es durch diese Datenbanken einen Referenzpunkt für Schwachstellen, die einen Austausch darüber verbessern.
So würde der Ablauf im Idealfall aussehen. Aber davon gibt es unzählige Abweichungen, zum Beispiel wenn Verantwortliche die Schwachstelle nicht als solche anerkennen oder für nicht relevant erachten, sie nicht nachvollziehen können / wollen oder zu lange für einen Patch brauchen. Und natürlich kommt es zu Abweichungen, wenn eine oder mehrere Parteien sich nicht mehr an die informell vereinbarten Aufgaben und Verantwortlichkeiten halten. Wenn zum Beispiel Verantwortliche einen Patch veröffentlichen, ohne die Offenlegung mit Findenden oder vermittelnden Instanzen zu koordinieren, oder wenn Findende Informationen über die Schwachstellen veröffentlichen, ohne dass der Offenlegungsprozess seitens der Verantwortlichen abgeschlossen ist, etwa mit der Bereitstellung eines Patches oder einer Warnmitteilung an Kunden. Oder wenn Verantwortliche trotz Zusage keinen Patch für die Sicherheitslücke bereitstellen, aber sie die Findenden bereits mit einer formellen Vereinbarung zum Stillhalten zwingen konnten.
Welche Rolle kann der Staat spielen?
Auch der Staat muss seinen Teil dazu beitragen, dass ein Ökosystem entsteht, in dem koordinierte Schwachstellen-Offenlegung funktioniert. Er hat ein Eigeninteresse daran, denn funktionierende Prozesse erhöhen die IT-Sicherheit. Zunächst einmal wäre es Aufgabe der zuständigen Ministerien und Parlamenten, den vorhin erwähnten sicheren Rechtsrahmen für Sicherheitsforschende zu schaffen. Zusätzlich muss er mit Policies und Rechtsakten dafür Sorgen, dass Findende von Schwachstellen sich an die zuständigen Cybersicherheitsbehörden oder betroffene Verantwortliche wenden, um Unterstützung zu erhalten. Damit dies geschieht, sollte (gesetzlich) geregelt sein, dass Cybersicherheitsbehörden die Schwachstellen, die ihnen zur Offenlegung übermittelt werden, nicht für eigene Schad- oder Überwachungssoftwaren nutzen; dies würde aller Erfahrung nach zahlreiche Findende von einer Kontaktaufnahme abschrecken.
Des Weiteren kommt dem Staat, also seinen Behörden und weiteren Organisationen, eine Vorbildfunktion zu. Diese beinhaltet, dass er sich sowohl als Findende von Schwachstellen als auch als Verantwortliche für Software und Hardware an internationalen Standards, technischen Richtlinien und konkreten Handreichungen zur koordinierten Schwachstellen-Offenlegung hält.
In Gestalt seiner nationalen Cybersicherheitsbehörde kommt dem Staat noch eine weitere Rolle zu. Sie kann als Koordinator zwischen Findenden, beziehungsweise vermittelnden Instanzen und Verantwortlichen fungieren. Das ist vor allem dann der Fall, wenn Findende oder vermittelnde Instanzen den Verantwortlichen nicht vertrauen, also zum Beispiel Angst vor rechtlichen Konsequenzen haben, oder wenn die Kommunikation mit den Verantwortlichen nicht funktioniert beziehungsweise diese sich nicht an ihre Absprachen halten. Dann kann der Staat, also in diesem Fall die staatliche Cybersicherheitsbehörde, die Offenlegung koordinieren und bei Bedarf Druck auf die Verantwortlichen ausüben. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt diese Rolle auch in seiner entsprechenden Leitlinie. Hier heißt es: „Im Rahmen eines CVD-Prozesses kann das BSI, vertreten durch das Computer Emergency Response Team des Bundes (CERT-Bund), eine Rolle als Koordinator oder Vermittler zwischen Sicherheitsforschenden und Verantwortlichen einnehmen und dabei unterstützen, dass Schwachstellen schnellstmöglich behoben werden”.
Dies kann im Einzelfall dazu beitragen, dass aus einer Offenlegung, die unkoordiniert zu werden droht, zum Beispiel wegen mangelnder Responsivität der Verantwortlichen, doch noch eine koordinierte Offenlegung wird. Die Cybersicherheitsbehörde sollte – und die deutsche tut das bereits – Kommunikationsmöglichkeiten bereithalten, die auch eine anonyme Kontaktaufnahme ermöglichen. Gleichzeitig müssen Sicherheitsforschende darauf vertrauen können, dass Cybersicherheitsbehörden sich auch als Koordinatoren im Sinne der IT-Sicherheit einsetzen und gemeldete Schwachstellen nicht – zum Beispiel durch andere Behörden wie Polizeien oder Nachrichtendienste – in Überwachungs- oder Schadsoftware landen.
Aktueller Stand: Wir waren schon einmal weiter
Natürlich weicht auch im Bereich der koordinierten Schwachstellen-Offenlegung die Praxis von der Theorie ab. Es ist eines der vielen IT-Sicherheitsthemen, bei denen wir in der Theorie mittlerweile sehr gut wissen, wie sie funktionieren sollten – und bei denen es aber in der Praxis und in der Umsetzung oftmals hakt – häufig auf Seiten der Verantwortlichen und leider auch in der aktuell bestehenden Gesetzgebung.
Die Rolle des Staates ist bisher noch weitaus weniger beleuchtet als die der traditionellen Akteure – Findende, Meldende, Vermittelnde und Verantwortliche. Aus diesem Grund arbeiten wir aktuell mit einer internationalen, interdisziplinären Arbeitsgruppe daran, die Rolle und die Aufgaben des Staates besser zu definieren. Leider gibt es auch entgegengesetzte Entwicklungen. So hat die Volksrepublik China eine Rechtslage geschaffen, die dazu führt, dass gefundene Schwachstellen staatlichen Stellen gemeldet werden müssen und dann in Cyberoperationen ausgenutzt werden können. Weiterhin steht zu befürchten, dass die derzeit verhandelte Cybercrime Konvention der Vereinten Nationen einen Rückschritt beim Rechtsschutz der IT-Sicherheitsforschenden darstellt.
Will Deutschland also IT-Sicherheit durch koordinierte Schwachstellen-Offenlegung stärken, muss es international gegen diese Entwicklungen vorgehen. Gleichzeitig sollte Deutschland stärker auf die Bedeutung des Bundesamtes für Sicherheit in der Informationstechnik für die koordinierte Schwachstellen-Offenlegung hinweisen, damit diese Rolle stärker bekannt wird. Zudem sollte die Behörde durch vertrauensbildende Maßnahmen und konkrete Angebote attraktiver als Vermittlungs- und Eskalationsinstanz für Schwachstellen-Findende gemacht werden und die Rechtssicherheit der Findenden im entsprechenden Rahmen hierbei gegeben sein. Hierzu, konkret zur Reform des Computerstrafrechts, gibt es unter Federführung des Bundesministeriums der Justiz bereits einen Prozess, der jedoch noch nicht abgeschlossen ist.
Um seiner Rolle als Koordinator gerecht werden zu können, muss die entsprechende Ressourcenausstattung innerhalb der zuständigen Behörde geprüft und gegebenenfalls nachjustiert werden. Denn je mehr die Dienste der Behörde als Koordinator in Anspruch genommen werden, desto wichtiger ist die Personalausstattung. Im CERT Guide to Coordinated Vulnerability Disclosure heißt es dazu: „Due to the possibility of burnout and the associated costs, the CERT/CC recommends that CVD capability be established within a well-resourced team or teams specifically created for this task, rather than concentrating the responsibilities to a small team, or even a single person”. Ist er nicht hinreichend ausgestattet, kann der Koordinator nur selektiv oder unzureichend tätig werden („Triage”), was möglicherweise seiner Reputation und damit verbunden dem Vertrauen der Findenden und Verantwortlichen in seine Rolle schaden kann.
Dem Bundesamt für Sicherheit in der Informationstechnik obliegt es neben den operativen Aufgaben, auch Verantwortliche über den Prozess zur koordinierten Offenlegung von Schwachstellen aufzuklären. Viele sehen sich nur als Herstellende von zum Beispiel Smart TVs, Kühlschränken oder KI-Applikationen, ohne zu wissen, dass auch Kühlschrankhersteller eine Verantwortung für die IT-Sicherheit ihrer Geräte haben und für ihr Schwachstellenmanagement dringend entsprechende Prozesse brauchen — spätestens dann, wenn der Cyber Resilience Act in Kraft tritt, der die Verantwortlichen nach aktuellem Stand dazu verpflichten wird.
Sven Herpig ist Leiter für Cybersicherheitspolitik und Resilienz bei Interface (vorher: Stiftung Neue Verantwortung).
In unserer Reihe „Perspektiven“ kommentieren unsere Kolumnist:innen regelmäßig aktuelle Entwicklungen, Trends und Innovationen im Bereich Cybersicherheit ein. Zuletzt von Herpig erschienen: Was kommt nach dem Ende des Lebenszyklus?
