Testy penetracyjne i bug bounty: gdzie kończy się zgoda właściciela systemu

Dobre intencje nie zastępują podstawy prawnej

Celem pentestingu jest wykrycie słabości zabezpieczeń przed atakiem. Jednak od strony prawa należy odróżnić autoryzowany audyt od samodzielnego penetrowania cudzej infrastruktury bez zezwolenia. W określonych okolicznościach znaczenie mogą mieć przepisy Kodeksu karnego dotyczące nieuprawnionego dostępu do informacji lub systemów, a także obowiązki zachowania poufności. Dlatego audyt powinien zaczynać się od dokumentacji zakresu zgody, a nie od pierwszego skanu.

Co powinno obejmować upoważnienie

Przed testem należy wskazać konkretne domeny, adresy IP, aplikacje i środowiska, a także właściciela upoważnionego do udzielenia zgody. Należy określić dopuszczalne techniki, wyłączenia, czas, limit intensywności i zasady reagowania na awarie. Szczególne znaczenie ma to, czy test dotyczy produkcyjnego środowiska z danymi klientów oraz czy może mieć skutki dla innych podmiotów współkorzystających z infrastruktury.

Właściciel aplikacji nie zawsze może zezwolić na wszystko

Strona internetowa może działać na infrastrukturze dostawcy hostingu, operatora płatności lub zewnętrznej platformy SaaS. Zgoda przedsiębiorcy prowadzącego serwis nie musi automatycznie obejmować atakowania sąsiednich systemów albo mechanizmów należących do dostawcy usługi. Audytor powinien przeanalizować warunki outsourcingu i granice kontroli klienta nad poszczególnymi komponentami. W przeciwnym razie test może naruszyć prawa osób trzecich.

Bug bounty i odpowiedzialne ujawnianie

Program bug bounty powinien wyraźnie określać dopuszczalne badania, zasady wypłaty nagrody, wymogi zgłoszenia i status uczestnika. Polityka coordinated vulnerability disclosure może pomóc w bezpiecznym przekazywaniu informacji o lukach. Brak oficjalnego programu nie oznacza, że tester ma swobodę wykorzystania podatności dla udowodnienia jej istnienia. Należy unikać publicznego ujawniania szczegółów technicznych zanim organizacja zdoła wdrożyć odpowiednie zabezpieczenia.

Granice dowodu podatności

Niekiedy do wykazania błędu wystarczy minimalna demonstracja, nie zaś masowe pobieranie rekordów klientów. Zasada minimalizacji ma tu znaczenie zarówno etyczne, jak i prawne. Jeśli tester nieoczekiwanie uzyska dostęp do danych wrażliwych, powinien przerwać czynności, zabezpieczyć potrzebne informacje w minimalnym zakresie i postępować według ustalonej procedury incydentowej. Dokumentacja dowodowa nie może stać się pretekstem do dalszej eksfiltracji.

RODO w ramach audytu technicznego

Testy mogą obejmować przetwarzanie danych osobowych, logi, konta pracowników oraz informacje klientów. Trzeba określić role stron, ewentualną umowę powierzenia i zasady retencji artefaktów. Wykonawca powinien ograniczyć kopiowanie baz, odpowiednio szyfrować raporty i przekazywać je przez bezpieczne kanały. W razie niezamierzonego naruszenia ochrony danych może być konieczna analiza obowiązków wynikających z RODO, niezależnie od tego, że działania wykonywano w ramach audytu bezpieczeństwa.

Umowa powinna rozdzielać badanie i odpowiedzialność

Klauzule kontraktowe powinny określać odpowiedzialność za przestój, limity testu obciążeniowego, sposób zatrzymania działań na żądanie klienta oraz obowiązki odtworzenia środowiska. Nie należy obiecywać, że pentest zapewni bezwarunkowe bezpieczeństwo systemu. Raport powinien precyzyjnie wskazywać zakres i ograniczenia badania oraz ryzyka, których nie oceniano. Dobrą praktyką jest niezależna weryfikacja usunięcia najpoważniejszych podatności.

Ocena ryzyka operacyjnego

Test prowadzony na produkcji może nieumyślnie unieruchomić usługę publiczną, proces rozliczeń albo system opieki zdrowotnej. Dlatego przed uruchomieniem należy określić okna serwisowe, osoby kontaktowe, procedurę awaryjnego zatrzymania i możliwe środki ograniczające skutki. Testowanie odmowy usługi oraz technik inwazyjnych wymaga szczególnej zgody. Bez odpowiedniego planu można wyrządzić szkodę większą niż potencjalna korzyść z wykrycia błędu.

Luki zgłaszane przez osoby niezamówione

Przedsiębiorstwo może otrzymać zgłoszenie od niezależnego badacza bez wcześniej zawartej umowy. Reakcja powinna łączyć ochronę systemu z rozsądną oceną zachowania zgłaszającego. Nie każda informacja o luce dowodzi przestępstwa, ale też samo określenie się jako „ethical hacker” nie usuwa odpowiedzialności za działania poza dopuszczalnymi granicami. Warto ocenić fakty, zakres użytych technik i ewentualne naruszenie danych, unikając pochopnych kwalifikacji.

Jak przygotować profesjonalny raport

Raport powinien opisywać środowisko, zakres upoważnienia, metodologię, wyniki weryfikacji, poziom ryzyka, dowody w odpowiednio zanonimizowanej postaci i rekomendacje naprawcze. Należy wskazać, czy podatność została potwierdzona, czy stanowi hipotezę. Osobno trzeba omówić luki procesowe, takie jak nadmierne uprawnienia administracyjne lub brak aktualizacji. Celem jest realna poprawa bezpieczeństwa, nie jedynie lista technicznych narzędzi wykorzystanych w teście.

Kto może skutecznie udzielić upoważnienia

W większej organizacji nie każdy administrator systemu ma kompetencję do zawarcia umowy na test inwazyjny. Przedsiębiorca powinien ustalić, kto jest uprawniony do reprezentacji i kto może dopuścić czasowy wzrost ryzyka technicznego. W przypadku usług outsourcingowych zgoda może wymagać również stanowiska dostawcy platformy albo operatora infrastruktury. Upoważnienie najlepiej sformułować tak, aby tester mógł je okazać w razie nieporozumienia, a firma miała dokumentację akceptacji zakresu badania.

Procedura eskalacji po znalezieniu krytycznej luki

Jeżeli audytor znajdzie podatność umożliwiającą odczyt dużego zbioru danych, powinien znać bezpieczny sposób jej zgłoszenia i granice dalszego badania. Celem nie jest maksymalizacja liczby pobranych rekordów, ale weryfikacja ryzyka. Organizacja powinna wskazać kontakt awaryjny, sposób przechowywania dowodów i termin ograniczenia ekspozycji systemu. W razie incydentu wymagającego analizy RODO albo innych regulacji trzeba zachować odrębną procedurę oceny obowiązków zgłoszeniowych.

Szyfrowanie raportu i retencja artefaktów

Raporty pentestowe zawierają instrukcje wykorzystywania wykrytych słabości, dane konfiguracji i czasami przykładowe informacje klientów. Powinny być przekazywane bezpiecznym kanałem i dostępne wyłącznie osobom rzeczywiście odpowiedzialnym za naprawę. Umowa powinna wskazywać okres przechowywania materiału przez wykonawcę i zasady jego usunięcia po zakończeniu zlecenia. Nie jest właściwą praktyką zamieszczanie szczegółów krytycznej podatności w publicznym portfolio audytora bez odpowiedniego uzgodnienia i oceny bezpieczeństwa.

Powiązane analizy

Cyberincydent a odpowiedzialność zarządu · Phishing i nieautoryzowany przelew