Bug-Bounty-Programme: Darstellung von Rahmen- und

Erfolgsfaktoren bei der Einbindung der Community in

das Sicherheitsmanagement
Christoph Bhm
Universitt Bamberg, Lehrstuhl fr Wirtschaftsinformatik insb. Industr. Anwendungssysteme
An der Weberei 5, 96047 Bamberg, Deutschland

christophboehm86@googlemail.com

Abstract. Bug-Bounty-Programme bieten Hersteller von IT-Systemen eine

Plattform um Informationen ber Fehler in Softwareprodukten von Dritten zu
erhalten. Sie erfreuen sich auf Grund positiver Erfahrungen in der Praxis einer
zunehmenden Beliebtheit. Es zeigt sich, dass sie eine kostengnstige und vor allem eine langfristige Mglichkeit darstellen, das Vertrauen der Kunden in das
eigene Produkt zu sichern. Wichtig bei der Einrichtung eines solchen Programmes sind klar definierte Rahmenbedingungen. Eine Definition des Umfangs und
der Ziele sind unerlsslich genau wie ein gut definierter Problemlsungsprozess. Das als Referenzprojekt gewhlte Chrome-Bug-Bounty hat Google
744.680 Dollar ber 4 Jahren gekostet und dabei zu mehr als 620 besttigten
Einreichungen gefhrt. Insgesamt lassen sich Programme dieser Art als ein
sinnvolles Instrument beurteilen, welches jedoch berlegt einzusetzen ist. In
agilen Entwicklungsprozessen wird die Wichtigkeit in der Praxis weiter steigen.
Stichworte: Application-Security, IT-Security, Bug-Bounty-Programme, Vulnerability Rewards, Vulnerability-Markets, White-Hat, Security-Engineering

Einfhrung

1.1

Motivation

Sicherheitslcken sind Schwachstellen in IT-Systemen, die von Angreifern oder

durch ein Schadprogramm ausgenutzt werden, um in dieses einzudringen [1; 2, S.
298]. Aufgrund der groen Komplexitt heutiger Softwaresysteme sind kritische Fehler bei der Entwicklung jedoch trotz umfangreicher Tests und angepasster Entwicklungsprozesse hufig nicht auszuschlieen und finden damit ihren Weg in das Endprodukt [3, S. 1].
Genau hier setzen Bug-Bounty-Programme, in der Praxis auch VulnerabilityReward-Programme genannt, an. Die Hersteller gehen damit explizit davon aus, dass
in der eigenen Software Mngel sind, die jedoch gemeinsam mit dem Nutzer gefunden und behoben werden knnen. Die Programme bilden letztendlich nun eine Plattform, ber welche ein geordneter Informationsaustausch ermglicht wird [4, S. 1].
Fr die Mitarbeit bei der Reproduzierbarkeit und Behebung sowie der Nichtverffent-

lichung wird der Entdecker des Softwarefehlers anschlieend entlohnt. Dabei ist das
frhzeitige Wissen ber die von einem Dritten entdeckte Fehlerlcke entscheidend [5,
S. 1]. Damit ist es fr den Softwareanbieter von groem Interesse, die Zusammenarbeit mit dem Entdecker zu suchen.
Die letzten Jahre haben, im Wesentlichen durch die positiven Erfahrungen mit
solchen Programmen durch groe Hersteller wie beispielsweise Google [6] aber auch
PayPal [7] zu einem steigenden Interesse und einer groen Diskussion dieses Themengebiets in der Praxis gefhrt [4, S. 1]. Eine umfangreiche und vor allem systematische Diskussion dieses Trends in der Wissenschaft sowie Literatur existiert mit einigen Ausnahmen aber kaum. Auf der anderen Seite zeigen empirische Untersuchungen
jedoch Vorteile dieser Programme gegenber traditionellen Methoden der Sicherheitsanalyse [4, S. 15]. Rose vertritt gar die Meinung, dass traditionelle Testverfahren
wie Penetrationstests hierdurch abgelst werden knnen [8, S. 6].
Mit dieser Projektarbeit wird dem Trend daher Rechnung getragen und BugBounty-Programme umfassend betrachtet. Dabei beschrnkt sich die Ausarbeitung
nicht nur auf den Inhalt, sondern ebenfalls auf die organisatorische und prozessuale
Ausgestaltung einer solchen Manahme. Ziel dieser Arbeit ist es daher insbesondere
Interessierten und Unternehmen einen Leitfaden sowie Ideen zu bieten, um ein neues
Programm aufzusetzen oder das eigene Programm weiterzuentwickeln.
1.2

Aufbau der Arbeit

Die vorliegende Projektarbeit gliedert sich in fnf Kapitel. Neben dem einleitenden
ersten Kapitel befasst sich das zweite mit der Einordnung sowie generellen Darstellung von Bug-Bounty-Programmen. In Kapitel drei wird anhand einer empirischen
Untersuchung aus der Praxis Inhalt und Umfang unterschiedlicher Modelle systematisiert und die prozessuale Ausgestaltung diskutiert. Das hufig als Referenz aufgefasste und von Google aufgelegte Chromium-Vulnerability-Reward-Program wird im
vorletzten Kapitel ausfhrlich untersucht. Anhand des Bug-Trackers werden wichtige
Kennzahlen und Erfolgskriterien erarbeitet. Die Schlussbetrachtung vervollstndigt
die vorliegende Ausarbeitung.

Theoretische Grundlagen

2.1

Lebenszyklus von Schwachstellen

Bug-Bounty-Programme beziehen sich alleinig auf Schwachstellen, welche durch

Personen auerhalb des eigenen Unternehmens entdeckt wurden [2, S. 301]. Das von
Frei et al. vorgeschlagene Modell zur Unterteilung des Lebenszyklus eines durch
Dritte festgestellten sicherheitsrelevanten Fehlers kann nun dabei helfen, Risiken fr
den Endanwender zu systematisieren und Handlungsempfehlungen abzuleiten. Ziel ist
eine Ausnutzung der entdeckten Schwachstelle zu verhindern [9].
Die einzelnen Phasen ergeben sich wie in Abbildung 1 dargestellt auf Grund des
Eintretens definierter Ereignisse. Diese sind die Entdeckung sowie die Verffentlichung der Sicherheitslcke aber auch die Bereitstellung und der darauf folgenden
Installation eines Fixes durch den Endkunden [5, S. 4].

3
Abbildung 1. Lebenszyklus eines Softwarefehlers
(in Anlehnung an [5, S. 4])
Entdeckung

Verffentlichung

Patch verfgbar

Patch installiert
Zeit

Black Risk

Gray Risk

White Risk

Die zeitliche Abfolge aber auch der Inhalt der Phasen kann nun je nach Verhalten des
Entdeckers sowie der Art des Fehlers sich unterscheiden. So lsst sich in der Zeit von
der Entdeckung bis zur Verffentlichung feststellen, dass nur eine sehr begrenzte
Anzahl an Personen Wissen ber den Softwarefehler besitzt. Dies knnen Personen
sein, die mit krimineller Energie handeln oder beabsichtigen, das Zielsystem zu beschdigen (als Black-Hat bezeichnet). Genau so gut knnen dies aber auch Sicherheitsdienste, Kunden aber auch Wissenschaftler sein, die ein Interesse an der Zusammenarbeit und Lsung des Problems haben (White-Hat). Das Risiko wird hier als
Black-Risk bezeichnet, da das Wissen ber die eigentliche Schwachstelle fehlt [10, S.
5]. Frei spricht in diesen Zusammenhang auch von bekannten Unbekannten [10].
Nach der Verffentlichung des Fehlers besteht bis zur Bereitstellung eines geeigneten Patches ein graues Risiko. Es existiert keine Lsung des Problems durch den
Softwareanbieter und durch die Bekanntheit des Fehlers in der ffentlichkeit steigt
die Anzahl potentieller Angreifer [10, S. 5]. Der Vorteil einer Verffentlichung ist,
dass hierdurch der Kunde das Angriffs- und Risikopotential bewerten kann. Hufig
bereiten Anbieter auch Workarounds in Form eines Advisory vor, um die Auswirkungen bei einer aktiven Ausnutzung mglichst gering zu halten [10, S. 6].
Zu guter Letzt wird nach der Bereitstellung eines Patches ebenfalls einige Zeit vergehen, bis alle Kunden eine Aktualisierung des Softwaresystems durchgefhrt haben.
Diese Zeit wird als White-Risk bezeichnet [10, S. 5]. Whrend hingegen die vorgelagerten Risikoarten durch den Softwarehersteller zu verantworten sind, steht hier der
Kunde in der Pflicht [10, S. 5]. Bei modernen webbasierten On-Demand-Verfahren
wird dieses Risiko gegen null tendieren, da die Pflege der Software hierbei ebenfalls
vom Hersteller wahrgenommen wird.
Explizit nicht in der Abbildung dargestellt ist der Zeitpunkt der Verfgbarkeit eines Exploits, entsprechend auch Exploit-Time benannt [5, S. 3]. Zeitlich lsst sich das
Auftreten eines Exploits und damit die Mglichkeit zur aktiven Ausnutzung der
Schwachstelle zwischen der Entdeckung und der Installation des Patches einordnen.
2.2

Verffentlichung von Schwachstellen

Betrachtet man das in Kapitel 2.1 dargestellte Lebenszyklusmodell lsst sich feststellen, dass zum Schutz der Anwender der Hersteller im Idealfall in die Lage versetzt
werden sollte die Verffentlichung einer Sicherheitslcke so weit hinauszuzgern, bis
ein Patch zur Verfgung steht. Entsprechend umfassend wurde die Verantwortung
von Forschern bei der Verffentlichung von Sicherheitslcken diskutiert [11, S. 2].
Im Mittelpunkt der Debatte steht das Ziel eine Kooperation der beiden Parteien bei

der Problemlsung zu erreichen. Auf der anderen Seite sieht der Entdecker sein Wissen als Druckmittel, um eine rasche Behebung durch den Hersteller sicherzustellen.
Anstelle eine Korrektur der Software transparent und schnell umzusetzen zeigt die
Praxis nmlich, dass Hersteller dazu neigen, Produktfehler abzustreiten oder Korrekturen nur verzgert bereitzustellen [3, S. 4; 10, S. 11f]. Um die beiden Interessensbereiche auszugleichen werden verschiedene Verffentlichungsmethoden diskutiert.
Beim Full-Disclosure stellt der Entdecker einer Schwachstelle alle ihm vorliegenden Erkenntnisse der ffentlichkeit zur Verfgung, etwa auf einer Mailingliste wie
seclists.org [3, S. 3]. Dies schliet technische Details sowie Manahmen zur Reproduzierung und mglicherweise auch Ausnutzung ein. Vorteil dieses Verfahren ist es,
dass Hersteller gezwungen werden, schnellst mglichst einen Fix bereitzustellen.
Endanwender werden weitergehend gewarnt und knnen Schutzmanahmen ergreifen. Klar ist jedoch, dass Dritte eine Vorlage zur Durchfhrung von Angriffen erhalten und sich damit die potentielle Anzahl an Angreifern erhhen wird [3, S. 3].
Das genaue Gegenteil hierzu stellt das Non-Disclosure dar. Der Entdecker verffentlicht die Schwachstelle nicht und geht davon aus, dass die Allgemeinheit am besten geschtzt ist, wenn keine Information an die ffentlichkeit gelangt [11, S. 6].
Problematisch an diesem Vorgehen ist die Tatsache, dass es keine Garantie gibt, dass
die Sicherheitslcke selbst nicht bereits dritten bekannt ist [11, S. 6]. Die Sicherheit
der Applikation wird damit nur scheinbar gefrdert.
Eine Erweiterung hierzu stellt das Non-Disclosure-Agreement dar. Hierbei wird
eine Vereinbarung mit einem Dritten, zumeist dem Softwarehersteller, getroffen, dass
nach Information an diesen der Entdecker keine Berechtigung hat, die ffentlichkeit
ber die Softwarelcke zu unterrichten. Dieser Ansatz wird weitestgehend in der Literatur mit der Begrndung abgelehnt, dass damit das betroffene Unternehmen keinen
Zwang mehr sieht tatschlich in angemessener Zeit einen Bugfix fr das Problem
bereitzustellen [11, S. 7] und sich das Schweigen der Entdecker erkauft [12].
Um die offensichtlichen Risiken der beiden oben dargestellten Anstze zu vermeiden hat sich in der Industrie daher ein Konzept etabliert, dass einen Ausgleich zwischen den betroffenen Parteien erreichen will. Entsprechende Verfahren werden hier
unter dem Begriff des Responsible-Disclosure oder auch Coordinate-Disclosure [3, S.
3] zusammengefasst. Anstelle einer direkten Verffentlichung rumt der Entdecker
einer Schwachstelle dem Hersteller einen gewissen Zeitraum ein, bis zu dem dieser
ein Stillschweigen ber die Sicherheitslcke garantiert [3, S. 3]. Der Hersteller hat
damit innerhalb der Frist die Mglichkeit, einen Fix fr das Problem bereitzustellen.
Nach dem Ablauf des festgesetzten Zeitrahmens wird ein Full-Disclosure durchgefhrt und damit die ffentlichkeit informiert. Ein solches Vorgehen ermglicht eine
Diskussion des Problems ohne das "Details zu ihrer Ausnutzung in falsche Hnde
geraden und eine unmittelbare Gefhrdung bewirken" [3, S. 4].
2.3

Inhalt von Bug-Bounty-Programmen

IT-Unternehmen versuchen nun Sicherheitsforscher zu einer Zusammenarbeit bei der

Beseitigung von gefundenen Softwarefehlern zu bewegen. Das geeignete Werkzeug
hierfr stellen Bug-Bounty-Programme dar, welche in dieser Projektarbeit behandelt
werden. Anstelle einer unbegrenzten Verffentlichung oder gar dem Verkauf an Dritte sollen gezielt ber Belohnungen Anreize geschaffen werden, damit Entdecker von

Schwachstellen den Informationsaustausch mit dem Hersteller suchen [4, S. 1]. Mehr
noch sollen Bug-Bounty-Programme durchaus aktiv als Lockmittel genutzt werden,
damit externe Personen sich die Sicherheit der Plattform anschauen um auch ganz
neue Schwachstellen zu finden [4, S. 1].
Dabei endet ein Bug-Bounty-Programm aber nicht wie teilweise in der Literatur
dargestellt mit der Einreichung eines Fehlerbildes. Ein solches Programm kann und
soll in dieser Arbeit immer als Prozess betrachtet werden. Inhalt dieses Prozesses ist,
wie auch der Bounty-Marktplatz Bugcrowd.com darstellt, ein Ende-zu-Ende Prozess
[13]. Dieser beginnt bei der Ansprache von potentiellen Testern, die Aufnahme und
Validierung der Fehler, dem Fixing und der abschlieenden Auszahlung der Entlohnung [13; 14, S. 13]. Damit beschreibt dieser Prozess die systematische Einbeziehung
der Community in das Sicherheitsmanagement eines Unternehmens. Entsprechend
dem Open-Source-Gedanken kann ein Bug-Bounty-Programm wie in der Praxis auch
beispielsweise von Google praktiziert so weit gehen, dass fr gefundene Fehler vom
Entdecker ein Fix bereitgestellt wird [15], welcher dann zustzlich honoriert wird.
Dabei bieten Bug-Bounty-Programme sowohl fr den Hersteller wie auch den Sicherheitsforscher eine Reihe von Vorteile. Durch die Ausschreibung einer Entlohnung
werden weit mehr Personen bereit sein, aktiv nach Lcken in der eigenen Software zu
suchen und damit letztendliche unbekannte Fehler finden. Anstelle des Verkaufs auf
dem Schwarzmarkt wird ein Anreiz fr den verantwortungsbewussten Umgang mit
der Sicherheitslcke geschaffen. Die Gefahr von 0-day Exploits wird gesenkt, da
durch die Entlohnung mehr Benutzer bereit sein werden, eines der in Kapitel 2.2 vorgestellten Disclosure-Prinzipien mitzutragen. Zu guter Letzt werden aber auch so
genannte Black-Hats, also Sicherheitsforscher, die gewollt sind auch Sicherheitslcken ber illegale Kanle an Drittfirmen weiterzuleiten, durch die hhere Softwarequalitt [4, S. 1] aber auch durch Parallelentdeckungen des gleichen Fehlers durch
unabhngige Sicherheitsforscher [16] eingeschrnkt. Ergebnis der Einbeziehung der
Community soll damit die wesentliche Verbesserung der Sicherheit sein [4, S. 1].
2.4

Nutzung des Marktes bei der Feststellung von Bugs

Bei nherer Betrachtung sind Bug-Bounty-Programme nichts anderes als eine Mglichkeit zur Nutzung des Marktes fr die Ermittlung von Fehler. Wie in einem Markt
blich stellen die gefundenen Schwachstellen das wirtschaftlich begrenzte Gut beziehungsweie das Angebot dar. Ziel des Sicherheitsforschers ist es dabei, mit mglichst
geringem zeitlichen Aufwand eine maximale Entlohnung zu erzielen [4, S. 8]. Auf der
anderen Seite steht mit dem Hersteller ein Nachfrager bereit, der ein groes Interesse
hat, die Sicherheit der Anwendung zu gewhrleisten. Weitere wichtige Kufer von
Schwachstellen sind staatliche Institutionen, konkurrierende Unternehmen, Zwischenhndler aber auch Personen mit dem Ziel, Schaden zu verursachen [17, S. 2].
Eine Abgrenzung der unterschiedlichen Marktmechanismen ist daher notwendig.
Zunchst muss festgestellt werden, dass der Markt fr Softwareschwachstellen in
einem legalen sowie einem illegalen Bereich aufgeteilt werden kann. Beim Verkauf
eines Fehlers ber einen illegalen Marktplatz hat der Entdecker die Mglichkeit hhere Erlse zu erzielen, setzt sich aber dem Risiko einer Strafanzeige aus [17, S. 2]. Der
legale Weg verspricht eine Sicherheit auf Zahlung sowie eine Zusammenarbeit mit
etablierten Parteien am Markt. Die Schlussfolgerung aus dieser Tatsache ist, dass zur

Preisfestsetzung vom Markt daher neben dem reinen Informationswert und der Kritikalitt des gefundenen Fehlers zahlreiche weitere Faktoren wie Zuverlssigkeit, Einfachheit oder Prestige relevant sind [16]. Weitergehend ist eine Abgrenzung von legalen sowie illegalen Nachfragern in der Praxis meist nicht trennscharf mglich [17, S.
4]. So stellt beispielsweise der Verkauf an staatliche Sicherheitsdienste einen Graubereich dar. Besonders Interessant ist, dass die Anbieter legaler Programme den
Schwarzmarkt selbst nicht als Konkurrenz sehen und daher auch den Preiskampf nicht
suchen [16]. Im Folgenden soll sich daher auf legale Marktmodelle konzentriert werden, wobei sich hier drei konkrete Verfahren herausgebildet haben [2, S. 301]:
Tabelle 1. Legale Vulnerability Markets im berblick
(in Anlehnung an [2, S. 301])

Marktart
1 Bug Bounties

Inhalt und Beispiele

Ausschreibung einer Belohnung fr die Bereitstellung
von Berichten ber sicherheitsrelevante Fehler durch
den Hersteller:
Donald E. Knuths TEX
Mozillas Bug-Bounty-Programm
Deutsche Post Security Cup 2013

2 Vulnerability Brokers

Organisationen, die sicherheitsrelevante Fehler sammeln und diese Information einen Empfngerkreis
bereitstellen:
Computer Emergency Response Team (CERT)
Verisign iDefense
Vupen Threat Protection Program

3 Exploit Derivate

Gegenseitiger Vertrag, um die Risiken eines Schadeneintrittsfall separat an Handelsbrsen auszulagern:

Keine relevanten Praxisbeispiele vorhanden

Bug-Bounty-Programme sind eine der einfachsten Mglichkeit den Markt zur Ermittlung von Softwarefehler zu nutzen. Dabei verspricht der Anbieter wie in Kapitel 2.3
dargestellt eine Belohnung fr Einreichungen. Die Preisfestsetzung wird dabei zumeist ausgehend von einen Mindestpreis dem tatschlichen Marktwert whrend der
Laufzeit angenhert [2, S. 301].
Vulnerability Brokers arbeiten hnlich wie Bug-Bounty-Programme. Letztendlich
handelt es sich bei dem brokerbasieren Anstzen aber um unabhngige Unternehmen,
deren Geschftszweck die Sammlung von Softwarefehler und der anschlieenden
Information von Beteiligten ist [2, S. 302]. Mit dem im Internet sehr weit verbreiteten
CERT existiert eine anerkannte Organisation, die jedoch weder Belohnungen auszahlt
noch Geld fr die Informationsbereitstellung verlangt und daher eine Sonderrolle
einnimmt [2, S. 303]. Die von VeriSign sowie iDefense bereitgestellten Dienstleistungen kaufen im Internet sowohl Zeroday-Lcken aber auch existierende Exploits
von unabhngigen Sicherheitsforschern auf und stellen diese im Internet verkrzt

Interessierten zur Verfgung. Sie bernehmen weitergehend mit dem Softwarehersteller die Abstimmung zur Fehlerbehebung [2, S. 302f]. Aggressivere Anbieter wie beispielsweise Vupen bieten hingegen nur Auskunft ber Sicherheitslcken gegen Bezahlung. Insgesamt haben diese Anbieter jedoch einen negativen Ruf, da sie in der
Praxis nur wenige neue Softwareschwachstellen bereithalten, andererseits aber die
Hersteller eine Mitgliedschaft als erzwungen wahrnehmen [18].
Im Vergleich zu den beiden vorgestellten Marktmechanismen werden bei der Nutzung von Exploit-Derivaten sich im ersten Schritt von einzelnen Sicherheitslcken
gelst und vielmehr das Produkt und das Risiko selbst systematisch betrachtet. Hierfr kann man sich vorstellen, dass zwei Vertrge erstellt werden. Ein Vertrag C sowie
ein gegenlufiger Vertrag werden angeboten. Dabei wird ein bestimmter Geldbetrag, nehmen wir 100 Euro an, mit dem Vertrag C bezahlt wenn ein Bug innerhalb
eines bestimmten Zeitraums in der Software auftritt. Mit dem Vertrag hingegen
wird der gleiche Geldbetrag dann ausgeschttet, wenn kein Fehler auftritt. Da bei
Besitz beider Vertrge unabhngig des Ausgangs immer 100 Euro ausbezahlt werden,
betrgt der Verkaufspreis eines solchen Vertragspaares auch 100 Euro. Werden nun
die Einzelvertrge eigenstndig gehandelt, so kann der Markt jeweils die Aufgabe der
Beurteilung der Softwaresicherheit bernehmen. Bezogen auf einzelne Schwachstellen knnen jedoch Sicherheitsforscher entsprechende Vertrge am Markt kaufen und
mit der Verffentlichung von Exploits die Auszahlung veranlassen. Damit wird dann
auch wieder der Kreis geschlossen und durch den Handel solcher Zertifikate wird die
Anwendung fr Sicherheitsforscher potentiell interessant und Einzelfehler knnen
ermittelt werden [19, S. 303f]. Die Nutzung von Exploit-Derivaten kann vor allem
auch ein wichtiges Kriterium bei mglichen Investoren sein [19, S. 303f]. In der Praxis weit diese Art von Mechanismus keine Relevanz auf. Miller stellt heraus dass ein
Markt mangels Nachfrage schwer zu realisieren ist [17, S. 7].
Bhme fhrt als zustzliche fr die Sicherheitsbewertung nutzbare Marktmechanismen auch Versicherungen auf [19, S. 305f]. Da diese jedoch keine Fehler im eigentlichen Sinn ermitteln sondern sich nur auf die Sicherheitsbewertung konzentrieren sei an dieser Stelle auf die Literatur verwiesen (siehe [19, S. 305f]).
2.5

Abgrenzung zu alternativen Testverfahren

Fr ein Unternehmen stellen Bug-Bounty-Programme damit auch eine neue Perspektive fr die Betrachtung der Sicherheit dar. Zu den traditionellen internen Testverfahren wird durch die Einbindung des Marktes eine externe Sicht eingenommen. Dies
kann sehr gut anhand des Security-Engineering-Prozesses verdeutlicht werden:
Abbildung 2. Phasenmodell im Security-Engineering
(in Anlehnung an [20])
Systematische
Schulung aller
Prozessbebeteiligten

Schutzbedarfsfeststellung
Missbrauchsszenarien
erstellen

Risikoanalyse
Security by
design

Fachabteilung /
Business Analyse

Training

Definition

Design

Code-Review
Tooluntersttzung

Penetrationstest
Fuzzy-Testing
Erstellung von
Notfallplnen

Anwendungsbetrieb

Entwicklung

Implementierung

Monitoring Ausfhrung von

Notfallplnen
regelmige
Systemupdates Vulnerability
Management
Bug-BountyProgramme

Test

Betrieb

Reaktion

Ein derartiger Entwicklungsprozess stellt die Informationssicherheit beginnend bei

der Spezifikation ber die Entwicklung bis weit nach der Inbetriebnahme der Anwendung sicher [4, S. 2]. Zur Abgrenzung gegen alternative Methoden zum Auffinden
einzelner Schwachstellen wurden die relevanten Verfahren jeweils fett markiert.
Ein in der Praxis sehr hufig eingesetzte Manahme ist die Durchfhrung von
Code-Reviews. Die Entwickler prfen dabei zumeist gegenseitig Implementierungen
und Entwrfe. Alternativ knnen auch spezialisierte Kollegen die gesamtheitliche
Quellcodevalidierung bernehmen. Zu den beachteten Kriterien knnen neben der
Sicherheit auch die Verstndlichkeit und Wartbarkeit systematisch getestet werden [4,
S. 2]. Durch die intensive Analyse lassen sich eine Vielzahl von Schwachstellen im
Code frh erkennen. Zentrales Problem dieser Methode sind jedoch die hohen Kosten
einer doppelten Prfung. Architektonische Fehler werden hufig nicht erkannt.
Als Alternative zur manuellen Prfung kann mit dem Werkzeug der statischen und
dynamischen Codeanalyse ein automatisierter Sicherheitstest erfolgen. Whrend die
statische Codeanalyse den Quellcode der Anwendung untersucht und damit hnliche
Ziele wie der Code-Review verfolgt laufen dynamische Testwerkzeuge zur Programmlaufzeit und prfen das Applikationsverhalten selbst. Fehler, die im Zusammenspiel mit Drittkomponenten oder erst unter definierten Vorbedingungen auftauchen, knnen damit erkannt werden [4, S. 2]. Der Nachteil einer Tooluntersttzung
ist, dass ein hoher Aufwand in die Erstellung geeigneter Tests investiert werden muss
und nur klar definierte Fehlerbilder erkannt werden wrden. Auf der anderen Seite
ermglichen definierte Prfungen einen umfassenden und schnellen Test [21, S. 5].
Der als Black-Box-Test angelegte Penetrationstest ermglicht die Prfung der Sicherheit mglichst aller Systembestandteile und Anwendungen eines Netzwerks- oder
Softwaresystems. Hierzu werden Verfahren verwendet, die auch Angreifer fr das
Eindringen in die Applikation nutzen. Wesentlicher Teil eines Penetrationstests sind
Werkzeuge, die dabei helfen, mglichst alle Angriffsmuster nachzubilden [4, S. 2].
Zentraler Nachteil des Penetrationstest ist sein allumfassender Ansatz, so dass ein
vollstndiger Test hufig nur sehr aufwndig realisierbar ist.
Hiervon abzugrenzen ist das Fuzzy-Testing. Anstelle des Einsatzes von bestimmten Techniken wird von automatisierten Programmen eine Vielzahl an unterschiedlichen Daten zur Verarbeitung der Anwendung vorgelegt. Ziel ist es, Crashes und
berlufe zu verursachen. Einzelne Sicherheitslcken knnen damit meist nicht erkannt werden. Es stellt daher nur eine Ergnzung zu anderen Testverfahren dar [22].
In Abgrenzung mit Bug-Bounty-Programmen lassen sich im Vergleich zu den alternativen Anstzen nun einige zentrale Unterschiede erkennen. So stellen BugBounty-Programme eine Mglichkeit dar, auch im Betrieb ein systematisches Testen
der Applikation sicherzustellen. Whrend im Rahmen von einem Entwicklungsprozess meist nur neue Funktionalitt betrachtet wird, ermglichen diese weitergehend
neue Angriffsszenarien, beispielsweise auf Grund der Technologieweiterentwicklung,
durch Externe auch auf bestehende Funktionalitt testen zu lassen. Durch Rckfhrung der Ergebnisse der Einreichungen knnen damit auch die internen Testmglichkeiten weiter verbessert werden. Interessant wird ein Vergleich mit den alternativen
Testverfahren vor allem auch dann, wenn Kosten- oder Effektivittsvorteile der vorgestellten Einzelverfahren abgegrenzt werden. Hier weit Finifter et al. auf Kostenvorteile fr Bug-Bounty-Programme hin [4, S. 14]. In der Praxis werden sich die Einzelmanahmen wie in den folgenden Kapiteln noch gezeigt wird jeweils ergnzen.

2.6

Rechtliche Einordnung von Schwachstellenanalysen

Der Gesetzgeber hat im Jahr 2006 mit dem 202c StGB alle Vorbereitungshandlungen zum Aussphen von Daten unter Strafe gestellt. Dies umfasst die Herstellung, den
Vertrieb sowie ebenfalls die berlassung entsprechender Programme [23]. Damit
setzt Deutschland das vom Europarat getroffene bereinkommen ber Computerkriminalitt, bezeichnet als Cybercrime Convention, um [24, S. 2]. Mit dem Beitritt von
Amerika, Japan sowie Sdafrika [25, S. 1] weist dieses Abkommen mittlerweile auch
eine internationale Bedeutung auf, was fr Bug-Bounty-Programme von Relevanz ist.
Da die Anwendbarkeit des 202c explizit vom Zweck des Werkzeugs ausgeht und
die Ziele und Aktivitten der Personen nicht bercksichtigt, wird die Auslegung des
Gesetzestextes in der Literatur kritisch diskutiert. Konkret beschreibt der Gesetzgeber
einen abstrakten Gefhrdungsdelikt [24, S. 5] und verbietet damit grundstzlich bestimmte Verhaltensweisen, bei denen die Vermutung vorliegt, dass diese eine Gefahr
darstellen knnen. Auf die wachsende Kritik der Rechtsauslegung des Paragraphen
hat der Bundestag reagiert und darauf hingewiesen, dass der gutwillige Umgang mit
Hackertools nicht von 202c StGB erfasst wird. Dieser Meinung folgten auch die
Gerichte [24, S. 11]. Angewandt gegen konkrete Verffentlichungen von Sicherheitslcken wurde der Paragraph unter anderem vom Softwarehersteller Magix [26].
Parallel hierzu knnen von den Betreibern von Softwareprodukten ebenfalls in den
Vertragsbedingungen sowie den allgemeinen Geschftsbedingungen entsprechende
Vertragsstrafen bei Schwachstellenanalysen festgesetzt werden [27]. Ein Beispiel
hierfr war die Plattform StudiVZ [27]. ber die Gltigkeit solcher Vertragsbestandteile wird ebenfalls in der Literatur diskutiert. Fr Privatpersonen kann hier jedoch
von einer Ungltigkeit entsprechender Vertragsbestandteile ausgegangen werden. Fr
Unternehmen hingegen sind diese bindend [27].
Hierauf aufbauend lassen sich einige wesentliche Erkenntnisse ableiten. Generell
ist auch ohne zugrundeliegendes Bug-Bounty-Programm in Europa ein Umgang mit
so genannten Hacker-Programmen erlaubt. Die Weitergabe von Sicherheitslcken
darf gem Gesetz nur an bekannte und zuverlssige Partner erfolgen. Weitergehend
drfen die Beschreibungen von Fehlerlcken keinen unbegrenzten Personenkreis zur
Verfgung gestellt werden (Public Disclosure) [24, S. 12]. Wer diese Regeln nicht
befolgt macht sich zumeist schuldig. Durch ein Bug-Bounty-Programm wird nun
darber hinaus dem Sicherheitsforscher implizit die von Jlussi et al. geforderte Einwilligung des Herstellers gegeben [24, S. 12], die Plattform auf Sicherheitslcken zu
untersuchen. Durch die Definition der genauen Bedingungen kann ein klarer Rahmen
vorgegeben werden fr die Arbeit von externen Personen. Dies beinhaltet die Einschrnkung der Art der Angriffe und die Sicherstellung der bermittlung von Fehlerberichte an den Hersteller als zuverlssigen Partner.
Weitergehend entsteht mit der Einreichung eines Fehlers und der Besttigung
durch den Hersteller zwischen den beiden Parteien implizit ebenfalls ein Vertrag. Als
Grundlage gelten die Teilnahmebedingungen mit allen Rechten und Pflichten. Diese
Pflichten knnen beispielsweise in Form eines Non-Disclosure-Agreements ber die
im StGB definierten Anforderungen hinausgehen. Bei Versto knnen entsprechende
Schadensersatzansprche und eine rechtliche Strafverfolgung erfolgen.

10

Bug-Bounty-Programme in der Praxis

3.1

Ausgestaltung von Bug-Bounty-Programmen

Eine einheitliche Systematisierung von Bug-Bounty-Programmen existiert in der

Literatur nicht. Dies ist letztendlich auch der Tatsache geschuldet, dass die Unternehmen fr ihre Produkte und Technologien auf ihre Bedrfnisse zugeschnittene Kriterien festlegen. Folgende Bereiche lassen sich jedoch abgrenzen und sollten daher
bei der Ausgestaltung bercksichtigt werden. Grundlage der Darstellung ist eine
bergreifende Auswertung der Bestimmungen und Rahmenfaktoren der unterschiedlichen Anbieter. Zur bersicht bieten hier einzelne Webseitenbetreiber umfangreiche
Listen an (vergleiche [28] sowie [29]).
Abbildung 3. Entscheidungskriterien fr Bug-Bounty-Programme
(eigene Darstellung)
Bounty

Monetr

Art

Wettbewerb

Teilnehmer

Offen fr
alle

Entlohnung je
Einreichung
Klar definierte
Gruppen

Zeit

Befristet

Unbefristet

NonDisclosure
Art Sicherheitslcke
Eigenes
Unternehmen

ResponsibleDisclosure
Domain /
Programm

Disclosure
Ausschluss von
Einreichungen
Ausfhrung durch

Sachgter

Hall-ofFame

Beta / Stable

Drittunternehmen

Die in der Abbildung dargestellten sieben Dimensionen werden von dem Softwareanbieter zumeist als Teilnahmebindungen fr das Programm vorgeschrieben und stellen
damit den Rahmenvertrag fr die Zusammenarbeit mit der Community dar. Die ausfhrliche Definition und Dokumentation verhindert Konflikte mit der Community,
beispielsweise wenn sich ein Einreicher falsch entlohnt fhlt [30]. Ein gutes Beispiel
fr einen gesamtheitlichen Rahmenvertrag bietet Google (vergleiche [31]). Pro Kriterium sind dabei mindestens eine Auswahl beziehungsweie Einschrnkung zu treffen.
Kriterium 1: Bounty.
Typischerweise lassen sich Bug-Bounties anhand der Prmienarten unterteilen [28].
Bei der Auswertung der auf Bugcrowd.com vorhandenen Liste lsst sich feststellen,
dass von den 261 genannten Programmen nur 58 eine monetre Entlohnung vorsehen,
18 bieten Sachgter bei einer erfolgreichen Einreichung und etwa 104 setzen alleinig
auf eine Hall-of-Fame [28]. Der Rest wird zwar in der Liste erwhnt, bietet aber keine
Entlohnung fr die Einreicher an. Eine aktive Ansprache der Community existiert bei
diesen reinen Disclosure-Policies nicht.

11

Vor allem Unternehmen die aktiv am Markt auftreten und externe Sicherheitsforscher binden wollen werden auf eine geldliche Entlohnung von Einreichungen nicht
verzichten knnen. Vor diesem Hintergrund muss die No-more-free-bugs-Bewegung
betrachtet werden. Hacker, die durch ihre Arbeit die Qualittssicherung von Firmen
untersttzen, brachten dabei ihren Unmut ber die fehlende Bereitschaft fr Sicherheitslcken auch zu bezahlen zum Ausdruck [32].
Die prominentesten Vertreter dieser Art von Belohnungsmodell sind Google,
PayPal, Deutsche Telekom aber auch kleinere Webanbieter wie Prezi [28]. So bezahlt
PayPal bis zu 10.000 Dollar fr kritische Fehler an den Findern aus. Bei der monetren Entlohnung von Sicherheitsforschern ist eine Staffelung der Auszahlungsbetrge
sinnvoll. Je nach Kritikalitt der gefundenen Schwachstelle aber auch der Qualitt der
Einreichung sind diese zu variieren [4, S. 14]. Zustzlich kann die Mitwirkung bei der
Lsung der Sicherheitslcke bercksichtigt werden [33].
Alternativ haben sich Sachgter als Entlohnung bei kleineren Programmen etabliert. So versendet Pinterest T-Shirts [34]. Eine Hall-of-Fame kann genutzt werden um
Personen mit besttigten Einreichungen auch ffentlich zu loben. Hiermit soll vor
allem die Reputation der Sicherheitsforscher gefrdert werden. Ein Programm, dass
ausschlielich auf eine solche Entlohnung setzt ist der von Adobe aufgesetzte AlertUs Prozess [35]. Zu beachten ist, dass die einzelnen Prmienarten kombinierbar sind
[28]. So wird eine Hall-of-Fame meist parallel zur monetren Entlohnung gefhrt.
Die Dimension des Bounties ist ein zentraler Aspekt bei der Ausgestaltung von
Programmen. Die Herausforderung ist es, eine Entlohnung zu ermitteln, zu welchen
die Sicherheitsforscher bereit sind, eine Schwachstelle zu melden beziehungsweie
auch aktiv Fehler zu suchen. Grundstzlich wird man bei der Neuaufsetzung eines
solchen Programms im ersten Schritt ein relativ niedriges Bounty ansetzen um dann je
nach Reaktion der Community die Preise systematisch anzuheben [2, S. 301]. Die
Bounty-Festsetzung hngt damit unmittelbar mit den verfolgten Zielen zusammen.
Kriterium 2: Art des Bounty-Programms.
Eine weitere wichtige Entscheidung muss der Hersteller treffen wenn er die Art der
Durchfhrung festlegen will. Dabei weist der Groteil der untersuchten Programme
einen Modus auf, bei dem jede Einreichung eigenstndig bewertet und fr Auszahlungen bercksichtigt wird. Auch hier kann das von PayPal oder Google gewhlte
Verfahren beispielhaft gelten. Fr kleinere Programme und Unternehmen knnen
jedoch Wettbewerbe eine sinnvolle Alternative darstellen. Anstelle jeweils alle Einreichungen zu belohnen knnen hier detaillierte Ziele fr die Teilnehmer ausgearbeitet werden. Weiter beschrnken sich Wettbewerbe zumeist auf einen festen Zeitraum
sowie gegebenenfalls einen festen Personenkreis.
Ein typisches Beispiel fr einen solchen Ansatz stellte der von der Deutschen Post
zum Start des ePost-Briefs veranstaltete Security Cup dar. Bei diesen bewertet eine
Jury die Einreichungen eines fest definierten Teilnehmerkreises. Die jeweils fnf
besten Einreichungen werden durch eine Prmie gewrdigt. Zur Sicherstellung einer
kontinuierlichen Sicherheitsberprfung kann dann ein solcher Wettbewerb in regelmigen Zeitabstnden wiederholt werden [36]. Ein weiteres Beispiel stellt
Pwn2Own dar. Hierbei handelt es sich um eine Plattform anlsslich der Sicherheitskonferenz CanSecWest, bei dem Hersteller ihre eigenen Produkte unter den vorgege-

12

benen Teilnahmebedingungen den Sicherheitsforschern zur Verfgung stellen. Ziel

des Wettbewerbs ist die Prsentation eines Exploits auf Grundlage eines bisher unbekannten Sicherheitsfehlers. Die Hersteller schreiben fr gefundene Sicherheitslcken
fr den Wettbewerb Bounties aus. Die Attraktivitt dieses Forums stellt, da mehrere
Anbieter vertreten sind, der direkter Vergleich mit Konkurrenzprodukten dar [37].
Eine interessante Mglichkeit bietet die Kombination von fest installierten Programmen und vereinzelten darber hinausgehenden Wettbewerben. Ziel ist in der
Community selbst hierdurch fr Abwechslung zu sorgen oder durch klare Zielvorgaben bestimmte Sicherheitsaspekte tiefer untersuchen zu lassen. Eine Gamification,
also die Anwendung spielerischer Elemente, kann dadurch erreicht werden [4, S. 13].
Kriterium 3: Teilnehmer.
Die Idee von Bug-Bounty-Programmen muss es sein eine sehr breite Anzahl an Personen anzusprechen um letztendlich auch eine Diversifikation der Fehlerbilder und
damit des Wissens zu erreichen [4, S. 7]. Deshalb sind bei einer groen Anzahl der
Bug-Bounty-Programme auch Einreichungen durch die breite ffentlichkeit mglich.
Dies wird zumeist eingeschrnkt, da Beitrge von Firmenangehrigen nicht akzeptiert
werden. Zu prfen ist, ob Einreichungen von Institutionen wie VUPEN, die sich auf
das Finden von Bugs spezialisiert haben, fr Bounties zugelassen werden.
Hufig werden kleinere Unternehmen jedoch davor zurckschrecken das komplette
Internet aufzufordern, nach Sicherheitslcken auf der eigenen Webseite zu suchen.
Hierfr fehlen Mglichkeiten bezglich einer validen Einschtzung der Anzahl der
Einreichungen. Anstelle hierzu gibt es vor allem dann meist im Rahmen eines Wettbewerbs realisiert die Idee nur einen klar definierten Personenkreis anzusprechen.
Typischerweise kann ein Registrierungsprozess eingefhrt werden, bei dem der Anbieter sich das Recht vorenthlt nur bestimmte Personen freizuschalten [36]. Ebenfalls
sinnvoll knnen Kooperationen mit Universitten sein.
Zentrales Problem einer Einschrnkung des Teilnehmerkreises ist, dass der allgemeingltige Charakter hierdurch verloren geht. Bei einer Begrenzung sollte daher
zumindest eine Responsible-Disclosure-Policy parallel aufgesetzt werden.
Kriterium 4: Zeit.
Bei der zeitlichen Ausgestaltung werden unbefristet sowie befristet laufende Programme unterteilt. Im ersten Fall mchte der Softwareanbieter durch einen zeitlich
festgestellten Rahmen Sicherheitsforscher ermuntern ein Produkt detailliert zu untersuchen. Vorteil dieses Verfahren ist, das Unternehmen ber diese Einschrnkung sehr
gut die bentigten Ressourcen steuern knnen. So schreibt Microsoft regelmig bei
der Neuverffentlichung von Produkten oder bei Beta-Tests relativ hohe Bounties
aus. Entsprechend wurde die Einfhrung des Internet Explorers 11 mit einem dreiigtgigen Programm begleitet, wobei bis zu 11.000 Dollar fr Fehler in dieser fr die
breite ffentlichkeit noch nicht vorgesehenen Reviewversion bezahlt wurde [38].
Die Alternative sind zeitlich unbefristete Bounties. Diese stellen den Normalfall
dar. Dabei behalten sich die Hersteller zumeist das Recht vor, nach eigenem Willen
die Programme auch zu beenden. Das von Google mittlerweile vier Jahre laufende
Chromium-Reward-Programm geht hier einen Zwischenweg. Im Rahmenvertrag ist

13

explizit eine zeitliche Befristung von einem Jahr genannt. Verlngerungen der Laufzeit werden bei einem wirtschaftlichen Erfolg jhrlich verkndet [31, S. 1].
Kriterium 5: Disclosure.
Beim Disclosure gehen die Unternehmen in der Praxis ganz unterschiedliche Wege.
So whlt Google ein abgestuftes Responsible-Disclosure-Konzept in Abhngigkeit
der Kritikalitt. Bei anderen Unternehmen wie PayPal mssen Sicherheitsforscher
einem Non-Disclosure Agreement zustimmen. Da bereits in Kapitel 2.2 umfangreich
auf die Vor- und Nachteile der Disclosure-Policies eingegangen wurde ist an dieser
Stelle keine weitere Ausfhrung notwendig.
Kriterium 6: Ausschluss von Einreichungen.
Um die Community gezielt steuern und die Art der Angriffe eingrenzen zu knnen
werden von vielen Herstellern Ausschlusskriterien definiert. So ist eine bei allen Anbietern gefundene Regel, dass Einreichungen von bereits bekannten Fehlern nicht
entlohnt werden knnen. Entscheidend fr die Feststellung von unabhngig voneinander gefundenen Sicherheitslcken ist das Einreichungsdatum.
Bei der Abgrenzung der Angriffsszenarien selbst wurden Einschrnkungen bezglich der Domnen sowie der unterschiedlichen Angriffsarten festgestellt. Auch hier ist
die Ausgestaltung stark produktabhngig. So knnen die Angriffsszenarien von webbasierten Verfahren im Vergleich zu Festinstallationen groe Unterschiede aufweisen.
Teilweise schlieen Softwarehersteller daher auch explizit festinstallierte Anwendungen aus [39]. Bei der Art der Sicherheitslcke bietet die OWASP Top 10 Liste (vergleiche [40]) hier einen ersten Ansatzpunkt fr die Orientierung bei der Eingrenzung.
Entsprechend definieren die Teilnahmebedingungen des Google-Programms nur vier
definierte Gruppen von akzeptierten Angriffsszenarien [39].
Darber hinaus beschrnken Unternehmen Bug-Bounties alleine auf bereits verffentlichte Produktversionen. Werden auch Einreichungen fr gerade in der Entwicklung oder Test sich befindende Funktionalitten akzeptiert, ermglicht dies einerseits
die frhe Einbeziehung der Community. Andererseits mssen mglicherweise Bounties ausbezahlt werden, die spter im Test ebenfalls aufgefallen wren [4, S. 8].
Zustzlich lassen sich in den Rahmenbedingungen gezielt Domnen aufzhlen, die
fr eine Auszahlung berechtigt sind. Nicht ber diese URLs erreichbare Webseiten
werden nicht bei einer monetren Entlohnung bercksichtigt [39]. Somit knnen beispielsweise Neuakquisitationen oder aber nicht-kritische Programmbestandteile, die
keine kundenrelevanten Daten bearbeiten, explizit ausgespart werden.
Bei der Bestimmung der Ausschlusskriterien muss die Frage, ob eine Angriffsart
zu einer Kompromittierung des Produktionssystems fhren kann, eine wichtige Rolle
spielen. Es ist sicherzustellen, dass die Verfgbarkeit des Systems und die Vertraulichkeit der Daten auch bei Tests gewhrleistet bleibt. Um dies zu garantieren schreibt
Facebook die Verwendung von Testaccounts vor, andere Hersteller wie die Deutsche
Post nutzen spezielle Entwicklungssysteme fr Sicherheitsforscher.
Final muss festgehalten werden, dass die Auslegung der Ausschlusskriterien in der
Praxis flexibel erfolgen muss. Je nach Anwendungsfall knnen eigentlich ausgeschlossene Fehlerbilder auf Grund deren Kritikalitt sowie Medienwirksamkeit auch
zu entlohnen sein [8, S. 19; 30].

14

Kriterium 7: Ausfhrung durch.

Zu guter Letzt lassen sich Programme danach unterscheiden ob diese vom eigenen
Unternehmen ausgefhrt werden oder aber eine Drittfirma fr die Umsetzung und das
Handling der Bugs beauftragt wird. Im Internet haben sich Softwareplattformen oder
Marktpltze entwickelt, auf welchen sich Wettbewerbe ausschreiben lassen. Die bekanntesten Vertreter dieser Idee sind Bugcrowd.com oder Hackerone.com.
Fr Unternehmen werden solche Angebote immer dann interessant, wenn diese
beispielsweise auf Grund der Marktstellung vermutlich selbst nicht in der Lage sein
werden, eine gewnschte Anzahl an Hacker anzulocken. Darber hinaus bieten die
Anbieter ber die reine Vermittlungsfunktion Mehrwertdienste wie die Steuerung der
Auszahlung oder Priorisierung von eingehenden Anfragen gegen ein entsprechendes
Entgelt [13]. Groe Softwarehersteller wie Google oder PayPal haben durch ihre Ausstrahlkraft am Markt hier meist weniger Probleme Mitglieder zu erreichen.
3.2

Einbindung in das Vulnerability Management

Die in Kapitel 3.1 erarbeiteten Kriterien geben wie beschrieben nur den Rahmen vor,
in welchem die externen Sicherheitsforscher aktiv werden sollen. Wie dargestellt ist
ein Bug-Bounty-Programm jedoch nicht nur als ein Weg zu verstehen, Schwachstellen von Personen einzusammeln, sondern vielmehr die Webapplikation in Zusammenarbeit mit der Community sicherer zu machen. Das bedeutet, dass das Finden von
Fehler nur ein erster Schritt auf dem Weg zu mehr Sicherheit ist. Entsprechend wichtig ist es hierauf aufbauend einen systematischen Prozess zu besitzen, um entdeckte
Schwachstellen in der eigenen Applikation beheben zu knnen [30]. Dies ist besonders von Bedeutung, wenn beispielsweise ein Responsible-Disclosure mit dem Einreicher vereinbart wurde und damit eine begrenzte Zeit fr die Korrektur der
Schwachstelle garantiert werden muss. Die zentrale Herausforderung bei dem Prozess
ist es, den externen Sicherheitsforscher in die Fehlerbehebung einzubinden.
Ein geeignetes Werkzeug um dies Sicherzustellen beschreibt das Vulnerability
Management. Dieses befasst sich mit der zyklischen Identifizierung, Klassifizierung
und Behebung von Schwachstellen in IT-Systemen [41, S. 1]. Wie auch Foreman
beschreibt ist eine Definition explizit sehr breit gewhlt [41, S. 1], kann aber in unserem Fall auf den Bug-Bounty-Prozess fokussiert werden. Ziel ist deshalb die Erarbeitung von Prozessen und Techniken, mit denen zur Steigerung der IT-Sicherheit eine
geordnete Abwicklung der eingehenden Sicherheitslcken unter Zeit- und Kostenaspekten garantiert werden kann.
Abbildung 4. Grundschritte im Vulnerability Management Prozess
(in Anlehnung an [14, S. 3])

Benachrichtigung

[Schwachstelle
besttigt]

Analyse

Lsung
[Schwachstelle
nicht besttigt]

Release

15

Als Rollen kommen in diesem Prozess einerseits wie bereits dargestellt die des Einreichers und die des Herstellers zwangsweise vor. Der Einreicher bernimmt dabei
die Rolle des Prozessinitiators. Zumeist zeichnet er sich durch entsprechendes Fachwissen in dem vom Bug betroffenen Bereich aus und kann daher technisch und inhaltlich einen Beitrag zur Lsungsfindung leisten. Weitergehend kann er in die Evaluierung der Arbeitsergebnisse einbezogen werden [42, S. 4].
Der Hersteller selbst sollte eine klare Unterscheidung zwischen einer Entwicklungs- sowie einer Koordinationsrolle vornehmen [42, S. 4]. Im Rahmen der Koordinierung wird sichergestellt, dass der Prozess der Fehlerbehebung systematisch berwacht und damit ein Stillstand bei der Bearbeitung vermieden wird. Durch sein
Fachwissen kann er eine Einordnung des Fehlers vornehmen. Des Weiteren hat der
Koordinator einen berblick ber hnliche Flle oder Abhngigkeiten zu existierenden Sicherheitslcken und verknpft diese entsprechend. Der Entwickler selbst ist
Experte in dem vom Fehler betroffenen Programmbestandteil, beispielsweise da er die
ursprngliche Implementierung vornahm. Die Entwicklungsabteilung soll bereits sehr
frh im Prozess einbezogen werden um Workarounds vorzuschlagen und Korrekturen
fr die Anwendung zu betrachten [42, S. 4]. Je nach Prozessaufsetzung ist es sinnvoll,
eine unabhngige berwachungsstelle einzusetzen. Diese wrden die Einreichung
evaluieren und die Effektivitt der Kommunikation mit dem Kunden sicherstellen [14,
S. 2f], beispielsweise wenn Meinungsverschiedenheiten im Prozess auftreten.
Ein kritisches Element ist bei dem Prozess der Zeitrahmen. Als grobe Richtwerte
empfiehlt es sich hier, ein erstes Feedback dem Entdecker sptestens nach sieben und
den Fix nach 30 Tagen zur Verfgung zu stellen. Je nach Disclosure-Prinzip sowie
Schwere und Umfang der Sicherheitslcke kann ein gemeinsamer vom Standard abweichender Zeithorizont vereinbart werden. [14, S. 3].
Bei der Umsetzung der Einzelprozessabschnitte in die Praxis ist es von groer Relevanz, eine Adaptierung dieser auf die jeweilige zugrundeliegende Systemarchitektur
sicherzustellen. Hier weien vor allem webbasierte Verfahren wie Facebook im Vergleich zu Festinstallationen wie beispielsweise die Java-Laufzeitumgebung den Vorteil auf, dass die Releaseprozesse weit einfacher und damit auch schneller gestaltet
werden knnen. Hufig kann dann mit der Einspielung des Fixes bereits auch eine
Offenlegung der Schwachstelle durchgefhrt werden. Gleiches wurde in Kapitel 2.1
bereits dargestellt. Die einzelnen Prozesse sollen nun detailliert prsentiert werden.
Benachrichtigungsphase.
Wie das OIS ausfhrt ist es in jeder Phase essentiell, dass eine schnelle und effektive
Kommunikation zwischen Hersteller und Entdecker sichergestellt ist [14, S. 4]. Dies
fngt bereits damit an, dass ein einfach zu kontaktierenden Point-of-Contact geschaffen wird ber welchen Produktfehler vom Entdecker eingestellt werden knnen. Zur
Vereinheitlichung soll fr die Diskussion bei einer Einreichung von einem Vulnerability Summary Report, oder abgekrzt VSR, gesprochen werden [14, S. 6].
Die Kontaktaufnahme wird in der Praxis zumeist per E-Mail durchgefhrt. Alternativ bieten einige Anbieter ebenfalls Formulare zur Einreichung. Das OIS schlgt
hier eine Konvention bei den Adressen vor. Konkret sollen Fehler immer unter
https://[vendor_domain]/security eingereicht und die Kontaktemailadresse security@[vendor_domain] verwendet werden knnen. Zu groen Anteilen wird dies auch

16

von den Herstellern gelebt. Bei der bermittlung von VSRs wird zwingend eine verschlsselte Kommunikation empfohlen, um eine Aussphung zu vermeiden [14, S. 5].
Um eine mglichst einheitliche Kontaktaufnahme mit allen relevanten Informationen sicherzustellen soll der Hersteller die bentigten Informationen klar vorgeben.
Dies kann entweder durch ein Formular auf einer Webseite realisiert sein oder als EMail-Vorlage hinterlegt werden. Der Inhalt einer solchen Einreichung soll zwingend
die betroffene Softwareversion enthalten. Weitergehend kann auch auf die zugrundeliegende Konfiguration (beispielsweise Betriebssystem oder Endgert) eingegangen
werden. Wichtiger ist jedoch, dass der Einreicher eine Schritt-fr-Schritt Anleitung,
Testdaten sowie ein Proof-of-Concept liefert. Es soll eine Reproduzierbarkeit des
Fehlers durch den Hersteller jederzeit mglich sein [14, S. 6].
Auf Seiten des Softwareanbieters soll sich eine zentrale Person (Koordinationsrolle) fr die Betreuung der Fehler verantwortlich zeigen und dem Melder umgehend
den Erhalt der Daten besttigen. In der Antwort soll einerseits eine Referenz auf die
Regeln zur Teilnahme sowie das weitere Vorgehen beschrieben sein. Die bermittlung einer eindeutigen Bug-Id ermglicht in der weiteren Kommunikation eine klare
Abgrenzung bei Mehrfacheinreichungen [14, S. 9]. Die Besttigung ist auch deswegen unverzglich zu geben, damit der Entdecker bei einem Fehler whrend der Kommunikation (Email landet im Spam, Fehler bei der bermittlung) neu aktiv werden
kann um das Problem zu eskalieren [14, S. 8].
Analysephase.
Nachdem der Empfang des VSR dem Endanwender besttigt wurde muss im nchsten
Schritt der Inhalt analysiert werden. Ziel der Untersuchungsphase ist es, auf Grundlage der Einreichung die Aussage des Entdeckers zu verifizieren und einzuordnen [14,
S. 9]. Folgender Prozess ergibt sich:
Abbildung 5. Analyse von Einreichungen
(in Anlehnung an [14, S. 10])

[Einreicher wiederlegt
Ergebnis]

Hersteller
Untersuchung
VSR

Hersteller
Bewertung der
Kritikalitt

Hersteller
Ergebnisdokumation

Einreicher
Prfung des
Ergebnisses

[Ist
Fehler]

[Einreicher besttigt [Ist kein

Fehler]
Ergebnis]

Hersteller / Einreicher
hat Rckfragen

Im Mittelpunkt der Betrachtung steht in der Analysephase die Reproduzierbarkeit der

Einreichung. ber dieses Ziel hinaus muss der Fehler insoweit aufbereitet werden,
dass darauf aufbauende abhngige Fehlerbilder erkannt sowie betroffene Produktversionen identifiziert werden knnen. Zustzlich muss der Hersteller bei der Untersuchung ebenfalls prfen, welche weiteren Angriffsvektoren durch den beschriebenen
Fehler mglich sind und ob bereits unbemerkt eine aktive Ausnutzung der Sicher-

17

heitslcke stattfindet [14, S. 11]. Dies kann beispielsweise durch die Auswertung von
Logdateien geschehen.
ber den kompletten Prozess hinweg kann der Einreicher den Hersteller kontaktieren
um zustzliche Erkenntnisse bekannt zu geben oder den Bearbeitungsstand abzufragen. Auf der anderen Seite soll natrlich auch der Hersteller die Mglichkeit haben
dem Einreicher zu kontaktieren. Typischerweise knnen sich Rckfragen auf die Installation von Drittapplikationen oder der zugrundeliegende Infrastruktur beim Einreicher beziehen. Eine umfangreiche Mitwirkung darf aber niemals Pflicht fr den
Prozess sein, der Hersteller ist hier in der aktiven Rolle [14, S. 12].
Aufbauend auf den gefundenen Daten ist eine Risikobewertung sowie eine Priorisierung durchzufhren. Je differenzierter die Klassifizierung in dieser Phase erfolgt,
desto prziser ist die Steuerung der Bearbeitung und die Auswertung dann letztendlich in den darauffolgenden Prozessen der Lsung sowie im Release mglich [43].
Eine finale Klassifizierung kann sich auch zu einem spteren Zeitpunkt ergeben, beispielsweise wenn eine aktive Ausnutzung festgestellt wurde oder die Ursachenanalyse
neue Erkenntnisse hervorbrachte. Fr die Bewertung haben sich am Markt verschiedene Verfahren etabliert. Sehr verbreitet ist beispielsweise das CVSS-Scoringsystem.
Dieses ermglicht anhand definierter Fragen einen Scoringwert zu ermitteln, der dann
in gelufigen Begrifflichkeiten wie Hoch, Mittel oder Niedrig bersetzt werden kann
[44]. Eine vollstndige Liste an Verfahren definiert Krsul [45].
In der vom Hersteller zu verfassenden Ergebnisdokumentation wird beschrieben,
ob auf Grundlage der Einreichung ein Fehler festgestellt wurde. Um die unternommenen Manahmen transparent darstellen zu knnen sind alle Tests sowie die untersuchten Produktversionen klar zu dokumentieren. Sollte es tatschlich einen Fehler im
System geben, sollen dem Entdecker die vom Unternehmen geplanten Manahmen
zur Beseitigung der Schwachstelle inklusive eines groben Zeitplans vorgestellt werden [14, S. 12]. Hierdurch wird diesem die Sicherheit einer schnellen Behebung gegeben. Sollte kein Fehler gefunden werden, so mssen auch diese Beweise dem Einreicher vorgelegt werden. Dem Finder soll anhand technischer Erklrungen oder
Handbchern die korrekte Arbeitsweise und ein technisches Verstndnis gegeben
werden, warum das Applikationsverhalten keinen Fehler darstellt [14, S. 12].
Hierauf aufbauend hat nun dieser einen Review der Herstellerangaben durchzufhren. Sollten die Erkenntnisse des Herstellers durch den Entdecker besttigt werden, so
kann sich, falls tatschlich ein Fehler vorliegt, die Lsungsphase anschlieen. Wiederspricht jedoch der Einreicher dem Hersteller so hat dieser die seiner Meinung nach
fehlerhaften Aussagen zu kommentieren oder zu korrigieren. Der Hersteller muss
dann noch einmal eine Analyse auf Grundlage der neuen Erkenntnisse durchfhren.
Der Prozess beginnt von neuem [14, S. 13].
Zu guter Letzt ist der Einreicher auf die Einhaltung der Disclosure-Regelung hinzuweisen. Nach der Verffentlichung einer Korrektur knnen bei einem ResponsibleDisclosure die Informationen des Herstellers aus der Analysephase von diesem mitgenutzt werden. Sollte jedoch eine direkte Verffentlichung angestrebt werden, so ist
zumindest die Freigabe kritischer Informationen zu unterbinden [14, S. 13].
Lsungsphase.
Auf Grundlage des in der Analysephase ermittelten Fehlers muss der Entwickler eine
geeignete Lsung fr das Problem erarbeiten und diese implementieren. Durch den

18

Test wird anschlieend sichergestellt, dass die tatschliche Fehlerursache behoben

wurde [14, S. 13]. Der Prozess gliedert sich folgendermaen:
Abbildung 6. Lsungsimplementierung
(in Anlehnung an [14, S. 13])

[Konfigurationsnderung]

Hersteller
Untersuchung
Ursache / Fix

Hersteller
Erarbeitung
Workaround

Hersteller
Vorschlag Lsung /
Zeitplanung

Hersteller
Implementierung
Lsung

Einreicher
Prfung
Lsung

[Softwarefehler]

Im ersten Schritt wird durch eine detaillierte Fehleranalyse die Ursache der Sicherheitslcke, beispielsweise durch ein Review des Codes, ermittelt. Hufig macht es
Sinn die Ergebnisse auch hier dem Einreicher zu kommunizieren [14, S. 13].
Gerade bei modernen Applikationen kann die Ursachenanalyse ergeben, dass der
Fehler durch externe Bibliotheken oder Programmbestandteil (beispielsweise das
Java-Plug-In) verursacht wird. Neben der Tatsache, dass solche Schwachstellen von
Bug-Bounty-Programmen mglicherweise in den wie in Kapitel 3.1 dargestellten
Rahmenbedingungen ausgeschlossen werden knnen, ist trotzdem der Hersteller in
der Verantwortung, eine Lsung mit dem externen Softwareanbieter zu erarbeiten.
Der Einreicher muss darber informiert und ihm alle Informationen zur Weiterverfolgung des Fehlers beim Dritthersteller zur Verfgung gestellt werden. Die Kommunikation von Lsungen und Workarounds ist verpflichtend. Hier muss der Hersteller vor
allem Fingerspitzengefhl zeigen, um den Einreicher zufrieden zu stellen [14, S. 11].
Im zweiten Schritt kann optional untersucht werden, ob ein Workaround fr den
Fehler vorstellbar ist. Ein typisches Beispiel wre die Deaktivierung bestimmter
Funktionalitt im System oder die temporre Umkonfiguration zum Schutz der Anwendung. Gem OIS sollte ein Workaround aber nur im Ausnahmefall zum Einsatz
kommen. Je nach Schwierigkeit des Fehlers, der Auswirkung des Workarounds auf
das System sowie vor allem die Zeitdauer bis zur Implementierung einer Korrektur ist
eine Entscheidung diesbezglich zu treffen [14, S. 16].
Bei der darauf folgenden Umsetzung sind die Kritikalitt und das Risiko einer aktiven Ausnutzung bei der Steuerung relevant. Je bedeutender eine Sicherheitslcke
desto schneller soll eine Korrektur erfolgen. Weitere Kriterien wie die Qualitt der
Umsetzung, die vollstndige Lsungsbeseitigung und ein umfangreicher Test sind
jedoch in gleicher Weise zu bercksichtigen. Die Einplanung des Fixes fr bestimmte
Releaseversionen soll dem Einreicher vorgestellt werden. Parallel kann die Implementierung jedoch auch begonnen werden. Falls der Einreicher mit der Lsungszeit
nicht zufrieden ist, kann er dies begrndet darstellen. Wichtig ist deshalb die Komplexitt der Implementierung im Notfall darzustellen, jedoch wiederum Vorschlge
durch den Einreicher auch anzunehmen [14, S. 14f].
Ebenfalls muss entschieden werden, durch welchen Mechanismus die Korrektur
den Endanwendern bereitgestellt wird. Die Entscheidung ber das Deployment der
Lsung auf das Zielsystem muss jeweils abhngig vom Aufwand sowie der Kritikalitt des Fehlers stattfinden. Als Mechanismen stehen zur Verfgung [14, S. 14f]:

19

Patch: Lsung auerhalb des geplanten Releaseplan

Wartungsversion: Umsetzung im Rahmen eines geplanten Wartungsintervalls
Zuknftige Produktversion: Bereitstellung in einer zuknftigen Produktversion
Erst hierauf aufbauend kann dann der Fix implementiert und der Check-In gegen ein
Versionsverwaltungssystem stattfinden. In der Praxis wrde mit der Einspielung der
Korrektur und dem erfolgreichen Test der Applikation gleichzeitig auch die Belohnung verkndet und die Auszahlung gestartet werden. Fr die Auszahlung lassen sich
verschiedene Wege realisieren. Optional kann fr den Test auch der Entdecker bei
Interesse eingebunden werden. So kann eine berichtigte Softwareversion bereitgestellt
werden damit sich dieser von der vollumfnglichen Korrektur berzeugen kann.
Releasephase.
Nachdem eine geeignete Korrektur fr das Problem in der Lsungsphase erarbeitet
werden konnte muss eine Dokumentation fr die Verffentlichung erstellt werden.
Hierdurch knnen die Endanwender letztendlich auch ihr persnliches Risiko einschtzen und Manahmen zur Problembehebung ergreifen. Der Entdecker der
Schwachstelle kann bei Bedarf auch einen eigenstndigen Bericht erstellen. Die Verffentlichung des Fehlers soll abgestimmt geschehen. Je nach Kritikalitt soll dabei
die Publikation des Fehlerbildes zeitlich abgestuft erfolgen. Konkret sollen Informationen zur Erstellung eines Exploits vermieden oder zu einem spteren Zeitpunkt erst
verffentlicht werden [14, S. 17].
Abbildung 7. Release der Fehlerbehebung
(in Anlehnung an [14, S. 17])

Hersteller
Dokumenation
Fix

Einreicher
Optional: Erstellung
Advisory

Hersteller
Verffentlichung
Fix

Hersteller/Einreicher
Verffentlichung
Dokumentation

Hersteller/Entdecker
Erweiterte Informationsfreigabe

Hersteller
Entwicklung
Advisory

Wesentliche Herausforderung beim letzten Prozessschritt ist die abgestimmte Durchfhrung der Verffentlichung und Freigabe des Fixes. Die entsprechenden Informationen werden in einem Advisory zusammengefasst. Ziel eines solchen Advisories ist
es, ein Verstndnis fr die Sicherheitslcke, betroffene Produkte, Versionen und notwendige Schritte darzustellen, um den Fehler zu beheben. Inhaltich werden aber nur
relevante Informationen zur Risikoabschtzung und Korrektur des Anwendungssystems enthalten sein. Diese Informationen sind daher grundstzlich fr die ffentlichkeit bestimmt [14, S. 18].
Erst hierauf aufbauend wird der Hersteller den Fix verffentlichen. Anschlieend
knnen auch die erstellten Advisories den Anwendern zur Verfgung gestellt werden.
Wie in Kapitel 2.1 dargestellt muss dem Endanwender ein Zeitraum fr eine Einspielung des Fixes zugestanden werden. Deshalb soll auch hier wieder abgestimmt mit

20

dem Einreicher eine Frist vereinbart werden, bis eine Detailbeschreibung des Fehlers
publiziert wird. Danach knnen unabhngig Informationen, beispielsweise zur Ausnutzung der Lcke, ohne Risiko bekannt gegeben werden [14, S. 18].
Sollte eine gemeinsame Verffentlichung der Sicherheitslcke nicht stattfinden,
beispielsweise weil die Lcke bereits unter einer aktiven Ausnutzung steht oder der
Einreicher sich nicht ausreichend im Prozess eingebunden fhlt, so muss eine interne
automatische Eskalation erfolgen. Weitergehend sollte jedoch immer eine Warnung
durch die jeweilige Partei ber die bevorstehende Verffentlichung inklusive der
Beweggrnde sichergestellt werden. Parallel fhrt ein Vertragsbruch durch dem Einreicher implizit dazu, dass die Entlohnung nicht ausbezahlt wird [14, S. 19f].
3.3

Kosten von Bug-Bounty-Programmen

Betrachtet man die vorgestellten Einzelschritte zur Behebung einer Sicherheitslcke

mit der Community lsst sich feststellen, dass eine Reihe zustzlicher Aufgaben vom
Hersteller wahrgenommen werden mssen die bei einem reinen internen Test nicht
anfallen. Diese fhren zu nicht zu unterschtzende Kosten. So berechnet der Anbieter
Bugcrowd.com alleine fr das Managen der Einreichungen im Monat mindestens
4.000 Dollar [13], was einen ersten Anhaltspunkt fr die Kosten darstellt. Versucht
man diese Aufwnde, wie Rose es gemacht hat [8, S. 71], aufzugliedern lassen sich
fnf laufende Kostenpositionen unterteilen:
Abbildung 8. Mehraufwnde beim Entstrungsprozess durch Bug-Bounty
(eigene Darstellung)

Kosten

Analyse von
Einreichungen

Tracking

Bugfixing

Prmienauszahlung

Marketing

Die erste Aufgabe des Betreibers ist es, die Einreichungen der Community zu analysieren und auf Korrektheit zu prfen. Bei Programmen dieser Art ist eine Vorfilterung
durch Spezialisten zumeist obligatorisch. Ein zentrales Problem ist hier die Untergliederung in tatschliche Fehler und so genannten False-Positives, also eingereichte
Fehlerbilder, die gar keine Sicherheitslcke darstellen. Weitergehend kann je nach
Qualitt der Einreichung ein grerer Aufwand notwendig sein, um die Reproduzierbarkeit sicherzustellen. Darber hinaus bedarf es Experten, welche die Kritikalitt von
Fehler erkennen und Auswirkungen systematisch beurteilen knnen.
Nach der Besttigung einer Sicherheitslcke ist es beim Tracking des Applikationsfehlers notwendig eine interne Dokumentation des Fehlerbearbeitungsprozesses
durchzufhren. Hierauf aufbauend entsteht bei Bug-Bounty-Programmen ein zustzlicher Bedarf in der Koordination sowie Kommunikation mit dem Entdecker der Sicherheitslcke. Dieser ist ber dem Fortschritt sowie neue Erkenntnissen auf dem
Laufenden zu halten und Feedback muss in die Bearbeitung des Issues einflieen.
Die Entwicklung und Livesetzung von Korrekturen geschieht wie im traditionellen
Bug-Fixing auch. Es mssen fr die Bearbeitung in ausreichenden Umfang geeignete
Ressourcen zur Verfgung stehen um im festgelegten Zeitrahmen Patches zu entwickeln. Im Vergleich zu traditionellen Tests der Applikationssicherheit ist die Anzahl

21

der Fehler vor allem zu Beginn nicht vollstndig abschtzbar und Bedarf daher auch
ein Vorhalten geeigneter Ressourcen fr den Notfall.
Erst nach diesen Aufwnden sind als Kernelement von Bug-Bounty-Programmen
die Bounties selbst zu betrachten. Dies kann je nach Hhe der ausgeschriebenen Entlohnungen einen wesentlichen Kostenfaktor darstellen. Gebhren sowie Verwaltungsaufwand fr die Auszahlung von Prmien, beispielsweise in fremde Lnder, mssen
ebenfalls einbezogen werden. Abhngig vom Herkunftsland der einreichenden Person
knnen der Aufwand sowie die Gebhr fr die bermittlung hoch sein. Zustzlich
Marketingaufwnde sind zu bercksichtigen, um einmal Sicherheitsforscher zu gewinnen und diese auch effektiv ansprechen zu knnen.
Wichtig ist bei der Betrachtung der Aufwnde jedoch auch immer festzuhalten,
dass zumeist Fehler behandelt werden, die Software betrifft, die sich im Betrieb befindet. Boehm beschreibt hierbei, dass die Behebung solcher Fehler um einen wesentlichen Faktor teurer ist als die Korrektur dieser vor der eigentlichen Produktivsetzung
[19]. Insofern kann bereits durch dieses Argument die von Rose ausgefhrte Behauptung, dass traditionelles Testen tot sei [8, S. 6], nicht gefolgt werden. Letztendlich
drfen aus Kostensicht Bug-Bounty-Programme damit kein systematisches Testmanagement ablsen, sondern stellen einen Kanal fr den in Kapitel 3.4 dargestellten
Vulnerability-Management-Prozess dar. Zustzlich kann bei der Wirtschaftlichkeitsbetrachtung die von Finifter et al. durchgefhrte Bewertung von Bug-BountyProgrammen im Vergleich zu traditionellen Testmechanismen anhand der Prmienauszahlung [4] nur eine grobe Indikation darstellen. Die Beschrnkung der Kostenbetrachtung auf die reine Auszahlung erlaubt keinen vollstndigen Kostenberblick.
Geht man weitergehend davon aus, dass mit Hilfe von Bug-Bounty-Programmen
systematisch ein mehr an Sicherheit erreicht wird, ist davon auszugehen, dass die
Kosten bei der Durchfhrung eines solchen Programms ber den Zeitraum steigen
werden um die Effektivitt selbst zu halten. Jones stellt hier heraus: As quality improves, cost per defect gets higher until zero defects are encountered, where the cost
per defect metric goes to infinity [46, S. 1]. Diese Kostenentwicklung lsst sich auch
bei dem in Kapitel 4 dargestellten Chromium-Programm nachvollziehen [47].
3.4

Neuaufsetzung eines Programmes

Beim Neuaufsetzen eines Programmes gibt es eine Reihe von Vorbehalte, die Unternehmen vor einer Einfhrung abschrecken lassen [8, S. 46ff]:
Keine ausreichendes Feedback durch die Community
Zu hohe Kosten bei der Durchfhrung
Konflikte und Streit mit der Entwicklergemeinschaft
Diese Vorbehalte sind durchaus berechtigt, knnen durch eine strukturierte Planung
im Vorlauf zur Verffentlichung eines eigenen Programmes begegnet werden.
Eine wesentliche Idee bei der Einfhrung eines Bug-Bounty-Programms ist es daher mglichst klein anzufangen. Hierfr kann es sinnvoll sein anstelle der Auslobung
umfangreicher Gewinne zuerst eine reine Disclosure-Policy auf der Webseite zu
schalten. Ziel soll es sein, vereinzelte Bugs und das Feedback von Einreichern abzuwarten [30]. Dies wiederum ermglicht, den in Kapitel 3.2 dargestellten Prozess zu

22

testen und Prozessmetriken zu ermitteln. Der Aufwand zur Koordination mit dem
externen Sicherheitsforscher ist dabei nicht zu unterschtzen. Denn die grte Gefahr,
die von einer fehlerhaften Einfhrung ausgeht ist, dass zur Behebung der Fehler nicht
ausreichende oder nicht korrekte Ressourcen zur Verfgung stehen [30].
Zustzlich muss bei der Aufsetzung bercksichtigt werden, dass die Softwareentwickler sowie die Teamleiter in die Aufsetzung mit einbezogen werden. Mit der Einfhrung ist nahezu immer ein Kulturwandel notwendig. Anstelle dem Verschweigen
von Fehlern in Produktionssystemen soll positiv und transparent mit Einreichungen
umgegangen und die Zusammenarbeit mit externen Personen verbessert werden [30].
Eine wesentliche Voraussetzung ist weitergehend, dass in der eigenen Software ein
Mindestma an Sicherheit realisiert ist. Dies bedeutet beispielsweise, dass ein auf
Sicherheit optimierter Entwicklungsprozess existiert. Weitergehend muss es fr die
Fehlerbehebung einen klar definierten Prozess geben und die Entwickler in der Lage
sein, auch komplexe Fehler zu beseitigen. Erst dies ermglicht dann auch eine Einschtzung der Anzahl und Schwere der Einreichungen [8, S. 32f].
Um den Start zu begleiten und auf das eigene Bug-Bounty-Programm aufmerksam
zu machen kann Marketing untersttzen. Durch Aufnahme in die unterschiedlichen
bersichtslisten im Internet, beispielsweise auf Bugcrowd.com, wird das Programm
direkt einer Vielzahl an Hackern bekannt. Ein Auftreten auf Sicherheitskonferenzen
kann ebenfalls untersttzend wirken.
Ein wesentlicher Punkt bei der Entwicklung des Programms ist es dann, systematisch aus dem Feedback der Community zu lernen und das Programm entsprechend
dem Wnschen anzupassen. Dies ist ein stndiger Prozess der zwingend notwendig
ist, um die Entwicklercommunity eine Flexibilitt zu bieten. So hat beispielsweise
Facebook auf vermehrte Einreichungen auerhalb der Domne facebook.com mit
einer Ausweitung der allgemeinen Rahmenbedingungen auf weitere Applikationsbestandteile reagiert [30]. Weitergehend sollen Erfolge ffentlich dargestellt werden und
damit auch Werbung fr die Arbeit mit der Community gemacht werden.

Chromiums Bug-Bounty-Programm

4.1

Detaillierte Vorstellung des Programms

Das von Google im Januar 2010 [31, S. 1] aufgelegte Chromium Vulnerability Reward Program wird sowohl von der Praxis wie auch der Literatur als ein Beispiel fr
ein gut aufgesetztes aber auch reifes Bug-Bounty-Programm wahrgenommen [4, S.
2]. Es wurde fr eine detaillierte Analyse fr diese Projektarbeit ausgewhlt, da die
Bugtrackingdatenbank des Chromium-Projekts zur Auswertung im Internet frei zur
Verfgung steht und mit 622 besttigten Einreichungen [48] eine ausreichende Datenbasis fr eine zuverlssige Analyse ermglicht. Weitergehend sind alle Kriterien
und Prozesse des Programms gut dokumentiert. Dies erlaubt die in Kapitel drei dargestellten Rahmenfaktoren in einem echten lebenden Projekt darzustellen.
Inhaltlich zielt das von Google aufgelegte Vulnerability-Reward-Programm auf das
Chromium-Projekt sowie den daraus abgeleiteten Endkundenprodukten Chrome sowie das Betriebssysteme Chrome OS ab [31, S. 1]. Gefundene Fehler in diesen Produkten sowie in direkt von Google integrierten Plug-Ins ermglichen eine Teilnahme.

23

Typische integrale Bestandteile sind hier das PDF- oder auch das Flash-Plug-In. Nicht
berechtigt sind Fehler, die in von Chromium verwendeten Drittbibliotheken wie beispielsweise bzip2 oder libxslt gefunden werden oder durch Erweiterungen von
Drittherstellern entstanden sind [31, S. 1].
Die Schwere der vom Sicherheitsforscher gefundenen Sicherheitslcke spielt eine
entscheidende Bedeutung sowohl bei der Entlohnung wie auch dann bei der Beseitigung von Fehlern im Softwareprodukt. Eine ausfhrliche Dokumentation der Priorisierung steht zur Verfgung [33] und ermglicht damit eine objektiv nachvollziehbare
Festsetzung des Entlohnungsbetrags. Konkret unterteilt Google vier Stufen:
Tabelle 2. Bounties des Chromium VRP
(in Anlehnunug an [33] sowie [47])

Schwere
1 Critical
Severity

Beschreibung / Beispiel
Ermglicht die Ausfhrung von externem Code im
Benutzerkontext. Dabei kann die Ausfhrung whrend des normalen Browsens passieren. Ein typisches Beispiel ist ein unkontrollierter Buffer Overflow, bei dem der Angreifer den Inhalt des Speichers direkt beeinflussen kann.

Bounty
> $5.000

2 High
Severity

Ein Angreifer kann vertrauliche Daten des Anwenders lesen oder bearbeiten. Typisches Beispiel sind
Fehler, die dazu fhren, dass gegen die SameOrigin-Policy verstoen wird.

$5.000

3 Medium
Severity

Ermglicht das Auslesen einer begrenzten Anzahl

an Informationen. Typisches Beispiel ist das Auslesen der zuletzt besuchten Webseite. Ebenfalls sind
hochpriore Fehlerbilder, die aber nur sehr schwer
zu nutzen sind, hier eingeordnet.

$3.000

4 Low
Severity

Browser-Features, die nicht zwingend bentigt

werden, knnen von Angreifern temporr bernommen werden. Beispielsweise wrde ein Angreifer den Browser durch eine Sicherheitslcke zum
Absturz bringen knnen.

$1.000

Bei der Einfhrung von Googles Bug-Bounty-Programm wurden zu Beginn Vergtungen von 500 Dollar fr Einreichungen mit einem hohen beziehungsweie kritischen Risiko bezahlt [33]. Diese durchschnittlichen Betrge wurden jedoch seit der
Einfhrung gesteigert. Zuletzt erfolgte im August 2013 eine Anhebung der Auszahlungen um den Faktor fnf [47]. Aufbauend auf diesem Preismodell werden fr besonders innovative und bedeutende Sicherheitslcken explizit keine Schranken nach
oben vorgegeben. Diese Regelung fhrte in Einzelfllen zu Auszahlung von bis zu
21.500 Dollar (vergleiche [49] Bug 252010).
Als besonderes Element sind darber hinaus so genannte Reward-Modifiers zu sehen [33]. Hierunter werden Bonizahlungen verstanden, die an dem Sicherheitsforscher fr besondere Bemhungen und eine gute Zusammenarbeit extra ausbezahlt

24

werden. Dabei knnen 500 1.000 Dollar vergtet werden, falls von dem Entwickler
gleichzeitig ein Patch in das Open-Source-Projekt Chromium eingesteuert wird. Auch
das Erstellen eines Exploits fr eine Sicherheitslcke wird mit bis zu $4.000 honoriert. Zustzlich zur monetren Entlohnung wird eine Hall-of-Fame gefhrt, in welcher die Teilnehmer des Programms aufgezhlt werden [33].
Auf Grund des Erfolgs des existierenden Chrome-VRP hat sich Google im Jahr
2013 ebenfalls entschieden, fr die bestehenden Webapplikationen wie Google Plus,
Google Mail aber auch der Google Suchmaschine ein Bug-Bounty-Programm einzurichten (vergleiche hierzu [39]). Auerdem gibt es von Google Kooperationen mit
dem Ziel fr das Internet wichtige Open-Source-Projekte ebenfalls durch ein BugBounty-Programm zu untersttzen (vergleiche hierzu [50]). Beide Anstze sind jedoch explizit nicht Gegenstand des Chromium-Vulnerability-Reward-Programms und
damit nicht Grundlage der vorliegenden Betrachtung.
4.2

Prozess der Bearbeitung der Einreichungen

Sowohl
der
Quellcode
wie
auch
die
Bugdatenbank
sind
unter
https://code.google.com/p/chromium von der Allgemeinheit einsehbar. Fr die Erfassung von Fehler im Produkt kann jeder im Issue-Tracker eigenstndig Bugs erfassen.
Dieser ist als ein dreistufiger Wizard realisiert.
Abbildung 9. Erfassungsmaske Einreichungen Chromium VRP
(eigene Darstellung)

25

Zu Beginn sind produktabhngigen Daten wie Browserversion oder verwendetes Betriebssystem anzugeben. Im zweiten Schritt ist die Art des Fehlers zu bestimmen. Fr
die Ausarbeitung interessant ist nur die Fehlerkategorie IT-Security. Im abschlieenden Dritten Schritt sind hierauf aufbauend alle Daten zu erfassen, die fr die Reproduzierbarkeit des Fehlerbildes bentigt werden. Eine Vorlage, die alle relevanten
Daten abfragt, steht ebenfalls wie in Abbildung 9 dargestellt bereit.
So gettigte Einreichungen knnen zunchst von der Allgemeinheit nicht eingesehen werden, sondern sind initial nur vom Ersteller sowie einem so genannten Security-Sheriff sichtbar [51]. Mit der Einreichung stimmt der Sicherheitsforscher ebenfalls
einem Responsible-Disclosure zu. Auf der anderen Seite verpflichtet sich Google
explizit Fixes fr kritische Sicherheitslcken innerhalb von 30 und die Verffentlichung innerhalb von 60 Tagen durchzufhren. Bei einer aktiven Ausnutzung des Fehlers werden hingegen sieben Tage vorgegeben [52]. Fr alle Nicht-Kritischen Fehlerbilder wird keine festgelegte Frist definiert, jedoch weit Google auf eine angestrebte
Bearbeitungszeit von etwa 30 Tage bis zur Korrektur hin [52].
Die Stelle des Security-Scheriffs wird im wchentlichen Rhythmus bestimmt. Sie
zeigt sich verantwortlich eingehende Fehlerberichte zu bearbeiten sowie die EMailpostfcher zu beantworten. Weitergehend bernimmt diese Person die Aufgabe
den Fortschritt bei der Bearbeitung von offenen Bugs nachzuverfolgen und im Notfall
zu eskalieren. Zustzlich bernehmen sie die korrekte Einordnung in Sicherheitsklassen sowie das Tagging der Einreichungen [51]. Die Person wird aus dem existierenden Bugfixing-Team bestimmt und hat dadurch fundamentale Kenntnisse ber die
Sicherheitsarchitektur [51]. Damit stellt sie den in Kapitel 3.2 geforderten SinglePoint fr die Kontaktaufnahme dar und tritt im Prozess als Koordinator auf.
Ein so eingereichter VSR wird nun im ersten Schritt vom Security-Scheriff analysiert. Dies beinhaltet, dass der Fehler auf mgliche Duplikate untersucht sowie die
Reproduzierbarkeit geprft wird. Zur Bewertung der Kritikalitt entsprechend der
oben vorgestellten Tabelle stehen klare Vergaberegeln zur Verfgung [51]. Auf die
Analyse aufbauend wird ein Entwickler dem eingereichten Bug zugeordnet, der das
notwendige Fachwissen fr die Bearbeitung des Problems besitzt. Er bernimmt die
Ursachenanalyse fr den Fehler und entwickelt einen Fix. Die Kommunikation mit
dem Entdecker luft zentral ber das Bug-Tracking-Tool ab, der externe Einreicher
hat hierzu Bearbeitungsrechte. Zu guter Letzt wird die Korrektur durch eine Qualittssicherung, meistens in Form von automatisierten Tests, geprft [51]. Dieser Schritt
wird dabei als kritischer Punkt im Prozess wahrgenommen, so dass hier durch das
eingesetzte Tool Clusterfuzz ein Repository von 10.000 automatisierten Testflle zur
Qualittssicherung zur Verfgung steht [21, S. 5].
Nach Implementierung eines Fixes muss sich abschlieend wiederum der SecurityScheriff darum kmmern, diesen in Abstimmung mit dem Releasemanagement fr
alle betroffenen Softwareversionen bereitzustellen [51]. Je nach Schwierigkeit des
Softwarefehlers wird eine Implementierung fr eine zuknftige Version oder aber ein
Patch vorgesehen. Interessant ist dabei festzustellen, dass Google fr den Benutzer
transparent und automatisiert eigenstndig Patches weltweit auf Endgerten einspielen kann. Dies erlaubt wie Reis et al. darstellt eine Aktualisierung von 75 Prozent der
Installationen innerhalb von fnf Tagen nach Freigabe [21, S. 6].
Ebenfalls nach erfolgreicher Korrektur wird der Fehler einer internen Jury vorgelegt, wo die einzelnen Einreichungen besprochen und die Entlohnung angewiesen

26

wird. Fr die Auszahlung der Geldbetrge beschreibt Google selbst keinen konkreten
Weg. Je nach Vereinbarung und Land wird diese unterschiedlich ausgefhrt. Prferiert wird jedoch eine berweisung ber AdWords oder Google Wallet [30]. Wichtig
ist, dass Google nach Produktivsetzung des Bugfixes ber einen automatisierten Lauf
zeitversetzt einen vollstndigen Disclosure durch Freigabe des Issues in der Bugtrackingdatenbank durchfhrt.
4.3

Vorgehensweise bei der Datenerhebung

Fr die vorliegende Projektarbeit wurden alle sicherheitsbezogenen Bugdaten am

21.03.2014 im offiziellen Chrome-Bugtracking-System exportiert. Fr die Erhebung
wurden basierend auf den Richtlinien zur korrekten Kategorisierung (vergleiche hierzu [53]) alle vorhandenen Datenstze selektiert, die eine Sicherheitsrelevanz aufweisen. Die Suche kann entsprechend ber die Anfrage type:Bug-Security OR
has:security_severity durchgefhrt werden.
Abbildung 3. Screenshot Google Issue-Datenbank
(in Anlehnung an [14, S. 3])

Zustzlich zu den oben genannten Einschrnkungen wurden Daten aus dem Pwnium
beziehungsweie den Pwn2Own-Programm entfernt, da durch die im Vergleich hohen Auszahlungen und die Anlegung als Wettbewerb eine Vergleichbarkeit nicht
gegeben ist. Weitergehend wurden Issues auf dem Zeitraum vom 01.01.2010 bis heute, also der tatschlichen Laufzeit des Programms, eingeschrnkt.
Die Datenaufbereitung wurde zweistufig durchgefhrt. Auf der einen Seite wurde
die Exportfunktion genutzt um relevanten Kopfdaten zu erhalten. Nicht auf diese
Weise extrahierbar waren Verlaufsdaten. Diese sollten jedoch explizit fr eine erweiterte Auswertung von Issues aus dem Bug-Bounty-Programm genutzt werden. Zu
diesem Zweck wurde aufbauend auf der nicht mehr untersttzten, aber noch zum
Zeitpunkt der Erstellung dieses Dokumentes funktionsfhigen, Google Issue-TrackerAPI aufgesetzt, um XML-Dokumente zu generieren und diese ber ein VBA-Skript
auszuwerten. Eine detaillierte Beschreibung sowie der Quellcode kann im Anhang
nachvollzogen werden. Ebenfalls nicht ber den Issue-Tracker extrahierbar waren die
konkreten Informationen zum Releasezeitpunkt der Bugs. Hierfr wurden aus dem
Chrome-Release-Notes, erreichbar unter http://googlechromereleases.blogspot.de/,
die jeweilige Version sowie das Releasedatum extrahiert.

27

Die Datenqualitt ist fr die Aussagekraft der anbei dargestellten Auswertungen

entscheidend. So weit Finifter et al. darauf hin, dass Google die Korrektheit der im
Issue-Tracker vorhandenen Daten grundstzlich besttigt [4, S. 4]. Jedoch konnte vor
allem bei der Zusammenstellung der Daten Unstimmigkeiten festgestellt werden. Dies
betrifft vor allem die einheitliche und vollstndige Erfassung aller sicherheitsrelevanten Merkmale und dem konkreten Einsatz von einzelnen Labels. Kritisch werden vor
allem folgende Felder fr die Richtigkeit der Auswertungen gesehen:
Typ: Da als Selektionskriterium genutzt, wird vorausgesetzt, dass der Feldwert
entsprechend der Vorgabe korrekt gesetzt wurde. Fehler in diesem Feld wrden im
Problemfall dazu fhren, dass einzelne Bugs nicht erkannt werden.
Status: Es werden alleinig Endzustnde betrachtet. Konkret sind diese Duplicate,
WontFix, Fixed, Invalid oder Verified. Es wird erwartet, dass die Endzustnde korrekt gesetzt und damit eine Auswertbarkeit gegeben ist.
Reporter: Als Ersteller wird im Bug-Tracker diejenige Person aufgefasst, die den
Bericht erfasst hat. Dies kann vom tatschlichen Einreicher abweichen, beispielsweise wenn der Fehler ber E-Mail in das System kam. Fr mit Bounties prmierte
Fehler wurden daher die Einreichungen einzeln manuell ausgewertet und im Bedarfsfall korrigiert.
Security_severity: Zuordnung der korrekten Kritikalitt entsprechend der Schwere
und Auswirkung der gefundenen Schwachstelle.
M: Die konkret betroffene Produktversion, in welcher der Bug gefixed wurde.
Bugs sollten in den entsprechenden Releasenotes auch genannt sein. Sollten die
Releasenotes nicht vollstndig sein ist dies fr die Ermittlung des Releasedatums
problematisch.
Teilweise konnte festgestellt werden, dass die Bugdaten nicht korrekt oder widersprchlich waren. Fr die mit Prmien ausgezeichneten Eintrge wurde daher eine
Prfung der Informationen mit dem Verlauf innerhalb des Issue-Trackers durchgefhrt und Fehler manuell aufgelst.
4.4

Auswertung und Ergebnisse

Bei der Analyse der zugrundeliegenden Daten knnen zwei verschiedene Sichtweisen
eingenommen werden. Dies sind einmal die Rolle des Softwareanbieters sowie die
des Einreichers. Hierauf aufbauend lassen sich wie auch Finifter et al. beschreibt zentrale Informationsbedrfnisse ermitteln [4, S. 5]. Entsprechend den Einzelaspekten
eines Programms soll daher auch das vorliegende Kapitel aufgeteilt werden.
Anzahl und Struktur der Einreichungen.
Bei einer Laufzeit von fast vier Jahren konnte Google bereits 621 Bounties auszahlen.
Insgesamt wurden von Nicht-Projektmitgliedern im Rahmen des Programms 2.795
sicherheitsbezogene Einreichungen gettigt. Bezogen auf die insgesamt 5.473 Eintrge im Issue-Tracker kann daraus geschlussfolgert werden, dass etwa 51 Prozent der
relevanten Bugs durch externe Sicherheitsforscher eingestellt werden. Bereits anhand
dieser Zahl kann die Bedeutung der Einbindung der Community in das Sicherheits-

28

management des Chromium-Projekts sehr gut erkannt werden. Google ist es gelungen
eine sehr aktive Gemeinschaft an Entwicklern zu erreichen.
Betrachtet man weitergehend die Anzahl der Einreichungen pro Jahr ist festzustellen, dass 2010 638, 2011 705, 2012 759 sowie 2013 645 Einreichungen gettigt wurden. Da die Daten von 2013 aufgrund von Disclosure-Funktionen noch nicht vollstndig fr die Auswertung zur Verfgung stehen kann dieses bei der Trendbewertung
nicht bercksichtigt werden. Daher kann insgesamt festgestellt werden, dass pro Jahr
eine steigende Anzahl an Einreichungen, im Durschnitt 8 Prozent, erreicht wird. Analysiert man nun den Inhalt der Einreichungen knnen folgende Diagramme genutzt
werden:
Diagramm 1. Anzahl der besttigten
(Verified oder Fixed) Fehler im Zeitverlauf

Diagramm 2. Anteil der False-Positives

bei externen Einreichungen
1200

70
60

1000

50
40

800

30
20

600

10

400
Jan
Mrz
Mai
Jul
Sep
Nov
Jan
Mrz
Mai
Jul
Sep
Nov
Jan
Mrz
Mai
Jul
Sep
Nov
Jan
Mrz
Mai
Jul

2010
Critical

2011
High

2012
Medium

2013
Low

200
0
Fixed

Verified Duplicate

Invalid

WontFix

Wie man in der Abbildung links sehr gut erkennen kann sind die meisten Fehler tatschlich von Google mit der Kritikalitt Hoch bewertet. Besonders im Zeitraum 2011
bis Mitte 2012 haben als High bewertete Fehler mehr als 50 Prozent aller sicherheitsrelevanten Probleme ausgemacht. Bei der Betrachtung der vollstndigen Zahlen lsst
sich hier ein Abwrtstrend feststellen so dass beispielsweise im Juni 2013 nur 23 Einreichungen in dieser Kategorie tatschlich gettigt wurden. Die Anzahl an Medium
und Low-bewerteten Fehler hlt sich ber die Laufzeit relativ die Waage und nimmt
ebenfalls einen nicht unbedeutenden Anteil der Einreichungen ein. Ab dem Jahr 2012
lsst sich jedoch ein wesentlicher Anstieg zu Gunsten von als Medium bewertete
Tickets beobachten, die sich langsam den Summen der hochprioren Tickets annhern.
Die Anzahl an kritischen Fehler hlt sich konstant bei einem relativ geringen Anteil
von etwa drei Prozent.
Interessant wird hier vor allem auch die von Google im August 2013 angekndigte
Steigerung der Prmien um das bis zu Fnf-Fache des ursprnglich ausgezahlten Betrags [47]. An dieser Stelle aber kann abgeleitet werden, dass noch keine direkte
Auswirkung an der Entwicklung der Einreichungen feststellbar ist. Es kann vermutet
werden, dass Google damit die Suche nach hochprioren Problemen frdern will.
Betrachtet man die Einreichungen von Externen entsprechend der Qualitt ist festzustellen, dass von den 2.795 externen Einreichungen tatschlich nur 1.001 Beitrge,
dies entspricht 36 Prozent, besttigt wurden. Etwas weniger als 600 Beitrge mussten
als Dublette geschlossen werden, die restlichen konnten nicht reproduziert werden
oder sind invalid. Da der Zugang zur Einstellung von Bugs ja jeden mglich ist, sind
auch eine bestimmte Anzahl an Testanfragen vorhanden. Damit kann insgesamt festgestellt werden, dass ein grerer Aufwand in die Verifizierung von Einreichungen

29

gesteckt werden muss. Eine schnelle und zuverlssige Bearbeitung ist damit zwangsweise notwendig. Sehr viele Einreichungen knnen durch den Security-Scheriff direkt
geschlossen werden ohne dass tatschlich die Entwicklung aktiv werden muss.
Auszahlungen.
Eine vollstndige Betrachtung der in Kapitel 3.3 dargestellten Kosten ist mangels
ffentlichen Zugangs zu den internen Aufwnden bei der Analyse sowie Korrektur
der Einreichungen nicht mglich. Daher werden alleinig die Prmienauszahlungen
betrachtet. Diese knnen aus dem Bugtracker ermittelt werden. Insgesamt ist festzustellen, dass ber einen Zeitraum von vier Jahren $744.680 ausbezahlt wurden. Anhand des Erffnungsdatums aufgeteilt ergeben sich folgende Ausschttungen:
Tabelle 4. Auszahlungen des Chromium VRP pro Jahr

Jahr
2010
2011
2012
2013

Vorgnge
100
218
197
105

Summe Auszahlungen
$ 82.033,00
$ 240.035,00
$ 276.803,00
$ 144.809,00

Durchschnitt Auszahlungen
$ 820,33
$ 1.101,08
$ 1.405,09
$ 1.379,13

Wie aus der Tabelle entnommen werden kann weist das Jahr 2011 einen wesentlichen
Anstieg sowohl an Auszahlungsvorgngen wie auch im Auszahlungsvolumen selbst
auf. Wurden im Jahr 2010 durchschnittlich etwa 820,33 Dollar pro Bug bezahlt erhhte sich diese Zahl im Jahr 2011 auf 1.101,08 Dollar. Dies entspricht einer Steigerung um 34 Prozent. Auch im Jahr 2012 wurden noch einmal um etwa 27 Prozent die
Auszahlungen auf durchschnittlich 1.405,09 Dollar erhht. Die jeweiligen Erhhungen spiegeln relativ gut die im Zeitverlauf stattgefundenen systematischen Erhhungen der Prmienauszahlungen wieder. Da wie bereits beschrieben eine vollstndige
Erfassung der Daten des Jahres 2013 noch nicht mglich ist, kann hier noch keine
Entwicklung abgelesen werden.
Betrachtet man die einzelnen Bounties im Detail ist feststellbar, dass 500 beziehungsweie 1.000 Dollar bei 515 von 621 Einreichungen ausbezahlt werden. Nur in
siebzehn Prozent der Flle werden hhere Betrge vergtet. Beitrge ber $10.000
kommen gar nur zu einem Prozent vor. Durch relativ niedrige Auszahlungsbetrge
pro Einreichungen und der grundstzlichen Chance, sehr hohe Gewinne zu realisieren, wird eine Art Lotterieeffekt genutzt. Alleine die Aussicht auf hohe Prmienauszahlungen steigert die Attraktivitt fr Sicherheitsforscher weiter [4, S. 9]. Der hchste ausbezahlte Betrag war $21.500.
Basierend auf den oben dargestellten Auswertungen lsst sich zustzlich feststellen, dass pro Tag Google etwa $510 an Auszahlungen fr das Programm bereithlt.
Bringt man dies wie es Finifter gemacht hat [4, S. 8] in Relation zu den Kosten eines
festangestellten Mitarbeiters, lsst sich sehr gut erahnen, dass das Bug-BountyProgramm sehr rentabel betrieben wird. Ebenfalls werden pro Ticket im Durchschnitt
$1.173 bezahlt. Hierbei gestaltet es sich so, dass kritische Tickets im Mittel $2.048
erbracht haben, whrend hochpriore Tickets nur $1.128 erzielten.

30

Diagramm 3. Auszahlungen pro Monat

abhngig vom Releasestand

Diagramm 4. Anteil der Auszahlungen abhngig

der Kritikalitt der Einreichungen

70000

100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%

60000
50000
40000
30000
20000
10000
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt
Jan
Apr
Jul
Okt

(Leer)
Qrtl1
Qrtl2
Qrtl3
Qrtl4
Qrtl1
Qrtl2
Qrtl3
Qrtl4
Qrtl1
Qrtl2
Qrtl3
Qrtl4
Qrtl1
Qrtl2
Qrtl3
Qrtl4

2010

2011

2012

Stable

2013

<22.01.20102010

Gesamt

None

2011

Critical

2012

High

2013

Medium

Low

Das besondere am Bug-Bounty-Programm, wie dargestellt, ist, dass Einreichungen

sowohl fr Stabile wie auch Nicht-Stabile Releases erlaubt werden. Bei der Bewertung dieses Umstandes kann wie in Diagramm 3 dargestellt festgestellt werden, dass
ein groer Anteil der Auszahlungssumme tatschlich dem stabilen Release zufliet.
Etwa 25 Prozent, dass entspricht 190.472 Dollar, aller Finanzmittel werden aktuell fr
Bounties verwendet, die Nicht-Stabile Release-Versionen betreffen.
Ebenfalls von groem Interesse ist, wie viel der Summe fr die Schwierigkeit eines
Fehlers jeweils eingestellt wird. Hier kann ermittelt werden, dass ein sehr groer Anteil der Gesamtsumme fr hochpriore Tickets ausbezahlt wird und nur relativ geringe
Anteile an die sonstigen Tickets vergeben werden. Konkret sind etwa 73 Prozent aller
Auszahlungen fr hochpriore Tickets bestimmt.
Einbeziehung der Community.
Bei der Einbeziehung der Community ist zu untersuchen, in welchen Mae Sicherheitsforscher erreicht werden knnen. Ziel ist eine Diversifizierung der Personen um
mglichst viele und unterschiedliche Fehlerberichte zu erhalten [4, S. 7]. Insgesamt
konnte Google bis zum jetzigen Zeitpunkt 113 externe Einzelpersonen erreichen.
Basierend auf den Daten lassen sich folgende Kennzahlen ermitteln:
Tabelle 5. Einreichungen pro Person

# Einreichungen

11

13

14

>18

# Einreicher

79

10

Es kann festgestellt werden, dass dabei die groe Anzahl der Einreicher (etwa 70
Prozent) nur eine einzige Schwachstelle melden werden. Sie leisten mit 12 Prozent
der Einreichungen auf der anderen Seite jedoch nur einen geringen Beitrag zum Programm. Interessant ist nun die Feststellung, dass die aktivsten fnf Einreicher fr
etwa 53 Prozent aller Beitrge verantwortlich sind. Damit lsst sich in Anlehnung an
das Pareto-Prinzip auch hier die Feststellung treffen, dass eine kleine Anzahl an Entwickler wesentlich zum Erfolg des Programms beitragen. Google nutzt diesen Fakt

31

und versucht nun besonders zu diesen ein besonderes Verhltnis aufzubauen. Dies ist
beispielsweise im Jahr 2012 durch die Auszahlung von $10.000 an die drei besten
Untersttzern geschehen (siehe Issues 116661 bis 116663). Zustzlich wird mit dem
Pwn2Own ein Event untersttzt, bei dem zustzliche Entlohnungen ausbezahlt werden. Diese eventbasierte Vorgehensweise dient weitergehend zum Austausch mit der
Community in der realen Welt. Ziel dieser Manahmen ist es, einen festen Kreis an
externen Sicherheitsforscher zu gewinnen, und diese aktiv einzubinden. Beachtet man
weitergehend das 50 Prozent aller Auszahlungen an feste fnf Personen flieen kann
festgestellt werden das Bug-Bounty-Programme im Umkehrschluss fr diesen Teilnehmerkreis als lukrative Beschftigung angesehen werden kann.
Prozessdurchlauf.
Fr die Bewertung des Prozesses stellen die Durchlaufzeiten ein wesentliches Kriterium zur Beurteilung der Qualitt eines Bug-Bounty-Programms dar. Deshalb wurde
dem als CSV exportierten Kopfdaten fr alle Bounties Verlaufsdaten hinzugefgt um
auf den Prozess rckschlieen zu knnen. Diese wurden wie in Kapitel 4.3 dargestellt
aus unterschiedlichen Datenquellen generiert. Folgende Zeitpunkte wurden ermittelt:
Erffnung: Zeitpunkt der Erfassung des Issues ber die Bugdatenbank crbug.com.
Direkt auslesbar ber das CSV-Datenformat.
1. Response: Erste Antwort eines Teammitglieds des Chromium-Projekts nach
einer Einreichung. Falls das Issue bereist von Projektmitgliedern angelegt wurde
entspricht die Erffnungszeit dem ersten Response.
Bewertung: Zeitpunkt der Bewertung des Tickets bezglich Kritikalitt sowie der
betroffenen Versionen.
Fixed: Datumswert, zu dem vom Sachbearbeiter ein Fix eingestellt wurde und
damit der Status des Issues auf Fixed oder FixUnreleased gesetzt wurde.
Release: Termin, zu dem in dem Release-Notes der Fix in einem Endkundenprodukt genannt wurde.
Auf Grundlage der so ermittelten Daten lassen sich nun umfangreiche Auswertungen
zur Beschreibung des Prozesses durchfhren.
Diagramm 5. Durschnittliche Ticketbehebung inkl.
Standardabweichung

Diagramm 6. Bearbeitungszeit pro Prozessphase

100
90
80
70
60
50
40
30
20
10

0,00

10,00

20,00

30,00

40,00

50,00

0
Critical

High

Medium

Low

Benachrichtigung

Analyse

Lsung

Release

32

Die Entwicklung des Chrome-Projekt setzt auf einem agilen Entwicklungsprozess

auf. Dies bedeutet dass zwischen den einzelnen Releases in etwa vier bis sechs Wochen liegen und anschlieend bereits eine neue Endkundenversion ausgerollt wird.
Zwischen den einzelnen Releases wiederum knnen zustzliche Patches stattfinden.
Dieses Vorgehen zeigt sich dann auch sehr gut in dem ersten Chart. Generell dauert es im Durchschnitt 44 Tage bis ein durch ein Bounty prmierter Fehler als behoben angesehen werden kann. Behoben heit in diesem Zusammenhang, dass ein Fix
fr den Endanwender bereitsteht. Dies kann bei Vergleich mit dem Branchendurchschnitt als sehr schnell angesehen werden, bei denen Zeitrume von Durchschnittlich
153 Tage fr Exploits notwendig sind [10, S. 10].
Weitergehend kann man auch sehr gut erkennen, dass die Bearbeitungszeit in etwa
mit der Kritikalitt korreliert. Sowohl kritische wie auch hochpriore Schwachstellen
werden mit 41 Tagen gleichschnell bearbeitet. Die von Finifter et al. dargestellte
schnellere Bearbeitungen von kritischen Einreichungen konnte durch die zugrundeliegenden Daten selbst nicht besttigt werden, Detailinformationen stehen hier trotz
der Angabe einer Datenquelle und persnlicher Kommunikation nicht zur Verfgung
[4, S. 4]. Bei mittelschweren oder niedrigen Sicherheitslcken steigt diese Zahl auf 52
respektive 63 Tagen an. In allen Fllen lsst sich jedoch feststellen, dass die Standardabweichung relativ hoch ist. Dies drfte vor allem auch auf die Tatsache zurckgehen, dass wie dargestellt die Fehler unabhngig von der Priorisierung mitunter auch
einfach zu lsen sind. Die Notwendigkeit einer solch schnellen Bearbeitung der
Fehlerbilder zu ermglichen ist bei Bug-Bounty-Programmen nahezu obligatorisch
um vereinbarte Responsible-Disclosure Vereinbarungen einhalten zu knnen.
Gliedert man nun die Zeit fr die Behebung eines Issues weiter auf so lsst sich
feststellen, dass insgesamt pro Fix etwa 0,3 Tage fr die Rckmeldung zum Endkunden bentigt werden. Dies kann als sehr schnell angesehen werden. Weitergehend
wird die erste Analyse und Priorisierung des Fehlerbildes bereits ebenfalls hufig am
gleichen oder am nchsten Arbeitstag bereits erbracht. Die Lsung der Schwachstellen dauert im Durchschnitt etwa vierzehn Tage und die Produktivsetzung nimmt insgesamt etwa 29 Tage in Angriff. Der Hauptaufwand liegt ganz klar jedoch in der Analyse- sowie Lsungsphase. Mit diesen Leistungsdaten konnte Google bis auf wenige
Ausnahmen immer die gewhrten Responsible-Disclosure Zeitrume einhalten.
Weiter lsst sich feststellen, dass ber die Laufzeit einer Einreichung der Besitzer
des Issues im Durchschnitt 2,51 mal wechselt. Dies entspricht relativ gut der Tatsache, dass fr die Bearbeitung immer ein Entwickler sowie der Security-Scherriff bentigt wird. Zustzlich werden pro Issue etwa 30 verschiedene Kommentare, also
Kommunikationsvorgnge, hinterlassen. Hier ist jedoch darauf hinzuweisen, dass ein
Groteil der Kommentare durch automatisierte Prozesse wie der automatischen Freigabeprozesse oder bei Commits eingestellt wird.

Fazit und Ausblick

5.1

Ergebnis der Untersuchung

Im Rahmen dieser Ausarbeitung konnte im ersten Schritt eine generelle Einordnung

von Bug-Bounty-Programmen als wichtiges Instrument zur Einbeziehung der Com-

33

munity in das Sicherheitsmanagement eines Unternehmens durchgefhrt werden.

Dieses Wissen wurde anschlieend genutzt, um anhand der Rahmenbedingungen und
Prozesse eine Umsetzung fr Unternehmen aufzuzeigen. Zudem zeigt das Kapitel vier
dann im Detail, wie ein erfolgreiches Bug-Bounty-Programm auszugestalten ist und
welche Vorteile es bieten kann. Die dargestellten Kennzahlen und Verlufe knnen
beispielweise im Rahmen eines Benchmarkings fr ein eigenes Bounty-Programm
genutzt werden. Die Projektarbeit schafft damit auch entsprechend eine ganzheitliche
sowohl interne als auch externe Sicht fr Unternehmen auf das Themengebiet.
Bei der Bewertung kann festgestellt werden, dass durch die Einbindung einer
Community ein komplett neuer Blickwinkel auf die eigene Sicherheitsarchitektur
ermglicht wird. Anstelle eines meist sehr strukturiert geplanten internen Softwaretests kommt mit der externen Perspektive fremdes Wissen hinzu. Neue Werkzeuge
und Angriffsszenarien werden von Sicherheitsforschern zur Aufdeckung neuer
Fehlerbilder verwendet [8, S. 23]. Von diesen Erkenntnissen knnen die Angestellten
lernen und entsprechend den Fokus bei Bedarf verschieben. Dies resultiert in einer
hheren Applikationssicherheit [8, S. 22]. Sollte ein Programm weiter erfolgreich sich
am Markt etablieren ist die Marketingwirkung nicht zu unterschtzen. Der Entwicklungsgemeinschaft wird eine Offenheit gegenber Drittmeinungen symbolisiert. Zustzlich legt auch alleine die Aufforderung an Sicherheitsforschern das eigene Produkt zu Hacken, eine gewisse Selbstsicherheit offen. Kunden assoziieren mit BugBounty-Programmen einen gewissen Reifegrad des Produktes [8, S. 22]. Diese immateriellen Faktoren sind nicht zu unterschtzen und sollten bei der Entscheidung zwingend mit einflieen. Zustzlich stellen sie wie in Kapitel vier auch gezeigt eine kostengnstige Analysemglichkeit dar. Das Versprechen aber auf Einsparquoten von bis
zum 100-fachen im Vergleich zu internen Sicherheitsforschern wie Finifter et al. darstellt [4, S. 14] kann jedoch auf Grund der Erkenntnisse in Kapitel 3.3 sowie 4 vermutlich nicht aufrecht erhalten werden.
All diese Vorteile drfen dann aber auch nicht darber hinwegtuschen, dass zentrale Voraussetzung fr die offensive Vermarktung eines solchen Angebots an die
Entwickler- und Hackergemeinschaft immer auch die berzeugung sein muss, dass
die Sicherheit des eigenen Produkts einen hohen Reifegrad aufweist. Bug-BountyProgramme stellen damit nur eine Option fr Unternehmen dar, die Sicherheit bereits
im Griff haben und weiter verbessern wollen. Firmen die bereits heute Probleme bei
der Behebung von intern bekanntgewordenen Sicherheitslcken haben und dem Themengebiet IT-Sicherheit nur eine sehr eingeschrnkte Prioritt zuordnen, knnen
groe Risiken am Markt bezglich des Image entstehen. Eine Zurcknahme des Programms ist dabei meist kaum mehr mglich. Dies folgernd darf auch nicht der Fehler
gemacht werden, Bug-Bounties als Allheilmittel zu sehen.
Um diese Risiken zu vermeiden muss die Bedeutung der Ausgestaltung der Rahmenfaktoren hervorgehoben werden. Ein guter Entstrungsprozess wie in Kapitel drei
dargestellt mit einer mglichst geringen Entstrungszeit stellt den wichtigsten Baustein hierfr dar. Ein ehrlicher, flexibler und transparenter Umgang mit der Community ist dabei Pflicht.

34

5.2

Ausblick

Es zeigt sich, dass in der Praxis vor allem die groen Webunternehmen wie Google,
Facebook oder PayPal von Bug-Bounty-Programmen profitieren. Dies sind Firmen,
die klassischerweise bereits durch ihre Prsenz am Markt eine groe Anziehungskraft
auf Entwickler aufweisen. Daher wird es in Zukunft spannend sein, ob auch kleinere
und mittelstndische Unternehmen auf hnliche Verfahren verstrkt setzen werden.
Eine ausreichende Anzahl an Sicherheitsforscher einbinden zu knnen ist hier eine
entscheidende Fragestellung. In diesem Zusammenhang wird von Interesse sein genau
festzustellen welche Modelle sich fr die unterschiedlichen Geschftsformen etablieren werden. So knnen zeitlich begrenzte Aktionen und Kooperationen mit Universitten fr mittelstndische Unternehmen sicherlich weit einfacher realisiert werden.
Ebenfalls scheint sich mit Plattformen wie Bugcrowd aber auch die HackerOnePlattform Vermittler am Markt zu etablieren, um auch kleineren Programmen eine
Prsenz zu verschaffen. Auch fr aktuell noch nicht betrachtete Unternehmensgruppen wie Hersteller von Industrieapplikationen (Steuerungssysteme, Infrastrukturen)
knnten Bug-Bounty-Programme ein sinnvolles Werkzeug sein. Ziel wre es definiert
fr bestimmte Unternehmensgruppen basierend auf Kapitel 3.1 Leitfden fr die Einbindung der Community zu erarbeiten.
Weitergehende Forschungen sind hinsichtlich des Lebenszykluses von BugBounty-Programmen ebenfalls notwendig. Zwar wurde in Kapitel 3.4 das Neuaufsetzen dargestellt. ber dem Lebenszyklus von einem solchen Programm knnten jedoch zustzlich abhngig von der Laufzeit Manahmen ergriffen werden, um die
Attraktivitt fr Externe weiter hoch zu halten. In dieser Arbeit angesprochene Themengebiete wie Gamification durch Wettbewerbe, Bonusprogramme oder die Erhhung von Bounties abhngig dem Zeitverlauf knnen systematisch betrachtet werden.

Literaturverzeichnis
1. Wikipedia: Sicherheitslcke (Software), http://de.wikipedia.org/w/index.php?
oldid=116228200 (2014). Abgerufen am 02.03.2014.
2. Bhme, R.: A Comparison of Market Approaches to Software Vulnerability Disclosure. Emerging Trends in Information and Communication Security (2006).
3. Bundesamt fr Sicherheit in der Informationstechnik: Lebenszyklus einer
Schwachstelle, http://www.internet-sicherheit.de/institut/service/glossar/
allgemeine-studien/bsi-studien/?eID=dam_frontend_push&docID=2769 (2012).
Abgerufen am 06.04.2014.
4. Finifter, M., Akhawe, D. and Wagner, D.: An Empirical Study of Vulnerability
Rewards Programs, http://www.cs.berkeley.edu/~devdatta/papers/vrp-paper.pdf
(2013). Abgerufen am 06.04.2014.
5. Frei, S., Tellenbach, B. and Plattner, B.: 0-Day Patch. Exposing Vendors
(In)security Performance, http://www.techzoom.net/papers/
blackhat_0day_patch_2008.pdf (2008). Abgerufen am 06.04.2014.
6. Mein, A.: Google Online Security Blog: Celebrating one year of web vulnerability research, http://googleonlinesecurity.blogspot.de/2012/02/celebrating-oneyear-of-web.html (2012). Abgerufen am 01.03.2014.

35

7. Anagnos, G.: PayPals Bug Bounty Program: One Year Later, https://www.
paypal-forward.com/innovation/paypal-s-bug-bounty-program-one-year-later/
(2014). Abgerufen am 01.03.2014.
8. Rose, J.: Decoding Bug Bounty Programs, https://www.owasp.org/images/1/14/
Rose.pdf (2014). Abgerufen am 06.04.2014.
9. Schneier, B.: Crypto-Gram Newsletter. Full Disclosure and the Window of Exposure, https://www.schneier.com/crypto-gram-0009.html (2000). Abgerufen am
10.03.2014.
10. Frei, S.: The Known Unknowns. Empirical Analysis of publicly unknown security vulnerabilities, https://www.nsslabs.com/system/files/public-report/files/
The%20Known%20Unknowns_1.pdf (2013). Abgerufen am 06.04.2014.
11. Shepherd, S.: How do we define Responsible Disclosure?, http://www.sans.org/
reading-room/whitepapers/threats/define-responsible-disclosure-932 (2013).
Abgerufen am 16.03.2014.
12. ZEIT ONLINE GmbH: Bug Bounty: Kopfgeldjagd im Internet, http://
www.zeit.de/digital/datenschutz/2013-09/bug-bounty-hack (2013).
Abgerufen am 25.03.2014.
13. Bugcrowd Inc.: Full Managed Bug Bounties, https://bugcrowd.com/ (2014).
Abgerufen am 06.04.2014.
14. Organization for Internet Safety: Guidelines for Security Vulnerability Reporting
and Response, http://www.symantec.com/security/OIS_Guidelines%20for
%20responsible%20disclosure.pdf (2004). Abgerufen am 06.04.2014.
15. Google Inc.: Reward Nomination Process, http://www.chromium.org/Home/
chromium-security/vulnerability-rewards-program/reward-nomination-process/
(2014). Abgerufen am 06.04.2014.
16. Evans, C.: Bug bounties vs. black (& grey) markets,
http://scarybeastsecurity.blogspot.de/2011/05/bug-bounties-vs-black-greymarkets.html (2011). Abgerufen am 25.03.2014.
17. Miller, C.: The Legitimate Vulnerability Market, http://weis2007.econinfosec.
org/papers/29.pdf (2007). Abgerufen am 06.04.2014.
18. De Souza Soares, Philipp Alvares: Durch die Hintertr, http://www.zeit.de/
2013/41/vupen-sicherheitsluecken-geheimdienste/ (2013).
Abgerufen am 06.04.2014.
19. Boehm, B.W.: Software engineering economics Prentice-Hall, Englewood Cliffs,
N.J (1981).
20. Microsoft Corporation: Secure Development Lifecycle, http://www.microsoft.
com/download/en/details.aspx?id=12379 (2010). Abgerufen am 06.04.2014.
21. Reis, C., Barth, A. and Pizano, C.: Browser Security: Lessons from Google
Chrome, http://dl.acm.org/citation.cfm?id=1556050 (2009).
Abgerufen am 06.04.2014.
22. Rouse, M.: What is fuzz testing (fuzzing)?, http://searchsecurity.techtarget.com/
definition/fuzz-testing/ (2010). Abgerufen am 05.04.2014.
23. Jescheck, H.-H. (ed.): Strafgesetzbuchs Dt. Taschenbuch-Verl., Mnchen (1999).
24. Jlussi, D. and Hawellek, C.: IT-Sicherheit und 202c StGB, http://www.eicar.
org/files/jlussi_leitfaden_web.pdf (2007). Abgerufen am 06.04.2014.

36

25. Vatis, M.: The Council of Europe Convention on Cybercrime, http://cs.brown.

edu/courses/csci1950-p/sources/lec16/Vatis.pdf (2011).
Abgerufen am 18.03.2014.
26. Heise Online: Magix verhindert Exploit-Verffentlichung, http://www.heise.de/
newsticker/meldung/Magix-verhindert-Exploit-Veroeffentlichung-1235123.html
(2011). Abgerufen am 18.03.2014.
27. Kleinz, T.: StudiVZ: Hacken verboten, http://www.heise.de/newsticker/meldung/
StudiVZ-Hacken-verboten-Update-157815.html (2007).
Abgerufen am 18.03.2014.
28. Bugcrowd Inc.: The Bug Bounty List, https://bugcrowd.com/list-of-bug-bountyprograms/ (2014). Abgerufen am 18.03.2014.
29. Bugsheet: List of Bug Bounties & Disclosure Programs, http://www.bugsheet.
com/bug-bounties/ (2014). Abgerufen am 18.03.2014.
30. OWASP Foundation: OWASP AppSecUSA 2012: Bug Bounty Programs,
https://www.youtube.com/watch?v=k8Hx_XDUxXA (2012).
Abgerufen am 06.04.2014.
31. Google Inc.: Chromium Vulnerability Contribution Program. Official Rules,
https://docs.google.com/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRl
dnxneDoyZWQ3ZjY3MmMxMWUxNDcx (2014). Abgerufen am 06.04.2014.
32. Heise Online: 50.000 Dollar und mehr fr Bugs, http://www.heise.de/security/
meldung/50-000-Dollar-und-mehr-fuer-Bugs-1861881.html (2013).
Abgerufen am 30.03.2014.
33. Google Inc.: Reward Nomination Process, http://www.chromium.org/Home/
chromium-security/vulnerability-rewards-program/reward-nomination-process/
(2013). Abgerufen am 25.03.2014.
34. Facebook Inc.: Responsible Disclosure Statement, http://about.pinterest.com/
terms/responsible-disclosure/ (2014). Abgerufen am 30.03.2014.
35. Adobe Systems Inc.: Notifying Adobe of Security Issues, http://helpx.adobe.com/
security/alertus.html (2014). Abgerufen am 30.03.2014.
36. Deutsche Post AG: Deutsche Post startet zweiten "Security Cup",
http://www.dpdhl.com/de/presse/pressemitteilungen/2013/deutsche_post_security
_cup.html (2013). Abgerufen am 06.04.2014.
37. Wikipedia: Pwn2Own - Wikipedia, the free encyclopedia, http://en.wikipedia.org/
w/index.php?oldid=601384464 (2014). Abgerufen am 30.03.2014.
38. Microsoft Corporation: Internet Explorer 11 Preview Program Guidelines,
http://technet.microsoft.com/en-us/security/dn425054/ (2013). Abgerufen am
30.03.2014.
39. Google Inc.: Program Rules, http://www.google.com/about/appsecurity/rewardprogram/ (2014). Abgerufen am 30.03.2014.
40. OWASP Foundation: OWASP Top 10, http://owasptop10.googlecode.com/
files/OWASP%20Top%2010%20-%202013.pdf (2014).
Abgerufen am 06.04.2014.
41. Foreman, P.: Vulnerability management CRC Press, Boca Raton (2010).
42. Laakso, M.: The vulnerability process: a tiger team approach to resolving vulnerability cases, https://www.ee.oulu.fi/research/ouspg/PROTOS_FIRST1999process?action=AttachFile&do=get&target=PROTOS_FIRST1999_paper.pdf
(1999). Abgerufen am 06.04.2014.

37

43. OWASP Foundation: OWASP Risk Rating, https://www.owasp.org/index.php/

OWASP_Risk_Rating_Methodology (2014). Abgerufen am 06.04.2014.
44. NIST: NVD Common Vulnerability Scoring System Support v2,
http://nvd.nist.gov/cvss.cfm (2007). Abgerufen am 28.03.2014.
45. Krsul, V.: Software Vulnerability Analysis, http://www.krsul.org/ivan/articles/
main.pdf (1998). Abgerufen am 06.04.2014.
46. Jones, C.: A short history of the cost per defect metric, http://semat.org/wpcontent/uploads/2012/03/a_short_history_of_the_cost_per_defect_metric.doc
(2009). Abgerufen am 06.04.2014.
47. Google Inc.: Security rewards at Google: Two MEELLION Dollars Later,
http://googleonlinesecurity.blogspot.de/2013/08/security-rewards-at-googletwo.html (2014). Abgerufen am 06.04.2014.
48. Google Inc.: Chromium Issues, https://code.google.com/p/chromium/issues/list/
(2014). Abgerufen am 25.03.2014.
49. Bhm, C.: Auswertung Bounties Gesamt (2013).
50. HackerOne: Vulnerability Disclosure, https://hackerone.com/faq#vulnerabilitydisclosure/ (2014). Abgerufen am 25.03.2014.
51. Google Inc.: Security Sheriff, http://www.chromium.org/Home/chromiumsecurity/security-sheriff/ (2014). Abgerufen am 28.03.2014.
52. Google Inc.: Severity Guidelines for Security Issues, http://www.chromium.org/
developers/severity-guidelines/ (2014). Abgerufen am 28.03.2014.
53. Google Inc.: Security Labels, http://www.chromium.org/Home/chromiumsecurity/security-labels/ (2014). Abgerufen am 29.03.2014.