Úskalí Bug Bounty programů

Na Bug Bounty programy můžeme narazit u různých společnosti, zpravidla z oboru IT, jako je např. Google, Microsoft, Facebook, apod.

Takový Bug Bounty program funguje vcelku jednoduše. Najdete zranitelnost, nahlásíte ji dané firmě a ona vám za ní zaplatí. Jenže je tu několik úskalí, především pro firmu, co takový Bug Bounty program vyhlásí.

Bug Bounty program může vyhlásit jakákoliv organizace, ale měla by si vše předem důkladně promyslet a rozhodnout se, zda do toho půjde sama anebo tuto činnost outsourcuje a nechá ji realizovat zkušenějším partnerem.

Bug Bounty program není možné vnímat jako náhradu penetračního testu, spíš doplněk. Rozdíl mezi zranitelností nalezenou v rámci Bug Bounty programu a zranitelností nalezenou v rámci penetračního testu spočívá v tom, že penetrační tester postupuje zpravidla vždy podle nějaké metodiky, např. OWASP testing guide, zatímco osoba hledající zranitelnost v rámci Bug Bounty programu dost často používá vlastní velice specifický postup a rovněž se i specializuje na určitou problematiku, a je tak schopna odhalit zranitelnost, kterou není možné v rámci klasických penetračních testů identifikovat.

Svou roli zde jistě hrají i peníze, neboť za provedení penetračního testu dostane tester zaplaceno tak jako tak, rozuměj, ať už nějakou zranitelnost najde nebo ne, zatímco v případě Bug Bounty programu dostává tester zaplaceno jen za nalezenou zranitelnost. Z výše uvedeného důvodu by měl být Bug Bounty program vyhlašován až v okamžiku, kdy proběhnou klasické penetrační testy, a je ověřeno, že nalezené zranitelnosti byly skutečně odstraněny. V opačném případě hrozí, že hledači zranitelností naleznou velké množství zranitelností a budou chtít vyplatit odměnu.

• Odměna jednoznačně zvyšuje motiv hackerů, více jich nyní bude testovat vaši aplikaci, a pokud nebudete včas reagovat, platit, odstraňovat nalezené zranitelnosti, tak pak daný nález někdo z nich zveřejní, a vy budete mít nálepku neseriózní firmy s mizernou úrovní bezpečnosti. Toto riziko lze částečně omezit tím, že vyhlásíte uzavřený Bug Bounty program. Bug Bounty programy totiž mohou být uzavřené, a chyby pak hledá jen omezený okruh osob, které se do tohoto programu přihlásí. V případě otevřených pak může chyby v aplikaci hledat v podstatě kdokoliv. (Případně by se dalo ještě uvažovat o něčem mezi tím, tedy že testovat může kdokoliv, ale musí se nejprve zaregistrovat.)
• Obzvlášť u otevřených Bug Bounty programů můžete být zahlceni skutečně obrovským množstvím neověřených zranitelností s různou mírou závažnosti. Spustit libovolný skener zranitelností totiž zvládne téměř každý. Ovšem interpretovat a ověřit ty mraky nalezených zranitelností již bohužel nikoliv, takže to zbude na vás. O tom, že vést komunikaci s každým, kdo má pocit, že nalezl nějakou kritickou zranitelnost, není jednoduché, se před lety přesvědčila i Mary Ann Davidson, manažerka bezpečnosti v Oracle, které jednoho dne prostě ruply nervy, a reagovala pak velmi emotivně.
• Pokud jste doposud nezavedli SecDevOps, tak můžete narazit i na to, že v okamžiku, kdy Bug Bounty program spustíte, tak budete nuceni rychleji uvolňovat nové verze, resp. komunita vás do toho může tlačit, protože nebude chtít, abyste nahlášenou zranitelnost ponechali v aplikaci příliš dlouho, a budou argumentovat tím, že by ji mohl najít i někdo jiný a zneužít ji. Jistě, něco se můžete pokusit opravit např. pomocí virtual patchingu, ale ne všechno.
• Jestliže Bug Bounty program vyhlásíte, pak se budete muset hlášením od hledačů bugů vážně zabývat a řešit, kdo první reportoval bug, zda vyplatit odměnu, zda zveřejnit jméno nálezce, a jak doložit, že druhý nálezce je skutečně druhý a nic proto nedostane. Otázka také je, zda případné spory ohledně nalezené zranitelnosti a toho, zda se jedná skutečně o zranitelnost, s nálezcem budete řešit veřejně na webových stránkách.
• Budete reportované, potvrzené a opravené bugy zveřejňovat? Pokud ano, tak jaké detaily ohledně zranitelnosti budete uvádět? A jak se zachováte, když v systému nalezne díru váš vlastní zaměstnanec, také ji zveřejníte? Když ne tak, vám ji pak může reportovat hacker a požadovat odměnu. Vyplatíte mu ji, přestože už o chybě vlastně víte? Na jednu stranu asi nebudete chtít zveřejňovat detailní informace ohledně zranitelnosti, ale na stranu druhou vám pak může více testerů reportovat stejnou zranitelnost a budou rozladěni, když jim sdělíte, že už ji někdo reportoval, a že je v databázi pod určitým ID, jen nejsou uvedeny podstatné detaily, aby ji někdo nezneužil.
• Mohou se objevit dvě hlášení přibližně ve stejný čas s různou úrovní detailu, (Vaše aplikace umožňuje XSS.) a vy se budete muset rozhodnout, komu zaplatíte, zda tomu kdo byl první anebo tomu, kdo uvedl veškeré detaily. I na to byste měli myslet, až budete Bug Bounty program vyhlašovat. Jako podmínku byste si měli proto dát, co přesně musí osoba, která zranitelnost hlásí, uvést, aby bylo možné přítomnost zranitelnosti ověřit.
• Jestliže vaše konkurence Bug Bounty program nezavede, počítáte s tím, že to pak můžete být jen vy, o kom se bude říkat, že má děravé aplikace, a některé vaše stávající i potenciální klienty to pak může odradit?
• Jakou nastavíte odměnu, aby se hackerům vyplatilo daný bug vám nahlásit a ne ho zneužít? Měli byste nastavit nějaký cenový model, tedy kolik budete platit za zranitelnost, kterou lze klasifikovat jako nízkou, střední, vysokou a kritickou. Špatně nastavená odměna může i poškodit vaše dobré jméno, protože někdo může prohlásit, že jste na tom dost špatně, když jste ochotni zaplatit za nahlášený bug jen takový směšný bakšiš. Zvážit byste také měli, zda nezavedete nějaký strop, tj. kolik může být třeba celkově vyplaceno na odměnách za nalezení zranitelností. To proto, abyste pak byli schopni dostát svým závazkům.
• Pro hodnocení zranitelností byste měli použít nějakou všeobecně uznávanou metodiku hodnocení zranitelností, např. CVSSv3, abyste minimalizovali riziko sporu ohledně závažnosti objevené zranitelnosti a tedy i výše odměny za její nahlášení.
• Zvýší se počet připojených uživatelů a skenů, a vzroste i zatížení serveru. A jestliže jste doposud nemuseli dostupnost až tak moc řešit, neb žádné DDoS útoky na vás vedeny nebyly, nyní budete muset.
• Počítejte s tím, že mezi legitimními hackery pracující v rámci Bug Bounty programu budou probíhat i skutečné útoky. Zvýší se počet záznamů v logách a zhorší se i detekce a provozní odezva. Ve výsledku může být zavedení Bug Bounty programu dražší, než standardní testování a nemusí přinést kýžený efekt.
• Odměna za nalezenou zranitelnost bude nejspíš vždy nižší, než možná škoda, tak se může najít někdo, kdo bude již od počátku hackovat s cílem nalezený bug nereportovat, nýbrž ho zneužít a když mu to nevyjde, tak se bude hájit tím, že se jen účastnil Bug Bounty programu, takže pak nemusí jít aplikovat zákon č. 40/2009 Sb. a příslušné paragrafy 230 a 231 neboť hacker bude tvrdit, že jednal v souladu s paragrafem 30 TZ.

Závěr: Výše uvedené mě vede k závěru, že Bug Bounty program se může vyplatit jen firmě se silným bezpečnostním zázemím, která si je jista se svou úrovní zabezpečení a dokáže případný tlak na ze strany bezpečnostní komunity a odborné i laické veřejnosti mediálně ustát a zveřejnění zranitelností ji nepoškodí.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.