Bug Bounty oder Red Teaming? Das ist die falsche Frage
Diese Frage kommt in der Praxis häufig vor. Sie ist berechtigt, basiert jedoch oft auf einem Missverständnis. Red Teaming und Bug Bounty erfüllen unterschiedliche Zwecke. Wer sie als Alternativen betrachtet, übersieht einen wichtigen Teil des Risikos.
Bug Bounty vs. Red Teaming: Zwei unterschiedliche Ansätze
Sowohl Red Teaming als auch Bug Bounty sind Formen von offensiven Sicherheitstests, unterscheiden sich jedoch in ihrem Ziel.
Red Teaming simuliert gezielte Angriffe über Menschen, Prozesse und Technologie hinweg. Ein kleines Team versucht, basierend auf klar definierten Zielen Zugriff auf Systeme zu erlangen, meist über mehrere Schritte hinweg. Im Fokus steht nicht nur das Auffinden von Schwachstellen, sondern auch die Frage, wie gut eine Organisation Angriffe erkennt und darauf reagiert.
Bug-Bounty-Programme hingegen basieren auf kontinuierlichem, explorativem Testen durch externe Sicherheitsforscher. Ziel ist es, möglichst viele reale Schwachstellen zu identifizieren, unabhängig davon, ob sie Teil eines vorab definierten Angriffsszenarios sind.
Kurz gesagt:
- Red Teaming fragt: Können wir einen Angriff erkennen und darauf reagieren?
- Bug Bounty fragt: Welche Schwachstellen existieren überhaupt?
Zentrale Unterschiede im Überblick
| Dimension | Red Teaming | Bug Bounty |
|---|---|---|
| Ziel | Simulation realistischer, gezielter Angriffsszenarien | Identifikation realer, ausnutzbarer Schwachstellen |
| Zeitraum | Begrenzt (z. B. Wochen) | Kontinuierlich |
| Umfang | Klar definiert, szenariobasiert | Klar definiert, explorativ innerhalb des Scopes |
| Vorgehen | Szenariogetrieben, threat-led | Explorativ, angriffsgetrieben |
| Perspektive | Kleines Expertenteam | Externe Forscher mit unterschiedlichen Spezialisierungen |
| Ergebnis | End-to-End-Angriffskette inkl. Bewertung von Detection & Response | Verifizierte Findings mit Reproduktionsschritten und Empfehlungen |
| Fokus | Erkennungs- und Reaktionsfähigkeit | Transparenz und Priorisierung von Schwachstellen |
Stärken und Grenzen
Red Teaming ist besonders stark, wenn es darum geht:
- Detection- und Response-Fähigkeiten zu testen
- Angriffspfade zu simulieren
- organisatorische Prozesse unter realem Druck zu validieren
- menschliche und organisatorische Faktoren zu prüfen (z. B. Social Engineering)
Gleichzeitig bleibt es eine Momentaufnahme. Was heute getestet wird, kann morgen bereits überholt sein, insbesondere in dynamischen IT-Umgebungen. Neue Systeme, Änderungen oder bisher unentdeckte Schwachstellen liegen oft ausserhalb des definierten Scopes.
Bug-Bounty-Programme sind besonders effektiv, wenn:
- Systeme sich kontinuierlich verändern
- mehrere Technologien im Einsatz sind
- unerwartete Schwachstellen entdeckt werden sollen
- Findings effizient triagiert und behoben werden können
Allerdings liefern sie kein vollständiges Angriffsnarrativ. Einzelne Findings müssen intern priorisiert und in den Gesamtkontext eingeordnet werden.
Wann Red Teaming, wann Bug Bounty?
Die entscheidende Frage ist nicht entweder oder, sondern wann welcher Ansatz den grössten Mehrwert liefert.
Red Teaming ist besonders geeignet, wenn:
- Detection- und Response-Prozesse validiert werden sollen
- konkrete Angriffsszenarien im Fokus stehen
- menschliche, technische und organisatorische Kontrollen gemeinsam getestet werden sollen
Bug Bounty ist besonders effektiv, wenn:
- die Angriffsfläche gross und dynamisch ist
- kontinuierliche Transparenz über Schwachstellen benötigt wird
- externe Perspektiven bewusst eingebunden werden sollen
Beide Ansätze ergänzen sich, wenn:
- kontinuierliche Schwachstellenidentifikation mit periodischer Validierung kombiniert wird
- nicht nur Schwachstellen, sondern auch deren mögliche Ausnutzung verstanden werden sollen
| Situation | Empfehlung |
|---|---|
| Detection und Response testen | Red Teaming |
| Schwachstellen kontinuierlich identifizieren | Bug Bounty |
| Dynamische Angriffsfläche | Bug Bounty |
| Menschliche und organisatorische Kontrollen testen | Red Teaming |
| Ganzheitliche Sicherheitsbewertung | Kombination aus beiden |
Was regulatorisch gefordert wird
Aus regulatorischer Sicht ist kein einzelner Ansatz ausreichend.
Unternehmen unter Aufsicht der FINMA müssen ihre Sicherheitsmassnahmen regelmässig überprüfen und risikobasiert weiterentwickeln. In der Praxis umfasst dies auch szenariobasierte Tests wie Red Teaming.
Auch das Nationale Zentrum für Cybersicherheit (NCSC) fördert den strukturierten Umgang mit Schwachstellen und verweist explizit auf Ansätze wie Coordinated Vulnerability Disclosure und Bug-Bounty-Programme, um externe Expertise einzubinden.
Frameworks wie DORA gehen noch einen Schritt weiter. Für bestimmte Organisationen verlangen sie explizit Threat-Led Penetration Testing (TLPT), was in der Praxis Red Teaming entspricht. Gleichzeitig betonen sie die kontinuierliche, risikobasierte Identifikation und Behebung von Schwachstellen.
Diese Anforderungen zeigen: Es geht nicht darum, dass jedes Unternehmen das gleiche Testmodell benötigt, sondern dass Sicherheitstests kontinuierlich, risikobasiert und kontextabhängig erfolgen müssen.
Wie sich die Unterschiede in der Praxis zeigen
Ein Red Team simuliert einen Angriff über Phishing, kompromittiert ein Benutzerkonto und bewegt sich lateral durch das Netzwerk. Das Ergebnis: Die Erkennung erfolgt zu spät, und interne Prozesse greifen nicht wie vorgesehen.
Parallel dazu identifiziert ein Bug-Bounty-Programm mehrere konkrete Schwachstellen: eine unsichere API, ein öffentlich zugängliches Admin-Interface und veraltete Software auf einer Subdomain.
Beide Ergebnisse sind relevant, beantworten jedoch unterschiedliche Fragen.
Warum es nicht um entweder oder geht
Red Teaming und Bug Bounty sind keine konkurrierenden Ansätze.
Sie adressieren unterschiedliche Ebenen der Sicherheit:
- Red Teaming testet, wie gut eine Organisation auf Angriffe reagiert
- Bug Bounty zeigt, wo Angriffe überhaupt möglich sind
Wer sich nur auf einen dieser Ansätze verlässt, erhält ein unvollständiges Bild.
Ein realistisches Verständnis der eigenen Sicherheitslage entsteht erst durch die Kombination beider Perspektiven.
Gehen Sie über punktuelle Tests hinaus. Kombinieren Sie kontinuierliche Schwachstellensuche mit realitätsnaher Angriffssimulation, um ein vollständiges Bild Ihrer Sicherheitslage zu erhalten.
Erfahren Sie, wie ein Bug-Bounty-Programm Ihre bestehenden Security-Tests sinnvoll ergänzt.