Program bug bounty czyli płacenie hakerom za wykryte podatności to kolejny sposób poprawę bezpieczeństwa systemów i aplikacji.
Wiele par oczu wyszukujących podatności oraz płatność w systemie success fee jest na tyle ciekawy, że coraz więcej firm korzysta z platform takich jak Bugcrowd czy HackerOne i uruchamia programy firmowe.
Jeśli jesteś bezpiecznikiem, osobą odpowiedzialną za start lub prowadzenie takiego programu, to jest to artykuł dla Ciebie.
Dowiesz się w jaki sposób położyć taki program na trzy różne sposoby.
Sposób pierwszy – brak zespołu obsługującego zgłoszenia
Haker zgłosił podatność, należałoby ją sprawdzić i ewentualnie załatać. Jak na złość właśnie wszyscy są zajęci przy wdrażaniu super hiper mega ważnej nowej funkcjonalności, nie ma komu łatać jakiś starych systemów.
Prosisz zgłaszającego o cierpliwość. I tak przez … dwa miesiące.
Myślisz, że zaczeka?
Wątpię.
O ile badacze mogą czekać na nagrodę, czy ujawnienia podatności publicznie, to czekanie na potwierdzenie podatności dłużej niż miesiąc nie zostanie zaakceptowane. Jeśli sytuacja będzie się powtarzać, hakerzy nie będą marnować swojego czasu na Twój program.
Jeśli nie chcesz położyć programu, zanim go wystartujesz, upewnij się że, jest ktoś, kto będzie weryfikował zgłoszenia. Musi to być ktoś, kto będzie znał się na programowaniu, żeby nie dał się nabrać na atak (phishing) za pomocą fałszywego zgłoszenia podatności (opiszę ten przypadek w innym artykule).
W zespole developerskim/administracyjnym musi być opracowana szybka ścieżka na likwidację podatności – nie powinny być one traktowane jak nowe funkcjonalności i leżeć w backlogu, czy podlegać standardowemu planowaniu.
Sposób drugi – brak budżetu
Zgłoszony został błąd bezpieczeństwa, zespół potwierdził i usunął podatność. Czas na wypłatę nagrody.
Niestety, na ten miesiąc limit wydatków został wykorzystany.
Haker, który znalazł podatność nie poświęcił swojego czasu charytatywnie. Pracował za obietnicę nagrody (tzw. success fee) .
Tej, której teraz nie dostał.
Co zrobi? Opublikuje podatność? Zgłosi to operatorowi platformy? Ostrzeże kolegów, przed firmą, która nie płaci?
Na pewno już więcej nie będzie chciał pracować dla Twojej firmy.
Jeśli nie chcesz pogrążyć firmowego programu bug bounty zadbaj o budżet na nagrody.
Możesz założyć na początek po 4 wykryte błędy na jednego researchera miesięcznie w programie prywatnym, jeden błąd jest warty średnio $300-$500. Gdy zostaje nadwyżka z poprzedniego miesiąca możesz zapraszać kolejnych hakerów. Budżet na nagrody powinien stale wzrastać wraz z rozwojem produktu podlegającemu badaniu.
Gdyby ilość błędów krytycznych znacznie przekroczyła budżet w pierwszym miesiącu, przemyśl wewnętrzny audyt bezpieczeństwa aplikacji. Może kod jest tak tragiczny?
Sposób trzeci – program prywatny na zawsze
Twój program działa już dobre kilka miesięcy, researcherzy przestali zgłaszać błędy do poprawy.
Dodajesz zapraszasz po dwie nowe osoby tygodniowo, głównie osoby, które wpadły przez wsparcie klienta lub jakiś formularz kontaktowy na stronie z informacją, że znalazły „błędy bezpieczeństwa” i zapytaniem ile zapłacisz?
Po zweryfikowaniu zazwyczaj okazuje się, że jakiś script-kiddie przeleciał automatem BurpSuite i znalazł słabe algorytmy TLS. Nic wartego uwagi.
Czy Twój produkt jest aż taki bezpieczny?
Szef pyta o ilość zgłoszeń z programu.
„Zero od kwartału? Dobra, zamykamy.”…
Sukces programu bug bounty wymaga ciągłego napływu „świeżej krwi” – rąk i par oczu mających nowe spojrzenie na Twój produkt.
Można to uzyskać otwierając prywatny program bug bounty dla społeczności.
Pamiętaj jasnym zdefiniowaniu polityki upublicznienia odkrytych podatności. Hakerzy bardziej od nagrody cenią sobie chwałę pierwszego odkrywającego podatność i możliwość opisania podatności.
Dodatkowe ręce do pracy napędza „Hall of Fame” – ranking najlepszych researcherów w Twoim projekcie.