Od hakera do właściciela programu Bug Bounty: nauka

Opublikowany: 2022-04-27

Bezpieczeństwo było głównym priorytetem w firmie Braze od momentu założenia firmy w 2011 roku. Skupienie się na ochronie danych naszych klientów doprowadziło nas do przyjęcia koncepcji bezpieczeństwa i prywatności w fazie projektowania podczas tworzenia naszego produktu, zapewnienia, że ​​otrzymaliśmy certyfikat zgodny z ISO 27001 i SOC 2 Typ 2 oraz zbudowanie dedykowanego klastra HIPAA, aby pomóc markom chronić chronione informacje zdrowotne. Ale chociaż wszystkie te kroki są ważne, nie spoczywamy na laurach. Zawsze możesz zrobić więcej, a skupienie się na znajdowaniu nowych sposobów na wzmocnienie naszego bezpieczeństwa jest ważnym powodem, dla którego tu jestem.

W 2020 roku Mark Shasha, szef bezpieczeństwa w Braze, zaprosił mnie do pomocy w uruchomieniu programu bug bounty, którego celem jest ułatwienie identyfikacji problemów z bezpieczeństwem, które mogą mieć wpływ na nasz produkt. A teraz, gdy program działa już od nieco ponad roku, pomyślałem, że nadszedł czas, aby spojrzeć wstecz na to, co zbudowaliśmy i czego się nauczyłem po drodze.

Co to jest program Bug Bounty?

W programie Braze bug bounty strony zewnętrzne są zachęcane do prób złamania oczyszczonej, wolnej od danych wersji platformy Braze i otrzymują zapłatę, gdy zidentyfikują ważny, możliwy do wykonania problem z zabezpieczeniami. Stworzenie programu bug bounty umożliwia firmie takiej jak Braze wykorzystanie zewnętrznych badaczy bezpieczeństwa i specjalistów do identyfikowania potencjalnych problemów z bezpieczeństwem, co pozwala nam proaktywnie eliminować luki w zabezpieczeniach.

Programy te są powszechnie postrzegane jako jedne z najważniejszych środków bezpieczeństwa cybernetycznego, jakie firma może zastosować — po części dlatego, że umożliwiają markom pozyskiwanie informacji o bezpieczeństwie od ogromnej liczby różnych osób o szerokim wachlarzu umiejętności. Z reguły uruchomienie i utrzymywanie udanego publicznego bounty za błędy jest oznaką, że organizacja ma zdrowy program bezpieczeństwa, ponieważ prowadzenie takiego programu bez incydentów wymaga poziomu dojrzałości bezpieczeństwa, który wymaga wiele przemyśleń i uwagi.

Moje dni jako uczestnik Bug Bounty

Po raz pierwszy usłyszałem o nagrodach za błędy w 2014 roku, ale ponieważ uważałem, że brzmią zbyt pięknie, aby mogły być prawdziwe, nie wziąłem udziału w jednej aż do 2016 roku. Zainspirowany kilkoma postami na blogu pisanymi przez innych hakerów etycznych, wziąłem udział w Yahoo! bug bounty i stwierdziłem, że mam prawdziwy talent do pracy. Po pierwsze, dali mi możliwość wykorzystania moich umiejętności hakerskich do ochrony systemów komputerowych, zamiast narażać je na szwank. Po drugie, dali mi możliwość zarobienia dużych sum pieniędzy, gdy tam byłem.

Wraz ze wzrostem liczby firm i organizacji rządowych uruchamiających programy bug bounty, zacząłem specjalizować się w polowaniu na błędy związane z fałszowaniem żądań po stronie serwera (SSRF) do programu bug bounty powiązanego z dużą firmą telekomunikacyjną i zarobiłem prawie 1 milion dolarów tylko z identyfikacji tych luk. Ale podczas gdy finansowa strona pracy za robaki naprawdę mi się opłacała, zauważyłem, że brakuje mi struktury i osobistych powiązań, które wiążą się z pracą na co dzień. Kiedy więc Braze zaoferował mi możliwość uruchomienia i nadzorowania własnego programu nagród za błędy, skorzystałem z tej szansy.

Jak uruchomiliśmy program Bug Bounty w Braze

W Braze musieliśmy przejść przez kilka kroków, zanim byliśmy w stanie urzeczywistnić naszą wizję programu bug bounty. Po pierwsze, ponieważ uczestnicy są opłacani za każdy zasadny, możliwy do działania błąd, który znajdą, uruchomienie programu nagród bez usuwania jakichkolwiek znanych luk w zabezpieczeniach może sprawić, że firmy będą płacić najwyższe pieniądze za informacje, które już posiadają, zmniejszając jednocześnie wpływ programu podnosząc jego koszt. W tym celu przed przygotowaniami do oficjalnej premiery wykonaliśmy następujące kroki:

  • Wdrażanie wewnętrznych umów dotyczących poziomu usług (SLA) dotyczących bezpieczeństwa z zespołami programistycznymi

  • Tworzenie programu do zarządzania podatnościami

  • Wdrażanie narzędzi do dynamicznej analizy bezpieczeństwa (DAST)

  • Wykonywanie wewnętrznych testów penetracyjnych

  • Przeprowadź zewnętrzne testy penetracyjne

  • Zapewnienie, że wszystkie znane problemy zostały naprawione

Następnie, gdy byliśmy już pewni, że zduplikowana wersja platformy Braze stworzona dla programu bug bounty jest tak dopracowana, jak to tylko możliwe, zainicjowaliśmy prywatny program o ograniczonym zakresie, korzystając z platformy Bugcrowd. Uruchomiliśmy ten dwutygodniowy program na żądanie, abyśmy mogli zarówno wykorzystać go jako weryfikację koncepcji, jak i pomóc wprowadzić organizację Braze w realia prowadzenia programu bug bounty. W końcu pomysł zapraszania hakerów i badaczy bezpieczeństwa do szukania luk bezpieczeństwa w twoim produkcie może wydawać się dziwny lub mylący, jeśli wcześniej nie spotkałeś się z nagrodami za błędy.

4 duże wnioski z uruchomienia nowego programu Bug Bounty

Dość szybko dowiedziałem się, że uruchomienie nowego programu bug bounty jest znacznie trudniejsze niż przejęcie istniejącego. Jest tak wiele różnych czynników, które składają się na stworzenie udanego programu, który nie przyciąga tak wiele uwagi — po części dlatego, że nie są tak ekscytujące, jak identyfikowanie krytycznych błędów, szybkie ich naprawianie i wypłacanie dużych nagród. Biorąc to pod uwagę, porozmawiajmy o kilku z moich największych odkryć:

1. Uruchomienie programu Bug Bounty wymaga współpracy między zespołami

Początkowo miałem nadzieję, że uruchomienie programu będzie tak proste, jak podjęcie decyzji o zrobieniu tego, wybranie odpowiedniej platformy, podjęcie decyzji o zakresie i wysokości nagród, a następnie po prostu rozpoczęcie pracy. Ale zrobienie tego właściwie wymaga o wiele więcej planowania, przygotowań i uwagi, niż myślałem. Po pierwsze, nie wziąłem pod uwagę wszystkich innych zespołów w Braze, które miały do ​​odegrania rolę we wspieraniu uruchomienia programu bug bounty — z pracy, jaką wykonał nasz zespół prawny, aby upewnić się, że mamy właściwe sformułowanie naszą zgodę Safe Harbor na pracę wykonaną w celu stworzenia naszych umów SLA i zapewnienia właściwego procesu eskalacji w przypadku naruszeń. Ta praca może być trudna, ale jest absolutnie niezbędna. Program bug bounty, który nie został dokładnie zaplanowany i wykonany, nieuchronnie napotka wiele problemów, co z kolei może prowadzić do złych wiadomości o programie, co utrudni przyciągnięcie czołowych hakerów i badaczy bezpieczeństwa, a potencjalnie skazując na zagładę całe przedsięwzięcie.

2. Nigdy nie trać z oczu swojego związku z hakerami i badaczami

Ważne jest, aby marki pamiętały, że udany program bug bounty zależy od relacji między programem a hakerami/badaczami, którzy w nim uczestniczą. Zadowoleni hakerzy znacznie chętniej poświęcają swój czas na Twój program, a biorąc pod uwagę, że każdy program bounty walczy o część ograniczonego zasobu — a mianowicie czasu i uwagi hakerów/badaczy — ważne jest, aby upewnić się, że się skonfigurowałeś na sukces, traktując tę ​​relację priorytetowo i robiąc wszystko, co w twojej mocy, aby odróżnić się od innych programów. Niektóre firmy robią to, płacąc wyższe nagrody niż średnia w branży za różne klasy i wagi błędów, ale nie jest to jedyny (lub najlepszy) sposób, aby to zrobić.

Ze względu na moje doświadczenie jako łowca nagród za błędy, mogłem wykorzystać moje doświadczenia, aby pomóc w informowaniu, w jaki sposób Braze pielęgnuje tę relację. Na przykład udało mi się uzyskać wpisowe, aby upewnić się, że Braze uruchamia jednocześnie publiczne i prywatne programy nagród za błędy. To pozwala nam identyfikować osoby zaangażowane w nasz program publiczny, które zgłaszają dobre, ważne raporty, a następnie nagradzać je, zapraszając do naszego programu prywatnego. Uczestnicy ci mają dodatkowe funkcje do przetestowania i uzyskania pierwszego cracka przy dodawaniu nowych zakresów, zanim dodamy ich do programu publicznego. Wierzę, że robiąc takie drobiazgi, firmy mogą okazać uznanie dla naukowców, którzy wnoszą wkład w ich program i zachęcić ich do pogłębienia zaangażowania w przyszłości.

3. Bug Bounty wyglądają inaczej niż po stronie firmy

Zanim zacząłem prowadzić własny program bug bounty, nie byłem fanem pracy z programami zarządzanymi przez platformę innej firmy. W przypadku programów skonfigurowanych w ten sposób firmy często polegają na zewnętrznych narzędziach triaerowych dostarczanych przez platformę, które przeglądają zgłoszenia hakerów/badaczy i określają powagę każdego zidentyfikowanego błędu, a ja miałem pewne doświadczenia, w których wykonałem telefony, z którymi się nie zgadzałem.

Jednak teraz, kiedy jestem po drugiej stronie, widzę, ile wartości takie podejście oparte na platformie zapewnia firmom, które z niego korzystają. Chociaż nadal jesteśmy zaangażowani w bezpośrednie nadzorowanie pracy wykonywanej przez zewnętrzne triagery, których używamy, odkryłem, że ich wykorzystanie może wiele zdziałać, aby zmniejszyć obciążenie czasowe i energetyczne związane z uruchomieniem takiego programu. Triagerzy, z którymi współpracujemy, są profesjonalistami i okazały się być wielkim atutem naszego programu, pomagając w pomyślnym uruchomieniu.

4. Praca nie kończy się na zidentyfikowaniu błędu

Przed dołączeniem do Braze często frustrowały mnie programy bug bounty, których naprawienie zgłoszonych im luk zajęło mi tygodnie lub miesiące. Z mojego punktu widzenia, problemy wydawały się być dość okrojone i suche, i czułem, że wdrożenie łaty dla tych błędów powinno zająć niewiele czasu lub wcale.

Ale teraz, gdy byłem świadkiem tego, co dzieje się za kulisami, gdy zgłaszany jest jeden z tych błędów, zdałem sobie sprawę, że nie wziąłem pod uwagę wszystkich dyskusji i prac, które zostały wykonane za kulisami podczas cyklu życia luki w zabezpieczeniach — z dochodzenia oraz potwierdzenie błędu i dostarczenie tych szczegółów do odpowiedzialnego zespołu wewnętrznie do rzeczywistych zmian w kodowaniu, testowania i wydań, które muszą nastąpić, zanim błąd zostanie naprawiony. Rzeczywistość jest taka, że ​​te rzeczy wymagają czasu i jako haker nie zawsze brałem pod uwagę włożoną pracę, po części dlatego, że chciałem, aby cały proces został wykonany tak szybko, jak to możliwe, abym mógł otrzymać zapłatę.

Końcowe przemyślenia

Prowadzenie programu bug bounty przez ostatni rok zmieniło całe moje spojrzenie na branżę, a nawet zmieniło sposób, w jaki wybieram programy, na których skupiam się w wolnym czasie. To spojrzenie za zasłonę dało mi dużo więcej szacunku dla zasadniczej pracy wykonywanej przez triagerów platform i lepsze zrozumienie, jakie są realistyczne ramy czasowe dla firm, aby ocenić i naprawić zgłaszane przeze mnie błędy. Mam nadzieję, że dzięki temu nowemu spostrzeżeniu będę mógł dalej ulepszać i rozwijać program nagród za błędy Braze, jednocześnie odnosząc jeszcze większy sukces jako łowca nagród za błędy.

Chcesz dołączyć do zespołu w Braze? Sprawdź nasze otwarte role !