Skip to main content

Verantwortungsvolle Offenlegung verstehen

Artikel von
Headshot of Tim Kadlec

Tim Kadlec

31. Januar 2017

0 Min. Lesezeit

Der Umgang mit Sicherheitslücken ist ein ständiger Kampf. Es ist ein Wettlauf zwischen Angreifern und den Organisationen, die sie fernhalten wollen. Leider verlieren die Organisationen häufig. Wie der ehemalige FBI-Direktor Robert Mueller es formulierte: „… es gibt nur zwei Arten von Unternehmen: solche, die gehackt wurden, und solche, bei denen das noch passieren wird.“

Um Ihr System zu schützen, müssen Sie die gesamte Anwendung absichern können. Ein Angreifer hingegen muss nur eine einzige Schwachstelle finden. Organisationen brauchen einen Vorsprung. Dabei spielt es eine wichtige Rolle, wie sie von Sicherheitslücken in ihrem Code erfahren.

Auf den ersten Blick scheint die Sache einfach: Wenn Sie eine Sicherheitslücke finden, kontaktieren Sie die Organisation und informieren Sie sie. Sie behebt die Lücke und alle können erleichtert und sicherer weitermachen. Die Realität sieht jedoch anders aus: Die Offenlegung von Sicherheitslücken ist seit Langem eines der meistdiskutierten Themen der Sicherheitsbranche.

Das Zeitfenster für Angriffe verkleinern

Bruce Schneier machte das Konzept des „Zeitfensters für Angriffe“ bekannt: den Zeitraum, in dem eine Sicherheitslücke ausgenutzt werden kann.

Das Zeitfenster für Angriffe beginnt, sobald eine Sicherheitslücke in einer Produktionsumgebung auftritt. Das Angriffsrisiko ist zu diesem Zeitpunkt relativ gering. Die Sicherheitslücke besteht zwar, wurde aber noch von niemandem entdeckt.

Sobald jemand die Sicherheitslücke entdeckt, steigt das Risiko. Danach nimmt es weiter zu, je bekannter die Lücke wird. Irgendwann wird ein Patch oder Upgrade veröffentlicht. Ab diesem Zeitpunkt sinkt das Risiko langsam, wenn Nutzerinnen und Nutzer die Fehlerbehebung installieren – was nur selten schnell geschieht.

Schneier veranschaulicht die Höhe des Risikos gern mit einem Diagramm. Die Fläche unter der Kurve stellt dabei das Zeitfenster für Angriffe dar. Ziel ist es also, dieses Zeitfenster zu verkleinern.

Das Risiko steigt nach Bekanntgabe einer Sicherheitslücke, erreicht vor der Bereitstellung eines Patches seinen Höhepunkt und sinkt, sobald Nutzer mit dem Patchen beginnen.

Wie sich das am besten erreichen lässt, darüber wird debattiert.

Wenn eine Sicherheitslücke im Wald auftritt und niemand sie ausnutzt, gibt es sie dann überhaupt?

Ein Argument lautet: Wenn Sie eine Sicherheitslücke entdecken, sollten Sie sie der Organisation melden und niemals öffentlich machen. So bleibe die Lücke sicher in der wenig beachteten Phase ihres Lebenszyklus, wodurch das Risiko minimiert werde.

Diese Denkweise hat einige Schwächen. Zum einen setzt sie gefährlicherweise voraus, dass nur die Person mit guten Absichten die Lücke entdeckt hat. Wenn auch Angreifer sie gefunden haben, warten diese nicht einfach ab, bis die Organisation das Problem erkennt. Sie nutzen vielmehr aus, dass ihnen eine noch ungepatchte Sicherheitslücke offensteht.

Eine weitere Schwäche dieses Ansatzes ist die Annahme, dass sich das Unternehmen ausreichend um die Sicherheitslücke kümmert, um etwas dagegen zu unternehmen. Tatsächlich fehlt es an Anreizen. Anfangs war dies die gängigste Art, Sicherheitslücken offenzulegen. In vielen Fällen führte das dazu, dass Organisationen Jahre brauchten, um eine Lücke zu schließen. Sie glaubten, dass ihnen die fehlende öffentliche Bekanntmachung eine gewisse Sicherheit verschaffte. Unwissenheit als zusätzliche Sicherheitsebene, im Grunde.

Aus Angst vor negativer Publicity, die manche Sicherheitsprobleme mit sich bringen, drohten Organisationen mitunter sogar Forschenden, die versuchten, das Problem zu melden. Leider kommt das gelegentlich noch immer vor. Deshalb ziehen es manche Sicherheitsforschende vor, sich an eine Organisation oder Person zu wenden, die das Problem anschließend dem Unternehmen meldet. Das übernehmen wir bei Snyk gern und haben es auch schon getan. So werden die Forschenden selbst vor übermäßig aggressivem Verhalten der verantwortlichen Person oder Organisation geschützt.

Vollständige öffentliche Offenlegung

Am genau entgegengesetzten Ende des Spektrums steht die vollständige öffentliche Offenlegung. Statt eine Organisation zu informieren, könnte eine forschende Person die Sicherheitslücke mitsamt allen Einzelheiten öffentlich machen. Die Lücke überspringt damit den langsamen Anstieg ihrer Bekanntheit und wird sofort allgemein bekannt. Von da an beginnt ein Wettlauf zwischen der Organisation und den Angreifern.

Dieser Ansatz schafft für die Organisation einen offensichtlichen Anreiz, das Problem schnell zu beheben. Der Nachteil liegt jedoch ebenfalls auf der Hand: Dieselbe Öffentlichkeit, die diesen Anreiz schafft, setzt Organisationen – und ihre Nutzerinnen und Nutzer – einem erheblichen Risiko aus, da Angreifer sofort von der Sicherheitslücke und den Angriffsmöglichkeiten erfahren.

Verantwortungsvolle Offenlegung

Irgendwo in der Mitte liegt ein Ansatz, auf den sich der Großteil der Branche geeinigt hat: die verantwortungsvolle Offenlegung. Sie umfasst einige grundlegende Schritte.

  1. Die Sicherheitslücke wird dem Verantwortlichen oder der Organisation vertraulich gemeldet.

  2. Es wird eine Fehlerbehebung entwickelt, in der Regel von der verantwortlichen Person oder Organisation (häufig unterstützt durch die meldende Person).

  3. Die Fehlerbehebung wird veröffentlicht und für Nutzerinnen und Nutzer bereitgestellt.

  4. Die Sicherheitslücke wird öffentlich bekannt gemacht. Diese Offenlegung enthält Informationen zur Sicherheitslücke, dazu, wie der Exploit ausgeführt wird, sowie zur Behebung des Problems.

Das klingt vielleicht ähnlich wie die Idee, Sicherheitslücken geheim zu halten. Es gibt jedoch einen wichtigen Unterschied: Bei einer verantwortungsvollen Offenlegung gilt in der Regel eine angemessene Frist.

Bei Snyk räumen wir beispielsweise zunächst der für ein Paket verantwortlichen Person 30 Tage ein, um auf unsere Meldung zu reagieren. Das ist eine recht übliche Frist in der Open-Source-Entwicklung, wo Autorinnen und Autoren häufig einem anderen Hauptberuf nachgehen. Manchmal meldet sich die verantwortliche Person. Dann können wir sie bei der Suche nach einer Lösung unterstützen und gemeinsam festlegen, welcher Zeitraum angemessen ist, bevor die Sicherheitslücke öffentlich gemacht wird. So können Menschen Maßnahmen zu ihrem Schutz ergreifen.

In einer idealen Welt würde jede Offenlegung einer Sicherheitslücke so ablaufen. Die Realität sieht jedoch etwas anders aus, und manchmal reagiert die verantwortliche Person nicht. Verantwortungsvolle Offenlegung bedeutet: Reagiert eine Organisation nicht innerhalb der festgelegten Frist, kann die meldende Person die Sicherheitslücke öffentlich machen. So erfahren Nutzerinnen und Nutzer von dem Risiko und können entscheiden, ob sie es in ihren eigenen Systemen in Kauf nehmen wollen. Zugleich werden Verantwortliche und Organisationen dazu angehalten, das Problem vorrangig zu beheben, da es nun öffentlich bekannt ist.

Bei Snyk tun wir unser Bestes, damit Verantwortliche und Organisationen einen Vorsprung erhalten. Wenn wir innerhalb von 30 Tagen nichts von ihnen hören, kontaktieren wir sie erneut und räumen ihnen weitere 10 Tage ein. Bleibt eine Antwort aus, wiederholen wir das noch einmal. Insgesamt geben wir ihnen 50 Werktage Zeit, um zu reagieren. Nur wenn wir in dieser Zeit keine Antwort erhalten oder die verantwortliche Person erklärt, dass sie die Offenlegung nicht koordinieren möchte, machen wir die Sicherheitslücke öffentlich.

Bei diesem Verfahren gibt es eine bemerkenswerte Ausnahme. Unsere Enterprise-Nutzer erhalten frühzeitig Benachrichtigungen über die Sicherheitslücke. Eine Geheimhaltungsvereinbarung (NDA) stellt sicher, dass sie zu diesem Zeitpunkt noch nicht öffentlich gemacht wird.

Die Ethik der Offenlegung

2016 entdeckte ein Cybersicherheitsunternehmen Sicherheitslücken in Geräten von St. Jude Medical (Herzschrittmacher, Defibrillatoren usw.). Statt ein Verfahren zur verantwortungsvollen Offenlegung zu befolgen, veröffentlichte das Unternehmen unvollständige Informationen zu den Sicherheitslücken und tat sich anschließend mit einer anderen Organisation zusammen, um auf fallende Kurse von St. Jude Medical zu spekulieren.

Damit entfachte die Debatte über verantwortungsvolle Offenlegung erneut. Der CEO des Unternehmens argumentierte, angesichts früherer Erfahrungen mit St. Jude sei dieser Ansatz seiner Meinung nach nicht praktikabel gewesen.

Selbst wenn wir die fragwürdige Ethik von Leerverkäufen nach der Veröffentlichung dieser unvollständigen Informationen außen vor lassen, ist der Schaden dieses Vorgehens erheblich. Die unvollständigen Informationen schaden dem Ruf von St. Jude, ohne dem Unternehmen dabei zu helfen, den zugrunde liegenden Problemen näherzukommen. Stattdessen befinden sich St. Jude und die Angreifer auf Augenhöhe: Beide wissen nun, dass ein Problem besteht, und beide versuchen herauszufinden, wer es zuerst entdeckt. Ob St. Jude innerhalb einer angemessenen Frist reagiert hätte, werden wir nie erfahren – St. Jude hatte diese Möglichkeit gar nicht.

Die Sicherheitsbranche ist insofern interessant, als gute Arbeit ein gewisses Maß an Misstrauen gegenüber den Menschen erfordert, die auf Ihre Server und Anwendungen zugreifen. Umso wichtiger ist es, dass wir vertrauenswürdig und ethisch handeln, wenn wir die Sicherheit im Internet verbessern wollen.

Es ist entscheidend, Sicherheitslücken ethisch und verantwortungsvoll offenzulegen und dabei Organisationen und Verantwortlichen so wenig Schaden wie möglich zuzufügen – und gleichzeitig Nutzerinnen und Nutzer zu schützen. Wir sind fest davon überzeugt, dass ein Verfahren zur verantwortungsvollen Offenlegung die richtige Balance schafft. Organisationen erhalten einen Vorsprung: Sie werden vertraulich über eine Sicherheitslücke informiert und haben Zeit, sie zu beheben, bevor das Risikofenster zu groß wird.

Dabei werden Nutzerinnen und Nutzer keinem Risiko ausgesetzt. Wenn eine Organisation einer Sicherheitslücke keine Priorität einräumt oder nicht reagiert, wird sie nicht unter den Teppich gekehrt. Sie kann öffentlich bekannt gemacht werden, damit nichts ahnende Nutzerinnen und Nutzer von dem Problem erfahren und geeignete Maßnahmen ergreifen können.

Sicherheit ist zu wichtig, um Probleme unter den Teppich zu kehren, und aus Sicherheitslücken gibt es zu viel zu lernen, als dass wir das zulassen könnten. Organisationen müssen jedoch die Möglichkeit erhalten, diese Sicherheitslücken zu beheben, bevor sie öffentlich gemacht werden. Sicherheit ist schon schwierig genug – wir sollten Angreifern keinen unnötigen Vorsprung verschaffen.

Wenn Sie mehr darüber erfahren möchten, wie wir bei Snyk mit der Offenlegung von Sicherheitslücken umgehen, finden Sie unsere vollständigen Richtlinien online. Wenn Sie eine Sicherheitslücke entdecken und möchten, dass wir Sie bei der Offenlegung unterstützen, helfen wir Ihnen gern weiter.

Weiterlesen

AI Background min crop
Blog

KI ruft alle Risiken auf den Plan, die Sie akzeptiert haben: Sieben Erkenntnisse aus dem AI Security Panel: Unfiltered

KI macht Angriffe günstiger und schneller und legt Risiken offen, die Unternehmen bereits tragen. Vier Sicherheitsverantwortliche erklären, warum Abwehr in Maschinengeschwindigkeit und schnellere Behebung jetzt unverzichtbar sind.

Blog

Frontier-Modelle fanden die Schwachstellen. Nur der Angreifer fand die Angriffsketten.

Die statische Analyse fand die Schwachstellen, doch erst Live-Angriffstests bewiesen, wie sie sich zu Angriffen verketten lassen. Ein Vergleich von Evo COS, Claude Security und Claude Code Security.

feature insights context
Blog

Autonome Angriffe sind bereits Realität. Die Verteidigung muss Schritt halten.

Autonome Angreifer verkürzen das Zeitfenster für die Verteidigung. Erfahren Sie, wie kontinuierliches Erkennen, Beheben, Validieren und Verhindern Sicherheitsteams helfen kann, Schritt zu halten.