Kiedy weryfikować tożsamość badaczy bug bounty?

Nie musisz znać nazwiska każdej osoby, która zgłasza lukę w publicznej stronie. Zanim jednak dasz komuś dostęp do wewnętrznego środowiska albo wypłacisz nagrodę, możesz potrzebować dodatkowej weryfikacji. To trzy osobne decyzje: kto może zgłaszać, kto może testować dany system i komu możesz zapłacić.

W programie ujawniania podatności (VDP) ustal te zasady przed zaproszeniem badaczy. Poniżej proponujemy cztery poziomy weryfikacji. Możesz stosować kilka naraz, zależnie od testowanych zasobów.

Co sprawdzasz i po co

Pod słowem „weryfikacja” kryją się różne czynności:

• Potwierdzenie tożsamości (IDV). Sprawdzenie, kto posługuje się danym kontem. Dostawca może porównać dokument ze zdjęciem lub nagraniem twarzy.
• Sprawdzenie warunków wypłaty. Dane odbiorcy, metoda płatności, wymagane dokumenty podatkowe i ewentualna kontrola sankcyjna. Obowiązki zależą od stron transakcji, kraju i sposobu płatności. Nie każda nagroda wymaga tego samego zestawu dokumentów.
• Sprawdzenie kwalifikacji i historii współpracy. Poprzednie zgłoszenia, referencje, doświadczenie lub test umiejętności. W niektórych programach dochodzi sprawdzenie niekaralności, jeśli prawo na to pozwala i jest ku temu uzasadnienie.

Te czynności nie zastępują się nawzajem. Dokument tożsamości nie potwierdza umiejętności technicznych, a wysoka reputacja nie daje uprawnienia do testowania dowolnego systemu.

Jak robią to platformy

HackerOne i Bugcrowd rozdzielają dostęp do poszczególnych programów, weryfikację tożsamości i warunki wypłaty. Wymagania mogą się zmieniać, dlatego przed wyborem platformy sprawdź zasady dla konkretnego rodzaju programu.

W HackerOne dodatkową weryfikację oferuje program Clear. Może ona obejmować sprawdzenie tożsamości i przeszłości badacza. Nie oznacza to, że każda osoba z kontem HackerOne przeszła taką kontrolę.

Według dokumentacji Bugcrowd weryfikacja tożsamości jest wymagana przed wysłaniem zgłoszenia do programów Managed Bug Bounty, publicznych i prywatnych, z wyjątkiem programów on-demand MBB. Otwarte przyjmowanie zgłoszeń nie musi więc oznaczać anonimowości, a prywatny program nie przesądza o zakresie weryfikacji.

Synack stosuje inny model: dobiera badaczy do Synack Red Team, sprawdza ich umiejętności i wiarygodność przed dopuszczeniem do testów. Kupujesz wówczas usługę z wyselekcjonowaną grupą, a nie sam formularz do przyjmowania zgłoszeń. Taki model może pasować do systemów wymagających ściśle kontrolowanego dostępu, ale wiąże się z innym kosztem i czasem organizacji.

Cztery poziomy weryfikacji

Poniższa tabela jest propozycją organizacji programu, a nie normą prawną ani opisem funkcji jednej platformy.

Zacznij od zakresu dostępu. Zgłoszenie błędu w publicznej dokumentacji nie wymaga takich samych uprawnień jak testy systemu płatności. Weryfikacja tożsamości nie zastąpi przy tym kont testowych, ograniczeń dostępu ani zakazu pobierania prawdziwych danych klientów.

Możesz przyjmować zgłoszenia publicznie i równolegle zapraszać wybranych badaczy do testów prywatnych. Dobre wcześniejsze zgłoszenia są podstawą do rozważenia zaproszenia. Sam wynik reputacji nie powinien automatycznie dawać dostępu do bardziej wrażliwego środowiska.

Tożsamość a upoważnienie do testów

Znajomość nazwiska badacza nie przesądza o legalności jego działań. Liczy się także to, czy miał zgodę na konkretny dostęp i czy przestrzegał warunków testów.

W sprawie United States v. Sullivan, dotyczącej ukrywania naruszenia bezpieczeństwa Ubera, amerykański sąd odrzucił argument, że późniejsza umowa mogła zmienić wcześniejszy nieuprawniony dostęp w autoryzowane testy. Opinia sądu nie ustanawia ogólnego obowiązku sprawdzania dokumentów wszystkich uczestników bug bounty. Dotyczy konkretnych faktów i amerykańskiego prawa.

Dla właściciela programu praktyczne znaczenie ma jasny zakres zgody: jakie systemy można testować, jakimi metodami, czego nie wolno robić i jak zgłaszać odkrycia. Opublikuj te warunki przed rozpoczęciem testów. Zapisy o ochronie badaczy działających zgodnie z zasadami, czyli safe harbor, wymagają dopasowania do prawa i programu. Samo włączenie formularza w aplikacji nie daje takiej ochrony.

Więcej o treści polityki znajdziesz w przewodniku po safe harbor i groźbach prawnych wobec badaczy bezpieczeństwa. Przy produktach sprzedawanych w UE sprawdź też obowiązki wynikające z Cyber Resilience Act.

Kiedy stosować zasady dla zewnętrznych wykonawców

Jeżeli nadajesz badaczowi konto w środowisku wewnętrznym, zastosuj podobne zasady jak wobec innych zewnętrznych specjalistów: wyznacz osobę odpowiedzialną za dostęp, jego zakres, termin wygaśnięcia i sposób odebrania uprawnień. Sprawdź kwalifikacje odpowiednie do zadania.

Nie zbieraj dokumentów tylko dlatego, że robi tak inna firma. Ustal, jakie ryzyko ma ograniczyć każda kontrola i kto będzie mógł zobaczyć zebrane dane. Oszustwa rekrutacyjne z udziałem północnokoreańskich pracowników IT pokazują znaczenie weryfikacji wykonawców, ale nie uzasadniają identycznej procedury wobec każdej osoby przesyłającej zgłoszenie.

Warunki wypłaty podaj przed przyjęciem zgłoszenia

W programach kryptowalutowych, takich jak te prowadzone przez Immunefi, warunki weryfikacji mogą zależeć od projektu. Badacz powinien wiedzieć przed rozpoczęciem pracy, czy do otrzymania nagrody potrzebny będzie dokument tożsamości i kto go przetworzy.

Ta sama zasada przydaje się przy nagrodzie 500 dolarów i przy wypłacie 5 milionów: opisz wymagania z wyprzedzeniem. Jeśli można zgłosić lukę pod pseudonimem, ale wypłata wymaga ujawnienia danych operatorowi płatności, napisz to wprost. Nie dodawaj takiego warunku dopiero po zaakceptowaniu zgłoszenia.

Co możesz zorganizować w Kit

Moduł CSIRT w Kit pozwala prowadzić program publiczny lub na zaproszenie, opublikować zakres i warunki, obsługiwać zgłoszenia oraz zapisywać decyzje o nagrodach. Profile badaczy i historia zgłoszeń pomagają zespołowi ocenić dotychczasową współpracę.

W procesie wypłat możesz wymagać zatwierdzonego dokumentu podatkowego. Kit nie jest jednak usługą sprawdzania tożsamości, sankcji ani niekaralności. Takie kontrole organizujesz osobno, jeśli są potrzebne. Zaproszenie do programu i zatwierdzenie nagrody pozostają decyzjami zespołu.

Sugestie AI dotyczące zgłoszeń, w tym poziomu ważności i możliwych duplikatów, wspierają ocenę techniczną. Nie potwierdzają tożsamości ani wiarygodności badacza.

Co ustalić przed uruchomieniem programu

1. Zakres testów. Wypisz zasoby, dozwolone działania i ograniczenia chroniące dane klientów.
2. Dostęp. Zdecyduj, które zgłoszenia przyjmujesz publicznie, a które testy wymagają zaproszenia lub umowy.
3. Weryfikację. Dla każdej kontroli określ cel, podstawę, zakres zbieranych danych i czas ich przechowywania.
4. Upoważnienie. Opublikuj warunki testów i safe harbor. Sprawdź ich treść z prawnikiem znającym prawo właściwe dla programu.
5. Wypłaty. Podaj wymagane dane i dokumenty, sposób zatwierdzania nagród oraz termin płatności.
6. Zmiany dostępu. Ustal, kto zaprasza badaczy do prywatnych testów i kiedy cofa zaproszenie.

Konfigurację opisujemy w tekście jak uruchomić program ujawniania podatności. Zasady wynagradzania znajdziesz w artykule o poziomach nagród bug bounty i zaufaniu badaczy.