Tabletop Tuesday

Bounty Hunter

Unbekannter Forscher fordert Bug Bounty – Erpressung oder Chance?

Herzlich willkommen zu unserer neuen Serie "Tabletop Tuesday"!

Heute widmen wir uns einem Szenario, das immer wieder Unternehmen betrifft: Ein externer Sicherheitsforscher meldet sich und behauptet, eine kritische Schwachstelle in einem Ihrer öffentlich zugänglichen Systeme gefunden zu haben. Für die Details fordert er eine Belohnung – ein sogenanntes Bug Bounty. Doch was, wenn Sie gar kein offizielles Bug-Bounty-Programm haben?

Dieser Fall wirft viele Fragen auf: Wie reagieren Sie professionell? Ist die Forderung legitim? Wie gehen Sie mit dem Forscher um, ohne ihn zu verprellen oder sich erpressbar zu machen? Finden wir es heraus!

Was ist eine Tabletop-Übung?

Eine Tabletop-Übung ist ein diskussionsbasiertes Training, bei der Teammitglieder die Rollen und Verantwortlichkeiten durchgehen, die sie während eines bestimmten Notfallszenarios hätten. Es geht nicht darum, Systeme live zu testen, sondern darum, Prozesse, Pläne und Kommunikationswege auf den Prüfstand zu stellen.

Phase 1: Die Kontaktaufnahme

Szenariobeschreibung (Teil 1):

An einem Montagmorgen landet eine E-Mail im allgemeinen info@-Postfach Ihres Unternehmens. Absender ist eine Person, die sich als unabhängiger Sicherheitsforscher ausgibt. In der E-Mail behauptet der Forscher, eine kritische Sicherheitslücke (angeblich Remote Code Execution – RCE) in einem Ihrer wichtigsten, öffentlich erreichbaren Webportale (z.B. Kundenportal, Online-Shop) entdeckt zu haben. Er gibt nur vage Hinweise, deutet aber an, dass die Ausnutzung gravierende Folgen hätte. Für die Offenlegung der genauen Details und des Proof-of-Concept (PoC) fordert er eine "Bug Bounty" Zahlung von $2000. Er setzt eine Frist von 48 Stunden für eine positive Rückmeldung, bevor er "andere Optionen in Betracht zieht".

Diskussionspunkte und Kernfragen für Ihr Team:

Erste Reaktion und Informationsfluss:

Wer im Unternehmen ist für die Entgegennahme und Erstbewertung solcher Meldungen zuständig? (IT-Sicherheit, ISB, CISO, Rechtsabteilung?)
Wie wird diese E-Mail intern weitergeleitet und wer muss sofort informiert werden?
Gibt es eine definierte "Responsible Disclosure Policy" oder "Vulnerability Disclosure Policy" (VDP) im Unternehmen? Wenn ja, was besagt sie?
Wo können Sicherheitslücken offiziell gemeldet werden? (z.B. security@, Kontaktformular, spezielle Seite). Ist diese Information leicht auffindbar? Wer bearbeitet diese Meldungen standardmäßig?
Bewertung der Glaubwürdigkeit und des Risikos:
- Wie schätzen Sie die Glaubwürdigkeit des Forschers und seiner Behauptung ein, ohne Details zu kennen? Gibt es Indizien (z.B. professionelle Aufmachung der Mail, Verweis auf frühere Funde – falls recherchierbar)?
- Welchen potenziellen Schaden könnte eine RCE-Schwachstelle im genannten System verursachen? (Datenabfluss, Systemübernahme, Reputationsschaden).

Umgang mit der Forderung:

Wie gehen Sie mit der Geldforderung und der gesetzten Frist um?
Ist die Formulierung des Forschers als Drohung oder als legitime (wenn auch ungeschickte) Anfrage zu werten?

Mögliche Sofortmaßnahmen (Entscheidungen, die im Rahmen der TTX getroffen werden müssen):

Einberufung des Incident Response Teams (IRT) oder eines dedizierten Schwachstellen-Management-Teams: Klare Zuständigkeiten festlegen.
Sicherung der Kommunikation: Alle Korrespondenz mit dem Forscher zentral dokumentieren.
Erste Recherche: Gibt es Informationen über den Forscher online? (Ohne ihn direkt zu kontaktieren und zu alarmieren).
Interne Prüfung: Schnelle, oberflächliche Prüfung des genannten Systems auf offensichtliche, kürzlich bekannt gewordene Schwachstellen, die zu einer RCE führen könnten (ohne die genauen Informationen des Forschers).
Vorbereitung einer ersten, neutralen Antwort an den Forscher: Empfangsbestätigung, Hinweis auf interne Prüfung, Bitte um etwas mehr Zeit (ohne auf die Geldforderung direkt einzugehen).

Phase 2: Interne Klärung – Policy & Prozesse

Szenariobeschreibung (Teil 2): Das zuständige Team hat die Meldung erhalten und eine erste, neutrale Empfangsbestätigung an den Forscher gesendet. Nun gilt es, intern die Fakten zu klären und eine Strategie zu entwickeln. Der Forscher hat noch keine weiteren Details geliefert und wartet auf eine Zusage bezüglich der $2000.

Diskussionspunkte und Kernfragen für Ihr Team:

Bug Bounty Policy und Praxis:

Existiert eine offizielle oder inoffizielle Bug Bounty Policy im Unternehmen?
Zahlt das Unternehmen überhaupt Bug Bounties? Wenn ja, unter welchen Bedingungen und in welcher Höhe? Wer entscheidet darüber?
Wenn nein, warum nicht? Wurde dies bewusst entschieden?
Gibt es Alternativen zur Zahlung von Geld? (z.B. Aufnahme in eine "Hall of Fame" auf der Webseite, ein offizielles Dankesschreiben vom CISO oder der Geschäftsführung, Sachpreise, Spenden an eine gemeinnützige Organisation im Namen des Finders).

Vorgehensweise bei Schwachstellenmeldungen:

Wie ist der standardisierte Prozess für die Bearbeitung von extern gemeldeten Schwachstellen?
Wer ist für die technische Validierung der Schwachstelle verantwortlich, sobald Details vorliegen?
Welche Rolle spielt die Rechtsabteilung in diesem Prozess, insbesondere bei Geldforderungen?

Kommunikationsstrategie mit dem Forscher:

Wie reagieren Sie auf die Geldforderung, wenn Sie (noch) keine Details zur Schwachstelle haben?
Wie können Sie den Forscher dazu bewegen, die Details preiszugeben, ohne eine Vorabzusage zur Zahlung zu machen? (Vertrauensaufbau, Verweis auf interne Prozesse).
Was passiert, wenn der Forscher auf der Vorauszahlung besteht?

Risikoabwägung:

Was ist das Risiko, wenn Sie nicht zahlen und der Forscher die Schwachstelle öffentlich macht oder verkauft?
Was ist das Risiko, wenn Sie zahlen, die Schwachstelle aber trivial oder nicht existent ist?

Mögliche Maßnahmen (Entscheidungen, die im Rahmen der TTX getroffen werden müssen):

Klärung der internen Haltung zu Bug Bounties: Basierend auf existierenden Policies oder einer Ad-hoc-Entscheidung der Geschäftsführung/IT-Leitung.
Festlegung der Verhandlungsposition gegenüber dem Forscher:
- Option A: Zahlung kategorisch ablehnen, aber Kooperation anbieten.
- Option B: Bereitschaft zur Zahlung signalisieren, nachdem die Schwachstelle validiert und ihre Kritikalität bestätigt wurde.
- Option C: Alternative Anerkennungen anbieten.
Ausarbeitung einer detaillierteren Antwort an den Forscher: Erläuterung des internen Prozesses, Bitte um Offenlegung der Details zur Validierung, ggf. Hinweis auf die Haltung zu Bounties.
Vorbereitung der technischen Validierung: Ressourcen (Personal, Testsysteme) bereitstellen für den Fall, dass der Forscher Details liefert.

Phase 3: Die Verhandlung

Szenariobeschreibung (Teil 3): Sie haben dem Forscher geantwortet, ihm für die Meldung gedankt, Ihren internen Prozess zur Validierung von Schwachstellen erläutert und um Details gebeten, um die angebliche RCE-Schwachstelle prüfen zu können. Bezüglich der $2000 haben Sie (je nach interner Entscheidung aus Phase 2) entweder alternative Anerkennungen in Aussicht gestellt oder eine Prüfung der Bounty-Zahlung nach erfolgreicher Validierung und Kritikalitätseinstufung signalisiert. Der Forscher antwortet und ist bereit, erste technische Hinweise (aber noch keinen vollen PoC) zu geben, fragt aber erneut nach der Zusicherung der $2000, falls sich seine Behauptung als wahr erweist.

Diskussionspunkte und Kernfragen für Ihr Team:

Bewertung der neuen Informationen:

Reichen die neuen Hinweise des Forschers aus, um eine erste interne technische Einschätzung vorzunehmen oder die Schwachstelle selbst zu finden?
Wie glaubwürdig erscheinen die technischen Andeutungen?

Umgang mit der fortbestehenden Geldforderung:

Bleiben Sie bei Ihrer bisherigen Linie oder bewegen Sie sich auf den Forscher zu?
Können Sie eine gestaffelte Offenlegung vereinbaren (mehr Details gegen eine klarere Zusage, aber immer unter dem Vorbehalt der Validierung)?
Wie stellen Sie sicher, dass der Forscher nicht nach Offenlegung der Details einfach die Bedingungen ändert oder mehr fordert? (Schriftliche Fixierung der Vereinbarung).

Eskalation und Entscheidungsfindung:

Wer trifft die endgültige Entscheidung über die Zahlung oder Nicht-Zahlung (unter welchen Bedingungen)? (CISO, Geschäftsführung, Rechtsabteilung).
Welche Kriterien werden für diese Entscheidung herangezogen (Kritikalität der (vermuteten) Lücke, Kosten der Behebung, potenzielle Schadenskosten, Reputationsrisiko, Budget für Bounties)?

Vorbereitung auf verschiedene Ausgänge:

Plan A: Forscher liefert Details, Lücke ist valide und kritisch, Sie zahlen (oder bieten Alternative an).
Plan B: Forscher liefert Details, Lücke ist nicht kritisch oder nicht existent.
Plan C: Forscher bricht Kommunikation ab, droht mit Veröffentlichung.

Mögliche Maßnahmen (Entscheidungen, die im Rahmen der TTX getroffen werden müssen):

Technische Analyse der neuen Hinweise: Versuch, die Schwachstelle intern zu reproduzieren oder zumindest ihre Plausibilität zu bewerten.
Finale Entscheidung über das Vorgehen bezüglich der Bounty-Forderung: Klare Zusage unter Bedingungen, Angebot von Alternativen oder Ablehnung.
Formulierung einer klaren Antwort an den Forscher, die die Entscheidung und die nächsten Schritte kommuniziert.
Falls der Forscher kooperiert und Details liefert: Start der detaillierten technischen Validierung. Sicherstellung, dass dies in einer isolierten Testumgebung geschieht.
Parallel: Intensiviertes Monitoring des betroffenen Systems auf verdächtige Aktivitäten.

Phase 4: Validierung, Behebung und Lessons Learned

Szenariobeschreibung (Teil 4):

Fall A: Der Forscher hat, nach Ihrer Zusage einer fairen Prüfung (und ggf. einer Bounty bei Bestätigung), die vollständigen Details und einen PoC geliefert. Ihre Techniker konnten die RCE-Schwachstelle validieren. Sie ist tatsächlich kritisch.
Fall B: Der Forscher hat Details geliefert, aber die Schwachstelle stellt sich als weniger kritisch heraus als behauptet, oder es handelt sich um ein bekanntes Problem, das bereits in Bearbeitung ist, oder es ist gar keine echte Schwachstelle.
Fall C: Der Forscher hat die Kommunikation abgebrochen, nachdem keine Vorabzusage zur Zahlung erfolgte.

Diskussionspunkte und Kernfragen für Ihr Team:

Fall A (Valide, kritische Lücke):

Behebung: Wie schnell kann die Schwachstelle behoben werden? Wer ist dafür verantwortlich? (Notfall-Patch, Workaround).
Belohnung: Wie wird die vereinbarte Bounty ausgezahlt? Oder welche alternativen Anerkennungen werden umgesetzt? Wie wird dies kommuniziert?
Kommunikation: Danken Sie dem Forscher öffentlich (falls gewünscht und vereinbart)?
Müssen Kunden oder Behörden informiert werden (abhängig davon, ob die Lücke ausgenutzt wurde)?

Fall B (Weniger kritisch / nicht existent):

Kommunikation: Wie kommunizieren Sie dies professionell und transparent an den Forscher, ohne ihn zu demotivieren?
Anerkennung: Bieten Sie trotzdem eine kleine Anerkennung für die Mühe an, wenn die Meldung in guter Absicht erfolgte?

Fall C (Kommunikation abgebrochen):

Risikomanagement: Wie hoch ist das Risiko, dass der Forscher die Schwachstelle nun anderweitig veröffentlicht oder verkauft?
Welche Monitoring-Maßnahmen intensivieren Sie?
Proaktive Suche: Versuchen Sie, die (vermutete) Schwachstelle basierend auf den vagen Hinweisen selbst zu finden und zu schließen?

Allgemeine Lessons Learned (für alle Fälle):

War der interne Prozess zur Handhabung solcher Meldungen effektiv? Was muss verbessert werden?
Sollte eine offizielle Bug Bounty Policy / Vulnerability Disclosure Policy eingeführt oder überarbeitet werden? Welche Vorteile hätte das? (Klarheit für Forscher, strukturierter Prozess, besseres Image).
Wie können Sie die Zusammenarbeit mit der Security-Researcher-Community verbessern?
Sind die internen Ressourcen für die Validierung und Behebung von Schwachstellen ausreichend?
Muss das Budget für IT-Sicherheit / Bug Bounties angepasst werden?

Mögliche Maßnahmen:

Fall A: Implementierung des Fixes, Auszahlung/Gewährung der Bounty/Anerkennung, Abschlusskommunikation.
Fall B: Professionelle Kommunikation der Ergebnisse an den Forscher, ggf. kleine Anerkennung.
Fall C: Erhöhung des Monitorings, interne Taskforce zur proaktiven Suche und Behebung, Vorbereitung auf mögliche Veröffentlichung.

Durchführung eines "Lessons Learned"-Workshops.

Überarbeitung/Erstellung einer Vulnerability Disclosure Policy und ggf. eines Bug Bounty Programms.
Schulung der relevanten Mitarbeiter im Umgang mit externen Schwachstellenmeldungen.

Fazit

Die Meldung einer Schwachstelle durch externe Sicherheitsforscher, verbunden mit einer Geldforderung, ist eine heikle Situation. Ein klar definierter Prozess, eine transparente Kommunikation und eine grundsätzliche Entscheidung, wie Ihr Unternehmen mit Bug Bounties umgeht, sind entscheidend. Ob Sie zahlen oder nicht – Professionalität und Wertschätzung für die (potenzielle) Hilfe von außen sollten immer im Vordergrund stehen. Es ist eine Gratwanderung, aber auch eine Chance, die eigene Sicherheit zu verbessern.

Nutzen Sie dieses Szenario, um Ihre internen Richtlinien und Reaktionsmechanismen zu überprüfen und zu optimieren! Was sind Ihre Erfahrungen mit solchen Anfragen?

Wir unterstützen Sie gerne dabei. Ob Awareness-Schulungen, Incident-Response-Pläne oder technische Schutzmaßnahmen – mit unseren Services helfen wir Ihnen, Sicherheitsvorfälle nicht nur besser zu bewältigen, sondern im besten Fall ganz zu vermeiden.