Dein VDP wird erstellt

Programmrichtlinien sind für jedes VDP unerlässlich und müssen sorgfältig ausgearbeitet werden. Die Programmrichtlinien sind das Erste, was Sicherheitsexperten bei der Teilnahme an einem VDP sehen. Sie gibt den Ton für das Programm sowie Erwartungen und Ihr Engagement für die Forschenden an, die sich für eine Teilnahme entscheiden.

Programmrichtlinien erstellen und hosten

Erstelle die Programmrichtlinien für dein VDP anhand der folgenden Richtlinien. Programmrichtlinien sind in der Regel nur ein bis drei Seiten lang und enthalten in der Regel die folgenden Themen:

• Ein Forscher-Versprechen
• Testrichtlinien
• Umfang des Programms

Die Programmrichtlinien müssen allen potenziellen Forschenden zugänglich gemacht werden. Wenn du vorhast, das VDP privat zu starten, und zwar nur für einige wenige eingeladene Forscher, dann benötigt die Programmrichtlinie eine Art Zugriffssteuerung, um es den von dir eingeladenen Forschern zur Verfügung zu stellen, die aber auf alle anderen beschränkt ist. Forschende benötigen auch eine Möglichkeit, Berichte zu senden, z. B. über ein Webformular oder einen E-Mail-Alias, der mit einem Ticketsystem verknüpft ist, um die Berichte nachzuverfolgen. Das solltest du beim Einrichten der Online-Ressourcen des VDP berücksichtigen.

Drittanbieterplattformen zur Offenlegung von Sicherheitslücken und Bug-Bounty-Plattformen bieten im Allgemeinen folgende Funktionen:

• Möglichkeit zum Erstellen, Bearbeiten und Veröffentlichen einer Richtlinie
• Zugriffssteuerungen zum Erstellen eines privaten Programms
• Du kannst Hacker in einem für dich angenehmen Tempo automatisch einladen
• Posteingangsfunktion zur Erleichterung der Verarbeitung eingehender Berichte

Drittanbieterplattformen bieten auch eine Vielzahl von Beratungsdiensten an, um die Erstellung und Einführung eines VDP zu erleichtern. In der Regel haben Plattformen und Beratungsdienste von Drittanbietern Kosten. Berücksichtigen Sie die Kosten und Vorteile der Nutzung eines Drittanbieters im Vergleich zur Entwicklung und Verwaltung Ihres Programms intern, um den besten Weg für Ihr Unternehmen zu ermitteln.

Weitere Anregungen dazu, was Sie in Ihre Programmrichtlinien aufnehmen sollten, finden Sie im Artikel A Framework for a Vulnerability Disclosure Program for Online Systems des Justizministeriums der Vereinigten Staaten.

Stakeholder für Programmrichtlinien

Überlegen Sie beim Entwurf Ihrer Programmrichtlinien, wie Sie mit Ihren Stakeholdern zusammenarbeiten können. Verschiedene Teams können zu Überlegungen beitragen, die in Ihre Richtlinie integriert werden sollen.

Stakeholder	Wissenswertes
Legal	Erarbeiten Sie zusammen mit Ihrer Rechtsabteilung Ihre Programmrichtlinien und Bedingungen, unter denen Hacker teilnehmen können. Forscher werden nicht bezahlt, daher gibt es keinen guten Grund, sich umfassenden Onboarding-Anforderungen oder umständlichen Bedingungen zu unterwerfen.
IT	Arbeiten Sie mit Ihrem IT-Team zusammen, um Testanforderungen und -umfang zu entwickeln und z. B. keine Denial-of-Service-Bedingungen zu erstellen.
Entwicklung	Das Engineering-Team kann Input zu Testanforderungen und zum Umfang haben, einschließlich der Arten von Sicherheitslücken, die am interessantesten oder am wenigsten interessant sind.
PR	Arbeiten Sie mit Ihrem PR-Team zusammen, um die Richtlinienformulierungen für die Offenlegung zu prüfen.
Sicherheit	Das Sicherheitsteam leitet in der Regel die Erstellung der Richtlinie. Das Sicherheitsteam wird wahrscheinlich Feedback von Hackern erhalten und die Richtlinie im Laufe der Zeit mit anderen Stakeholdern iterieren.

Versprechen der Forscher

Das Forscherversprechen erklärt die Verpflichtungen der Organisation gegenüber den teilnehmenden Forschern, die nach Treu und Glauben handeln. Dazu befolgen sie die in der Richtlinie beschriebenen Testrichtlinien. Zum Beispiel die Verpflichtung, alle eingehenden Sicherheitsberichte innerhalb eines bestimmten Zeitraums zu beantworten und Entscheidungen darüber zu informieren, welche Meldungen zu Sicherheitslücken akzeptiert und behoben werden.

Beispiel:

<Name Ihrer Organisation> arbeitet mit Sicherheitsexperten zusammen, um Sicherheitslücken in unseren Systemen und Diensten zu identifizieren und zu schließen. Sofern Sie nach Treu und Glauben handeln und die in dieser Richtlinie beschriebenen Richtlinien einhalten, werden wir uns nach besten Kräften bemühen:

• Sie erhalten innerhalb von drei Werktagen eine erste Antwort auf Ihren Bericht zu Sicherheitslücken.
• Bestimmen Sie, ob wir Ihren Bericht zu Sicherheitslücken innerhalb von zehn Arbeitstagen akzeptieren (beseitigen möchten) oder ablehnen (Ihren Bericht als falsch positives oder akzeptables Risiko kennzeichnen).
• Informieren Sie sich über den Fortschritt im Hinblick auf die Korrektur von Berichten, die wir von Ihnen akzeptieren.

Durch die Verwendung einer Safe-Harbor-Regelung in Ihren Programmrichtlinien können Sie den Forschern versichern, dass keine rechtlichen Schritte gegen sie für Tests mit Ihren Systemen eingeleitet werden, solange sie nach Treu und Glauben handeln und allen in der Richtlinie erläuterten Richtlinien entsprechen.

Hinweis: disclose.io stellt Vorlagen mit Safe-Harbor-Sprache bereit, die Sie beim Erstellen Ihrer Richtlinie verwenden können. Arbeiten Sie mit Ihrer Rechtsabteilung zusammen, um diese Formulierung zu beurteilen und an Ihre Anforderungen anzupassen.

Testrichtlinien

In den Testrichtlinien werden die Sicherheitstests beschrieben, die im Bereich des VDP liegen, sowie Tests, die nicht im Umfang enthalten sind und von Forschern vermieden werden sollten. Wenn es bestimmte Arten von Sicherheitslücken gibt, auf die sich die Forscher konzentrieren sollen, ist dieser Abschnitt gut geeignet, um darauf hinzuweisen.

Beispiel:
Halten Sie sich bei Sicherheitstests an die folgenden Richtlinien:

• Führen Sie nur Tests mit Ihren eigenen Konten und Daten durch (z.B. Testkonten). Wenn Sie eine Sicherheitslücke entdecken, die den Zugriff auf die Daten anderer Nutzer ermöglicht, sollten Sie sich zuerst mit uns in Verbindung setzen, bevor Sie weitere Tests durchführen.
• Solltest du bei deinen Tests versehentlich auf die Daten anderer Nutzer zugreifen, teile uns dies bitte mit. Bitte speichere diese Daten aber nicht.
• Führen Sie keine Tests durch, die zu Denial-of-Service-Bedingungen oder einer Beeinträchtigung unserer Produktionsdienste führen.
• Social Engineering ist im Rahmen dieses Programms nicht enthalten. Versuchen Sie nicht, unsere Organisation oder unsere Nutzer mit Social Engineering zu betreiben.

Uns interessieren insbesondere die folgenden Arten von Sicherheitslücken und Auswirkungen:

• Remote-Ausführung von Code
• XSS, das den Zugriff auf sensible Daten ermöglicht (z.B. Sitzungsinformationen)
• SQL-Injection, die Zugriff auf sensible Daten oder Funktionen ermöglicht
• Fehler in der Geschäftslogik, die zum Zugriff auf sensible Daten oder Funktionalität führen können

Uns sind weniger die folgenden Arten von Sicherheitslücken wichtig, da diese mit höherer Wahrscheinlichkeit
als falsch-positive Ergebnisse oder akzeptierte Risiken abgelehnt werden:

• Fehlender X-Frame-Options-Header auf Seiten ohne Funktionen, die den Status ändern
• Nicht bestätigte Ergebnisse der automatisierten Scanner
• Probleme, die wahrscheinlich nicht ausgenutzt werden können und/oder keine realistischen Auswirkungen auf die Sicherheit haben

Umfang

Der Umfang definiert, welche Assets getestet werden können und welche Assets nicht als Teil des VDP gelten. Der Umfang muss sorgfältig abgewogen und so umfangreich wie möglich sein, ohne Ihr Team zu überlasten. Je mehr Sie bereit sind, den Umfang anzugeben, desto wahrscheinlicher ist es, dass sich die Sicherheitsexperten einbeziehen. Erweitern Sie den Umfang jedoch nicht so groß, dass Ihr Team nicht mit den eingehenden Berichten Schritt halten kann. Beginnen Sie mit wenigen Assets im Umfang. Erweitern Sie den Umfang, wenn Sie eine bessere Vorstellung davon erhalten, welches Berichtsvolumen Sie erhalten werden. Bevor du dein VDP im Laufe der Zeit öffentlich zugänglich machst, solltest du alle erforderlichen Spezifikationen berücksichtigen.

Wenn Sie Details zu jedem Asset oder Bereich hinzufügen, können Sicherheitsexperten bei der Definition Ihres Umfangs in Ihren Programmrichtlinien erkennen, was für Sie wichtig ist und worauf sie sich konzentrieren müssen. Du kannst auch Tipps für sichere Tests mit deinen Assets hinzufügen. Beispiel:

Asset	mail.example.com
Beschreibung	Primäre Domain, über die Nutzer auf ihre E-Mails zugreifen können
Interessante Sicherheitslücken und Auswirkungen	Sicherheitslücken, die zu nicht autorisiertem Zugriff auf die E-Mails anderer Nutzer führen. Die Möglichkeit, die E-Mails eines anderen Nutzers oder das gesamte Konto unwiderruflich zu löschen
Probleme, die wahrscheinlich abgelehnt werden	SPF Phishing oder Probleme, die Phishing ermöglichen Möglichkeit, potenziell schädliche Anhänge zu senden
Richtlinien zum Testen	Führen Sie Tests nur mit Konten durch, deren Inhaber Sie sind oder für die Sie Ihre ausdrückliche Einwilligung haben. Geben Sie bei der Erstellung von Testkonten bitte "vdptest" im Nutzernamen an. Testkonten können unter mail.beispiel.de/neu erstellt werden.

Dies ist eine ziemlich detaillierte Aufschlüsselung. Alternativ können Sie eine einfache Liste von Assets hinzufügen, die zum Zuständigkeitsbereich gehören und nicht enthalten sind:

Im Zuständigkeitsbereich

• mail.example.com
• example.com

Nicht zuständig

• blog.example.com

Ressourcen für dein VDP

Vor dem Start eines VDP brauchst du bestimmte Ressourcen. Sie benötigen Ressourcen für:

• Eingehende Berichte zu Sicherheitslücken prüfen
• Kommunikation mit Hackern
• Asset-Eigentümer finden und Fehler melden
• Fehlerbehebung
• Verwaltung von Sicherheitslücken / Nachbereitung der Behebung

Rückblick auf die wichtigsten Stakeholder

Falls noch nicht geschehen, solltest du die Gespräche mit den wichtigsten Stakeholdern, mit denen du dein VDP zuvor besprochen hast, noch einmal durchgehen, um sicherzustellen, dass sie den Zeitplan für den Start deines VDP einhalten und alle notwendigen Ressourcen für den Start in die Warteschlange stellen. Sie können beispielsweise mit der technischen Leitung zusammenarbeiten, um sicherzustellen, dass ihre Teams auf einen potenziellen Zustrom von Sicherheitslücken vorbereitet sind, an denen sie in den ersten Wochen nach der Markteinführung arbeiten können. Achte in deinem Sicherheitsteam darauf, dass die Personen, die die Benachrichtigungen in deinen Erkennungs- und Reaktionssystemen sortieren, das Einführungsdatum des VDP kennen und erwägen Sie, mehr Zeit und Ressourcen für Testbeginn einzuplanen. Außerdem musst du ein Team zusammenstellen, das dich bei den täglichen Abläufen deines VDP unterstützt.

Dein Team erweitern

Die Durchführung eines VDP erfordert ein angemessenes Maß an operativer, unterbrechungsfreier Arbeit. Wenn Sie versuchen, jeden auftretenden Sicherheitslückenbericht zu überprüfen, technisch zu validieren und darauf zu reagieren, jeden Fehler zu melden, den Status zu verfolgen und Updates an Forscher alleine zu kommunizieren, kann das zu einem Burn-out führen. Auch wenn Sie kein großes Sicherheitsteam haben, sollten Sie sicherheitsorientierte Freiwillige finden, die Sie bei der Operationalisierung und Durchführung Ihres VDP unterstützen. Sie brauchen trotzdem einen „Inhaber“ oder „Leiter“ Ihres VDP, der letztendlich für den Erfolg Ihres VDP verantwortlich ist, aber Sie benötigen auch ein Team, das diesen Leiter unterstützt.

Einsatzplan erstellen

Sobald du alle nötigen Ressourcen hast und bereit bist, dich bei deinem VDP zu unterstützen, solltest du einen Einsatzplan erstellen. Sie können dies nach Belieben erstellen, aber eine wöchentliche Rotation ist ziemlich gängige Praxis. Wenn Sie in dieser Woche Einsatz haben, sind Sie für Folgendes verantwortlich:

• Triage – Prüfen Sie eingehende Berichte zu Sicherheitslücken.
  • Den Bericht technisch validieren und die Entscheidung „Akzeptieren“ oder „Ablehnen“ treffen
  • Teile deine Entscheidung dem Hacker mit, der das Problem gemeldet hat.
  • Fragen Sie gegebenenfalls den Hacker um weitere Informationen, wenn Sie das Problem nicht reproduzieren können.
  • Wenn die Sicherheitslücke gültig ist, melden Sie dem richtigen Inhaber einen behobenen Programmfehler.
• Vulnerability Management (Sicherheitslückenmanagement): Beseitigen Sie vorhandene Sicherheitslücken.
  • Prüfen Sie Fehler, die in den vergangenen Wochen gemeldet wurden, um sicherzustellen, dass die Behebung gemäß Ihren Schweregradstandards und Behebungsfristen abgeschlossen wird.
  • Nutzen Sie die Tipps unter Inhaber finden, um Inhaber davon zu überzeugen, diese Fehler zu beheben.
• Kommunikation: Sicherheitsexperten über vorhandene Berichte auf dem Laufenden halten
  • Forschende können proaktiv um Updates zu vorhandenen Berichten bitten. Prüfen Sie dies und antworten Sie bei Bedarf.
  • Wenn eine Sicherheitslücke behoben wurde, informieren Sie die Forschenden darüber, damit sie wissen, dass ihre harte Arbeit zu positiven Veränderungen in Ihrem Unternehmen geführt hat. Sie können sogar Vorlagensprache verwenden, in der die Forschenden gebeten werden, Sie zu informieren, wenn Sie etwas in Ihrer Fehlerbehebung übersehen haben oder ob Ihre Korrektur auf irgendeine Weise umgangen werden könnte.

Je nach Anzahl der Meldungen, der Komplexität dieser Berichte sowie der Fähigkeiten und dem Wissen des jeweiligen Mitarbeiters kann der Einsatz von einigen Stunden bis hin zu einer ganzen Woche dauern. Tipps für eine erfolgreiche Rotation im Einsatz sind unter anderem:

• Sorgen Sie dafür, dass Ihr Team bereit ist, in besonders schweren Wochen den Einsatz zu unterstützen.
• Sorgen Sie für einen guten Übergabeprozess. Wenn es Probleme gibt, die möglicherweise sofortige Aufmerksamkeit von der nächsten im Dienst zuständigen Person erfordern, schreiben Sie einige Übergabenotizen oder führen Sie am Ende der Woche ein Live-Gespräch.
• Erstelle einen automatisierten Zeitplan, damit alle wissen, wann sie im Einsatz sind. Dazu können einfach wiederkehrende Kalendereinträge für jede Person erstellt werden.
• Besonders zu Beginn des VDP solltest du noch einmal mit der auftraggebenden Person Rücksprache halten, damit sie sich an diese Woche erinnert und abfragt, ob sie Hilfe braucht. Wenn Sie mehr Junior-Ressourcen für die Rotation haben, sollten Sie mit ihnen zusammenarbeiten, damit diese sich wohlfühlen und Fragen stellen können.
• Tausche deine Wochen mit einem flexiblen Prozess aus. Es ist unvermeidlich, dass jemand einen Notfall hat und sich in der Woche Zeit nehmen muss oder jemand Urlaub nimmt usw. In diesem Fall sollten Sie das Team ermutigen, Wochen nach Bedarf zu tauschen, damit alle Pläne eingehalten werden.
• Erstellen Sie einen Spickzettel, in dem die zu erledigenden Aufgaben aufgeführt sind und die entsprechende Dokumentation enthalten ist.

Entscheidung zwischen internen und Drittanbieterdaten

Bisher basierten die meisten Empfehlungen darauf, dass du dein VDP intern erstellst und ausführst. Es gibt verschiedene Beratungsdienste und -plattformen, die dir bei der Erstellung und Durchführung eines VDP helfen können. Diese Drittanbieter sind in der Regel kostenpflichtig, können Ihnen aber dabei helfen, Ihr VDP zu erstellen, zu starten und auszuführen. Einige bieten sogar Triage-Services an, um eingehende Berichte zu Sicherheitslücken für Sie zu prüfen, die Kommunikation mit den Hackern abzuwickeln und nur gültige Berichte an Ihr Team zu eskalieren. Die Entscheidung, ob Sie diesen Prozess intern erstellen oder eine Drittanbieterplattform verwenden, hängt von Ihren Anforderungen und verfügbaren Ressourcen ab. Wenn Sie ein großes Budget, aber nicht viele Mitarbeiter haben, ist es sinnvoll, einen Drittanbieter mit der Verwaltung Ihres Programms zu beauftragen. Wenn es andersherum ist, lohnt es sich möglicherweise, die Zeit zu investieren, um Ihr Programm selbst zu erstellen.

Berichte erhalten

Wenn Sie sich für die Nutzung einer Drittanbieterplattform entscheiden, sollten Hacker die Möglichkeit haben, Berichte direkt an Sie zu senden. Wenn Sie das Programm intern entwickeln, müssen Sie das selbst erstellen. Dabei kann es sich um eine E-Mail-Adresse handeln, mit der automatisch ein Ticket oder einen Programmfehler in Ihrem Issue Tracker erstellt wird (z. B. [e-mail]). Es kann sich aber auch um ein Webformular mit Pflichtfeldern handeln, das entweder von Ihrer Programmrichtlinie oder auf derselben Seite verlinkt ist. In beiden Fällen ist dies die beste Möglichkeit, Hacker über das Format zu informieren, in dem du deine Berichte erhalten möchtest. Beachten Sie, dass es nicht immer garantiert, dass Hacker Meldungen in einem bestimmten Format einreichen, aber es schadet nicht, sie zu fragen. Hier ist ein Beispiel dafür, was Sie in einem Formular zum Senden von Berichten anfordern können:

Title: [Bitte eine einzeilige Beschreibung des Problems einfügen, z.B. "XSS in mail.example.com
results in session Dieft"]

Zusammenfassung: [Fügen Sie eine kurze Beschreibung der Sicherheitslücke und ihrer Bedeutung hinzu. Beispiel: Aufgrund fehlender Escapezeichen können Sie eine E-Mail mit einer XSS-Nutzlast an einen anderen Nutzer senden, die es einem Angreifer ermöglichen würde, die Cookies eines anderen Nutzers mit Sitzungsinformationen zu stehlen. Dadurch könnte sich der Angreifer im Konto des Opfers anmelden.] Reproduktionsschritte: [Fügen Sie eine detaillierte Anleitung zum Reproduzieren der Sicherheitslücke hinzu.]
1.
2.
3.

Angriffsszenario und Auswirkungen: [Wie könnte das ausgenutzt werden? Welche Auswirkungen hat dieses
Problem auf die Sicherheit?] Tipps zur Fehlerbehebung: [Wenn Sie Tipps zur Behebung des Problems haben, können Sie es hier hinzufügen.]