Seite 2 - Schwachstellen aufdecken mit Bug-Bounty-Programmen

Lesezeit
2 Minuten
Bis jetzt gelesen

Seite 2 - Schwachstellen aufdecken mit Bug-Bounty-Programmen

30.01.2019 - 14:00
Veröffentlicht in:
Umfang von Bug-Bounty-Programmen
Der Umfang definiert die Grenzen des Tests, das heißt welche Websites und mobilen Apps sollen die Hacker testen? Die wichtigsten Überlegungen sind dabei, welche Zugriffswege und -rechte Hacker erhalten und wie die Autorisierung erfolgt. Und natürlich, wer die gemeldeten Schwachstellen beheben soll, wenn etwas gefunden wurde.

Der Zugang ist wichtig, da einige Komponenten und Netzwerke eventuell nicht im Internet sind oder geografische oder physische Einschränkungen haben können, die die Teilnahme begrenzen. Es kann zudem bestimmte Schwachstellentypen geben, die nicht getestet werden sollen, beispielsweise Denial-of-Service-Tests oder Cross-Site-Request-Forgery beim Logout. Es ist wichtig, diese Fälle aufzulisten, damit Hacker ihre Zeit nicht damit verschwenden, was für alle Beteiligten nur frustrierend wäre.

Planung des Bounty Budget
Ein großer Unterschied zwischen einer traditionellen Sicherheitsbewertung und einem Bug-Bounty-Programm besteht darin, dass dieses nur pro Erfolgsfall Prämien ausschüttet. Es ist wie bei einem Pay-as-you-go-Telefonvertrag – je mehr Schwachstellen Hacker finden, desto höher sind die Kosten. Dies ist kosteneffizient, stellt aber eine Herausforderung bei der Einschätzung der Ausgaben dar, vor allem innerhalb eines festen Budgets.

Ein Bug-Bounty-Programm bestimmt die Höhe der Prämien normalerweise nach dem Schweregrad eines Fundes und definiert diese in einer Bounty-Tabelle auf der Programmseite. So erhält beispielsweise eine kritische Schwachstelle eine höhere Prämie als eine mit niedrigerem Schweregrad. Verschiedene untersuchte Bereiche können auch unterschiedliche Bounty-Tabellen haben, die auf organisatorischen Prioritäten basieren.

Prozess bei der Schwachstellenbehandlung
Der Prozess der Schwachstellenbehandlung ist das, was zwischen dem anfänglichen Melden einer Schwachstelle und der Behebung dieser Schwachstelle passiert. Zu den typischen Aktivitäten gehören das Reagieren, Ausprobieren, Korrigieren und Patchen. Es gibt Normen wie ISO 30111, die diese Aktivitäten detaillierter beschreiben. Für Unternehmen kann es dabei lohnenswert sein, eine Verantwortungszuordnungsmatrix (RACI) und ein Flussdiagramm mit den internen Beteiligten zu erstellen, um sicherzustellen, dass jeder vorbereitet ist, wenn Schwachstellen gemeldet werden. Dabei kommen folgende Metriken zum Einsatz, um die Effizienz eines Prozesses zur Behandlung von Schwachstellen zu messen:
  1. Zeit bis zur Triage / Antwort auf einen neuen Bericht
  2. Zeit bis zum Bounty (nach VA)
  3. Zeit bis zur Behebung der Schwachstelle
Bug-Bounty-Programme, die möglichst effektiv arbeiten wollen, veröffentlichen tatsächlich vorab, wieviel Zeit zum Reagieren, Bezahlen und Beheben das entsprechende Unternehmen benötigen wird. Es macht so auch die Voraussetzungen und Erwartungen an die Hacker klarer und versucht , die besten Talente für die Teilnahme am Programm zu gewinnen.

Die meisten Unternehmen entscheiden sich dafür, die Sicherheitsbefunde privat zu halten. Einige machen nur einen Teilbericht oder sogar einen vollständigen Bericht öffentlich zugänglich; allerdings erst, nachdem sie die Schwachstelle behoben haben. So demonstrieren sie ihre Sicherheitsaktivitäten und helfen der Community, dazuzulernen.

Fazit
Bug-Bounty-Programme sorgen für mehr Kapazitäten und Know-how und helfen so, Schwachstellen und Sicherheitsprobleme kontinuierlich und vor der Entdeckung durch Cyberkriminelle aufzudecken. Kurz gesagt helfen sie Sicherheitsteams, weniger Zeit mit der Fehlersuche und mehr Zeit mit der Behebung zu verbringen. Die einzige Einschränkung beim Ausführen eines Bug-Bounty-Programms ist die Geschwindigkeit, mit der die gefundenen Schwachstellen behoben werden können. IT-Sicherheitsteams sollten nicht nur die Zeit bis zur Behebung sorgfältig im Blick behalten, sondern auch alle nützlichen Erkenntnisse, die sie aus der Bug Bounty gewinnen, in ihre anderen Sicherheitslösungen einfließen lassen, zum Beispiel indem sie statische und dynamische Analyseregeln schreiben, um ähnliche Schwachstellen in verschiedenen Codebasen zu finden. HackerOne hat dazu eine Reihe von Leitfäden und Best-Practice-Dokumenten [1] erstellt.


<< Vorherige Seite Seite 2 von 2


ln/Laurie Mercer, Security Engineer bei HackerOne

[1] www.hackerone.com/resources#guides

Tags

Ähnliche Beiträge

Zero Trust richtig umsetzen

Zero Trust ist mittlerweile state of the art in Sachen Sicherheit. Was dabei häufig unter den Tisch fällt: Ganzheitliche Sichtbarkeit – und zwar bis auf Netzwerkebene – ist die Grundvoraussetzung für das Konzept. Ausgerechnet hier scheitern bereits viele Unternehmen. Die Folge: Blind Spots nehmen ihnen die Sicht. Erfahren Sie im Fachbeitrag, warum Deep Observability bei einer Zero-Trust-Strategie nicht fehlen darf.

Im Test: sayTEC sayTRUST VPSC

Mit VPNs stellen Administratoren den Zugriff für mobile User zur Verfügung. Jedoch ist es nicht immer gewollt, dass die Endgeräte auch zum Teil des Netzwerks werden. Zudem bringen klassische VPNs nach wie vor eine Reihe von Unzulänglichkeiten mit sich, etwa in der Verwaltung oder bei der Performance. Mit sayTECs sayTRUST VPSC steht ein anderer Weg des geschützten Zugangs offen, der im Test überzeugte.

Richtig auf NIS-2 vorbereiten

Bis zum 17. Oktober 2024 müssen zahlreiche Unternehmen ihre Informations- und Cybersicherheitsstrategien anpassen. Dazu gehören regelmäßige Penetrationstests und Meldesysteme für Cybervorfälle. Außerdem sind umfassende Risikobewertungen erforderlich. Die NIS-2-Richtlinie stellt Unternehmen vor Herausforderungen, bietet aber auch Chancen. Sie kann Organisationen sicherer und widerstandsfähiger machen.