Coordinated vulnerability disclosure

Koordinierte Offenlegung von Schwachstellen (CVD)

Wie man Sicherheitslücken meldet, entgegennimmt und koordiniert, mit Beispielrichtlinien.

Koordinierte Offenlegung von Schwachstellen (Coordinated Vulnerability Disclosure, CVD) ist ein Begriff aus der Computersicherheit. Er beschreibt, wie Menschen Meldungen über Sicherheitsprobleme austauschen können. Beispiele sind Fehlerberichte, Einbruchsrisiken, Hackerwarnungen, Datenlecks, Einbrüche in Websites usw.

Übersetzungen: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

Inhalt:

Richtlinien:

Einführung

Dieses Dokument erklärt die koordinierte Offenlegung von Schwachstellen auf eine Weise, die Menschen bei der Zusammenarbeit helfen kann.

Ziele des Dokuments:

  1. Menschen helfen, die Sicherheitsprobleme entdecken und melden möchten.

  2. Vertretern von Unternehmen helfen, die Bedürfnisse, Ziele, Praktiken und Sonderfälle der verantwortungsvollen Offenlegung zu verstehen.

  3. Beispiele für Richtlinien zur koordinierten Offenlegung von Schwachstellen in den Repository-Ordner aufnehmen.

Wir freuen uns über Pull Requests, GitHub-Issues oder E-Mails an security@joelparkerhenderson.com.

Was ist koordinierte Offenlegung von Schwachstellen?

Koordinierte Offenlegung von Schwachstellen beschreibt drei Schritte, wenn jemand ein Sicherheitsproblem (etwa einen Softwarefehler) entdeckt und es dem Hersteller (etwa dem Unternehmen, das die Software herstellt) melden möchte.

Schritte:

  1. Die entdeckende Person meldet das Problem dem Hersteller vertraulich und in gutem Glauben.

  2. Der Hersteller versucht in gutem Glauben, die Nutzer zu schützen und das Problem zu beheben.

  3. Nach einer vereinbarten Zeitspanne wird das Sicherheitsproblem öffentlich gemacht.

Schritt 1: Das Problem melden

Schritt 1 ist Aufgabe der entdeckenden Person: das Problem vertraulich und in gutem Glauben melden.

  • Gut: Die entdeckende Person sendet die relevanten Informationen an den Hersteller, etwa per E-Mail an die Sicherheits-E-Mail-Adresse des Herstellers (typischerweise "security@example.com") oder über ein Webformular auf der Website des Herstellers (typischerweise "https://www.example.com/security").

  • Schlecht: den Bericht in einem öffentlichen Blog veröffentlichen, die Medien alarmieren, drohen oder versuchen, das Sicherheitsproblem an Hacker zu verkaufen usw.

  • Tipp: Die entdeckende Person kann anonym bleiben; auch der Hersteller kann anonym bleiben.

Wenn Sie möchten, bleiben Sie weiter über das Problem im Bilde.

  • Gut: Kommunikationswege offen halten, Folgeinformationen liefern oder die Lage beobachten.

  • Schlecht: das Problem vergessen.

  • Tipp: Die entdeckende Person kann sich entscheiden, zu helfen oder nicht, in Kontakt zu bleiben oder nicht, und die Vereinbarung auch ändern, wenn sich die Umstände ändern.

Wenn Sie möchten, legen Sie das Problem anderen gegenüber offen.

  • Gut: die vereinbarte Zeit abwarten und dann an die Öffentlichkeit gehen, etwa indem die relevanten Informationen auf einer Sicherheitsnachrichten-Seite veröffentlicht werden, relevante externe Sicherheitsforscher kontaktiert werden oder das Problem in einem öffentlichen sozialen Netzwerk bekannt gegeben wird usw.

  • Schlecht: das Problem anderen nicht offenlegen, es sei denn, Sie meinen, dass dies für Sie selbst oder andere ein höheres Risiko als vergleichbar mit sich brächte.

  • Tipp: Ändern sich die Umstände, etwa weil ein höheres Risiko oder ein aktiver Exploit in freier Wildbahn entdeckt wird, kann die entdeckende Person das Problem früher anderen gegenüber offenlegen.

Schritt 2: Kontakte sicherstellen

Schritt 2 ist Aufgabe des Herstellers: sicherstellen, dass die Kontakte funktionieren.

  • Gut: Der Hersteller veröffentlicht eine Sicherheitskontakt-E-Mail-Adresse (üblicherweise "security@example.com") und idealerweise einen Schlüssel für sichere E-Mail-Verschlüsselung.

  • Gut: Der Hersteller veröffentlicht eine Sicherheitskontakt-Webseite (üblicherweise "https://www.example.com/security") und macht die Seite idealerweise leicht auffindbar, etwa über die Fußzeile der Website, die Sitemap und die Suche.

  • Schlecht: Der Hersteller stellt weder eine E-Mail-Adresse noch eine Webseite bereit oder macht sie nicht leicht auffindbar.

Fähigkeiten der Mitarbeitenden sicherstellen.

  • Gut: Der Hersteller schult den Support, was zu tun ist, wenn eine Sicherheitsanfrage eingeht, etwa wie mit Kontaktinformationen geantwortet oder die Anfrage an das richtige interne Team weitergeleitet wird.

  • Gut: Der Hersteller prüft regelmäßig, ob die Fähigkeiten der Mitarbeitenden funktionieren.

  • Schlecht: Der Hersteller schult nicht oder prüft nicht.

Der entdeckenden Person innerhalb der Frist antworten.

  • Gibt die entdeckende Person keine Frist an, dann gilt ein Werktag, weil dies Branchenstandard und aktuelle Best Practice der Branche ist.

  • Stellt die entdeckende Person Fragen, beantworten Sie sie. Das ist besonders wichtig, wenn sie um Erlaubnis zum Testen bittet. Achten Sie darauf, dass alle Antworten klar und direkt sind.

Der entdeckenden Person über einen autorisierten Sicherheitskontakt und/oder einen autorisierten Sicherheitsprozess antworten.

  • Gut: eine Antwort von einer sicherheitsspezifischen E-Mail-Adresse, etwa "security@example.com".

  • Zum Beispiel schlecht: eine Antwort von einer allgemeinen E-Mail-Adresse wie "help@example.com" oder von jemandem, der kein autorisierter Sicherheitsfachmann ist.

Der entdeckenden Person bestätigen, dass das Problem als Sicherheitsmeldung erkannt wurde.

  • Gut: sicherheitsspezifische Formulierungen, etwa "Unser Sicherheitsteam hat Ihre Meldung zur verantwortungsvollen Offenlegung erhalten", oder "Unser Sicherheitsprozess sieht folgende nächste Schritte vor", oder "Ihre Informationen befinden sich jetzt in unserem Sicherheits-Tracker mit der ID XYZ" usw.

  • Schlecht: allgemeine Formulierungen wie "Wir schätzen Ihre Geschäftsbeziehung" oder "Wir nehmen Sicherheit ernst", Formulierungen, die den Schwarzen Peter weiterreichen, wie "Wir haben Ihre E-Mail an eine andere Abteilung weitergeleitet" usw.

Schritt 3: In gutem Glauben zusammenarbeiten

Schritt 3 ist Aufgabe der entdeckenden Person und des Herstellers gemeinsam: in gutem Glauben zusammenarbeiten.

Verstehen Sie, dass koordinierte Offenlegung von Schwachstellen ein Verfahren in gutem Glauben beschreibt.

  • Ziel Nr. 1 ist guter Glaube, den Nutzern zu helfen, sich vor Sicherheitsrisiken zu schützen.

  • Ziel Nr. 2 ist guter Glaube, das Sicherheitsproblem zu beheben.

  • Die entdeckende Person und/oder der Hersteller können sich in gutem Glauben entscheiden, weitere Sicherheitsleute einzubeziehen, etwa andere relevante Sicherheitsforscher zu kontaktieren, die bei dem Problem helfen.

Verstehen Sie, dass koordinierte Offenlegung von Schwachstellen keine Verpflichtung begründet.

  • Die entdeckende Person und/oder der Hersteller können jederzeit aus beliebigem Grund aussteigen, mit oder ohne Vorwarnung. Es ist höflich, alle relevanten Personen informiert und auf dem Laufenden zu halten, doch das ist nicht immer möglich, praktikabel oder wünschenswert.

  • Koordinierte Offenlegung von Schwachstellen begründet keine rechtliche Vereinbarung. Wenn die entdeckende Person und der Hersteller bereits eine rechtliche Vereinbarung haben, empfehlen wir allen Beteiligten, die zuständigen Anwälte zu konsultieren; verwenden Sie dieses Dokument nicht als Rechtsberatung.

Verstehen Sie, dass koordinierte Offenlegung von Schwachstellen auf gute Kommunikation setzt und Drohungen ablehnt.

  • Koordinierte Offenlegung von Schwachstellen funktioniert am besten, wenn alle Beteiligten verstehen, dass Ziel Nr. 1 ist, den Nutzern zu helfen, sich vor Sicherheitsrisiken zu schützen, und Ziel Nr. 2, das Sicherheitsproblem zu beheben.

  • Koordinierte Offenlegung von Schwachstellen lehnt jede Art von Drohung mit Vergeltung, Einschüchterung, Sperrung, Entzug, Erpressung, Nachverfolgungslast oder Schuldzuweisung an das Opfer ab.

Verstehen Sie, dass koordinierte Offenlegung von Schwachstellen für verschiedene Menschen Unterschiedliches bedeuten kann.

  • Die entdeckende Person und der Hersteller haben möglicherweise ein unterschiedliches Verständnis von koordinierter Offenlegung von Schwachstellen. Diese Verständnisse müssen nicht übereinstimmen. Guter Glaube schließt ein, dass alle Beteiligten dies verstehen.

  • Manche Hersteller veröffentlichen Richtlinien zur koordinierten Offenlegung von Schwachstellen. Diese können eine hilfreiche Orientierung sein. Wählt eine entdeckende Person eine andere Art der koordinierten Offenlegung von Schwachstellen oder versteht sie verantwortungsvolle Offenlegung anders, ist das völlig in Ordnung.

Verstehen Sie, dass die entdeckende Person dem Herausgeber in der Regel einen Gefallen tut.

  • In der Regel braucht die entdeckende Person niemandes Erlaubnis, um Schwachstellen zu veröffentlichen.

  • In der Regel helfen die Informationen der entdeckenden Person dem Herausgeber.

Erfolg überprüfen

Nachdem das Problem gelöst ist, muss der Hersteller den Erfolg überprüfen.

  • Haben alle Personen und Prozesse die Offenlegung erfolgreich bewältigt? Wenn ja, gut. Wenn nicht, erwägen Sie eine Nachbetrachtung, etwa eine Ursachenanalyse (Root Cause Analysis, RCA), Post-Mortem-Berichte, Ishikawa-Diagramme oder eine auf Systemtheorie beruhende Kausalanalyse (CAST).

  • Werden noch offene Probleme priorisiert und nachverfolgt?

  • Verstehen Hersteller und entdeckende Person beide, was bei etwaigen nächsten Schritten zu tun ist? Das ist besonders wichtig, falls es weitere koordinierte Offenlegungen von Schwachstellen geben kann.

Orientierungshilfen

Orientierungshilfen für koordinierte Offenlegung von Schwachstellen können aus vielen Bereichen kommen, etwa von Ethikexperten, Rechtsvertretern, den berechtigten Erwartungen der Allgemeinheit usw.

Wenn Sie Orientierung suchen, interessieren Sie sich vielleicht für diese drei Bereiche, die alle unten beschrieben sind.

  • Barmherziger Samariter

  • Pflicht zur Hilfeleistung

  • Sorgfaltspflicht

Barmherziger Samariter

Wikipedia: Good-Samaritan-Gesetz

Good-Samaritan-Gesetze bieten rechtlichen Schutz für Menschen, die vernünftige Hilfe leisten für Personen, die verletzt, krank, in Gefahr oder anderweitig handlungsunfähig sind oder von denen man dies glaubt. Der Schutz soll das Zögern von Umstehenden verringern, aus Angst, verklagt oder strafrechtlich verfolgt zu werden.

Pflicht zur Hilfeleistung

Wikipedia: Pflicht zur Hilfeleistung

Eine Pflicht zur Hilfeleistung ist ein Konzept, das eine Situation beschreibt, in der eine Partei haftbar gemacht werden kann, weil sie einer anderen Partei in Not nicht zu Hilfe gekommen ist. Eine Pflicht zur Hilfeleistung kann moralische und/oder rechtliche Bereiche haben.

Sorgfaltspflicht

Wikipedia: Sorgfaltspflicht

Eine Sorgfaltspflicht ist die Verpflichtung, bei Handlungen, die andere vorhersehbar schädigen könnten, einen Standard angemessener Sorgfalt einzuhalten. Eine Sorgfaltspflicht kann moralische und/oder rechtliche Bereiche haben. Zu berücksichtigende Aspekte sind: die Vorhersehbarkeit des Schadens oder der Verletzung, das mögliche Ausmaß des potenziellen Schadens oder der Verletzung, die Bedeutung oder der gesellschaftliche Wert der vom Beklagten ausgeübten Tätigkeit, der Nutzen des Verhaltens für den Beklagten, die Machbarkeit alternativen Verhaltens, die mit dem alternativen Verhalten verbundenen Kosten und Lasten, der relative Nutzen des alternativen Verhaltens und die relative Sicherheit des alternativen Verhaltens.

Sonderfälle

Unsere Sicherheitsteams haben eine breite Palette von Sonderfällen erlebt.

Wir beschreiben sie hier, um verständlich zu machen, wo es eine große Bandbreite von Meinungen darüber gibt, was in Ordnung sein kann und was nicht. Wir empfehlen allen Beteiligten, hierüber in gutem Glauben zu kommunizieren.

Zugriff auf Informationen anderer Nutzer

Beispiel: Sie entdecken, dass eine URL Ihre Nutzer-ID enthält und einen Fehler offenbart, und Sie glauben, die URL so bearbeiten zu können, dass Ihre Nutzer-ID durch eine andere Nutzer-ID ersetzt wird.

  • Ist es in Ordnung, wenn die entdeckende Person dies tut, etwa mit dem alleinigen Ziel herauszufinden, ob auch andere Nutzer betroffen sind?

  • Ist es wichtiger, das Ausmaß des Risikos für alle Nutzer schnell zu verstehen, als ein paar Nutzer zu schützen, deren Informationen für Hacker möglicherweise ohnehin sichtbar sind?

  • Ist es in Ordnung, wenn die entdeckende Person dies mit so vielen Nutzern tut, wie sie möchte?

  • Ist es in Ordnung, wenn die entdeckende Person versucht, Nutzer zu kontaktieren, um sie wissen zu lassen, dass sie betroffen sind? Ist es in Ordnung, Vorschläge zur Schadensbegrenzung zu machen?

Dienstverweigerung

Beispiel: Sie entdecken einen Fehler, der versehentlich Ihr Konto sperrt, etwa indem er eine Passwortsperre auslöst.

  • Gilt dies als Denial-of-Service-Angriff?

Unerbetene E-Mails

Beispiel: Sie versuchen, ein Sicherheitsproblem Personen im Unternehmen zu melden, die Sie für zuständig halten und die Sie durch Recherche auf LinkedIn, Facebook usw. oder durch Namenskonventionen wie "webmaster@example.com" oder "security@example.com" ermitteln.

  • Ist das in Ordnung?

  • Gilt dies als unerbetene E-Mail?

  • Gilt dies als nicht autorisierte E-Mail?

Ausgeschlossene Gruppen

Beispiel: Sie gehören einer ausgeschlossenen Gruppe an, etwa als Minderjähriger, auf einer Sanktionsliste oder in einem Land auf einer Sanktionsliste.

  • Ist es für Sie in Ordnung, eine Meldung zu machen?

  • Ist es in Ordnung, anonym zu melden?

  • Ist es in Ordnung, potenziell identifizierende Informationen absichtlich zu ändern, etwa um der ausgeschlossenen Gruppe zu entgehen, mit dem Ziel, der Offenlegung zu helfen, die richtigen Leute zu erreichen?

Dritte

Beispiel: Sie entdecken, dass die Software eines Unternehmens einen Fehler hat, der einen Dritten betrifft, etwa eine Integration mit einer anderen Software oder einer anderen Website.

  • Ist es in Ordnung, alle gefundenen Informationen beiden Parteien zu melden?

  • Sind zwei verschiedene verantwortungsvolle Offenlegungen nötig, etwa eine Meldung an das eine Unternehmen und eine andere an das Drittunternehmen, mit dem Ziel, die an jedes Unternehmen gesendeten Informationen zu begrenzen?

  • Ist es in Ordnung, wenn die entdeckende Person die Unternehmen miteinander in Kontakt bringt?

Störende Software

Beispiel: Sie sind versiert genug, einen Virus zu schreiben, von dem Sie glauben, dass er Nutzern wahrscheinlich hilft, sich vor dem Sicherheitsrisiko zu schützen, zu erkennen, ob sie gefährdet sind, oder das Sicherheitsrisiko zu beheben.

  • Ist das in Ordnung?

  • Ist es in Ordnung, wenn die entdeckende Person Nutzer auf solche Software und/oder auf Anleitungen oder Tutorials verweist, die beschreiben, wie man diese Art von Software erstellt?

Koordinierte Offenlegung von Schwachstellen vs. verantwortungsvolle Offenlegung

Koordinierte Offenlegung von Schwachstellen ist der bevorzugte Begriff.

  • Der wichtigste Aspekt ist die Koordination zwischen entdeckender Person und Hersteller.

Verantwortungsvolle Offenlegung ist ein veralteter Begriff.

  • Menschen haben unterschiedliche Vorstellungen davon, was verantwortungsvoll bedeutet. Zum Beispiel vertreten manche, es sei verantwortungsvoll, wenn die entdeckende Person die Öffentlichkeit sofort informiert, unabhängig von jeder Interaktion mit dem Hersteller, und unverantwortlich, koordinierte Offenlegung von Schwachstellen zu betreiben, weil dies der Öffentlichkeit Informationen vorenthält.

Nachverfolgung