Troopers 2018: "Responsible Disclosure hilft nur dem Hersteller"

Mit einem streitbaren Konzept will der Hacker Graeme Neilson mehr Kommunikation zwischen Sicherheitsforschern und Nutzern von Technologie schaffen. Er ist überzeugt, dass das klassische Modell von Responsible Disclosure nicht funktioniert.

Ein Interview von Hauke Gierow veröffentlicht am 16. März 2018, 9:01 Uhr

Mit Artistic Disclosure sollen Sicherheitslücken schneller geschlossen werden - sagt unser Interviewpartner. (Symbolbild) (Bild: Peter Macdiarmid/Getty Images)

"Die IT-Sicherheitsindustrie hat in den vergangenen 20 Jahren versagt, die wirklichen Probleme zu lösen." Das hat der Hacker Graeme Neilson auf der Sicherheitskonferenz Troopers in Heidelberg gesagt. Er fordert mehr öffentliche Aufmerksamkeit für Sicherheitsprobleme. Es solle in Zukunft gesellschaftlich inakzeptabel sein, unsichere Software auf den Markt zu bringen. Ungefähr so, wie es heute nicht akzeptabel sei, ein Auto ohne Anschnallgurte herauszubringen.

Inhalt:

1. Troopers 2018: "Responsible Disclosure hilft nur dem Hersteller"
2. Ist Wanna Cry Artistic Disclosure gewesen?

Um das zu erreichen, will Graeme eine neue Beziehung zwischen Software-Herstellern und Diensteanbietern etablieren. Denn viele Nutzer würden über Sicherheitslücken und ihre möglichen Folgen meist nicht richtig informiert - und hätten daher nur wenig Bewusstsein dafür.

Dafür schlägt Neilson ein neues, streitbares Konzept für das Melden von Sicherheitslücken vor - im Widerspruch zum meist verwendeten Responsible Disclosure, wo Sicherheitslücken vorab an den Hersteller gemeldet werden, damit er diese schließen kann. Uns hat er erklärt, was genau er unter einem solchen Konzept versteht.

Golem.de: Sie haben in Ihrem Keynote-Vortrag ein neues Konzept für das Melden von Sicherheitslücken gefordert - Artistic Disclosure. Was genau meinen Sie damit?

Graeme Neilson: Responsible Disclosure ist eigentlich protektionistisches Disclosure. Niemand außer dem Hersteller bekommt die Information - jedenfalls zunächst. Man erzählt dem Hersteller von einer Sicherheitslücke und nicht den Leuten, die es eigentlich wissen sollten. Wenn man den Leuten diese Informationen vorenthält, handelt man eigentlich unverantwortlich.

Artistic Diclosure soll ein Problem der Sicherheitsindustrie lösen. Diese tut sich sehr schwer, das eigene Wissen in geeigneter Weise an die Nutzer weiterzugeben. Nutzer werden also nicht wirklich gut über Probleme informiert, deswegen haben sie eigentlich ein zu positives Bild von der Sicherheitslage.

Mit Artistic Disclosure soll dieser Informationsfluss verbessert werden. Nutzer sollen in die Lage versetzt werden, eine Sicherheitslücke sowohl intellektuell als auch emotional zu verstehen. Letztlich nutze ich dann einfach die Sicherheitslücke selbst, um mit den Nutzern zu kommunizieren. Das kann in der Praxis ganz verschieden aussehen.

Golem.de: Haben Sie ein Beispiel?

Neilson: Ein Freund von mir hat einmal ein Problem in Snapchat gefunden. Es war möglich, Nutzern aus der Ferne eine Nachricht zu schicken, ohne Authentifizierung. Er wollte das Problem eigentlich per Responsible Disclosure melden - ich habe ihn davon abgebracht und wir haben etwas Spannenderes gemacht.

An einem Samstagabend - wir hatten wohl etwas zu viel getrunken - haben wir allen Snapchat-Nutzern eine Nachricht geschickt, in der stand: "Warnung, Zombie-Apokalypse. Dies ist keine Übung" und dazu einige Informationen über das Problem. Das Problem war nur wenige Stunden später am Sonntagmorgen behoben. Per Responsible Disclosure hätte das sicher länger gedauert.

Golem.de: Riskiert ein solches Vorgehen denn nicht die Sicherheit der Nutzer?

Neilson: Wenn die Sicherheitslücke nur an den Hersteller gemeldet wird, dann dauert es oft lange, bis diese geschlossen wird. Wer sagt denn, dass nur ich das Problem gefunden habe und es nicht bereits ausgenutzt wird? Außerdem hilft dieser Prozess nur dem Hersteller - er kontrolliert die Information und die meisten Nutzer werden nie mitbekommen, dass es eine Sicherheitslücke gab und wie diese ausgenutzt werden kann.