Pytania o testy penetracyjne

Skan podatności to automat: porównuje wersje usług i konfiguracje z bazą znanych słabości i zwraca listę potencjalnych problemów. Test penetracyjny to praca człowieka, który te problemy weryfikuje — sprawdza, czy podatność da się faktycznie wykorzystać, z jakiego miejsca sieci i z jakim skutkiem. W praktyce ze skanu zostaje po weryfikacji kilkanaście procent pozycji. Reszta to szum, który podnosi koszt napraw, bo zespoły zaczynają od fałszywych alarmów.

Dlatego test robi się raz na rok lub dwa, a skanem można go uzupełniać między testami — pod warunkiem, że ktoś czyta jego wyniki krytycznie, a nie przepisuje ich do zadań.

Czas zależy od zakresu i liczę go w godzinach pracy testera, nie w dniach kalendarzowych. Dla typowego środowiska wariant identyfikacyjny to kilkanaście do kilkudziesięciu godzin, wariant z weryfikacją podatności — dwa do trzech razy tyle, bo każda podatność wymaga potwierdzenia i opisania ścieżki wykorzystania.

W kalendarzu przyjmuję około 30 godzin pracy tygodniowo, więc dwutygodniowy test o zakresie 60 godzin jest realny. Konkretny harmonogram podaję w zapytaniu — orientacyjny czas dla różnych rozmiarów środowiska jest w sekcji wyceny.

To pytanie zadaje mi każdy klient i odpowiedź brzmi: ryzyko istnieje, ale jest zarządzane, a nie przemilczane. Testy prowadzę z ograniczeniami ustalonymi przed startem: lista technik dozwolonych i wykluczonych, okna czasowe, wyłączone z zakresu hosty i usługi krytyczne.

Przed każdą akcją o potencjalnie destrukcyjnym charakterze — na przykład przy próbach przeciążeniowych albo eksploatacji podatności typu denial of service — pytam o zgodę, a jeśli nie ma jak potwierdzić jej na bieżąco, takiej akcji nie wykonuję i opisuję ją w raporcie jako podatność potwierdzoną pośrednio. Aktywną eksploatację prowadzę tylko w wariancie, w którym wyraźnie Państwo na to pozwalają.

To zależy od wariantu i od tego, co chcecie Państwo zmierzyć. Test „z zewnątrz”, bez konta, odpowiada na pytanie, jak daleko dojdzie ktoś, kto nie ma żadnych uprawnień — to scenariusz intruza, który przejął stację roboczą.

Test z kontem zwykłego użytkownika pokazuje, jak szybko z takiego konta da się podnieść uprawnienia w domenie. Konto administratora potrzebne jest tylko do badania ścieżek, które zaczynają się dopiero na tym poziomie. W praktyce proszę o konto dedykowane dla testera, z nazwą wskazującą cel (na przykład pentest-sezon), żeby było jednoznacznie widoczne w logach i łatwe do odebrania po zakończeniu prac.

Otrzymują Państwo dwa dokumenty. Raport wykonawczy jest dla zarządu i osób decyzyjnych: streszczenie, ryzyko w kontekście biznesowym, priorytety napraw i szacunek pracy potrzebnej do zamknięcia ustaleń. Raport techniczny jest dla zespołu IT: opis każdego ustalenia, dowód w postaci zrzutów lub fragmentów odpowiedzi, ścieżka odtworzenia i rekomendowana poprawka.

Do tego zwykle dodaję tabelę wykrywalności — czy Państwa monitoring zauważył daną aktywność i po jakim czasie. To informacja, której nie da żaden skan, a która pokazuje realną wartość posiadanych narzędzi.

Dane zbieram wyłącznie w zakresie potrzebnym do wykonania testu i opisania ustaleń. Nie kopiuję baz danych, nie wynoszę zbiorów osobowych, a jeśli w trakcie pracy natrafię na dane osobowe w dowodzie — zamazuję je w raporcie. Wszystkie materiały przechowuję zaszyfrowane i usuwam po uzgodnionym okresie, zwykle 90 dni po przekazaniu raportu.

Pracuję na umowie powierzenia przetwarzania danych i z zachowaniem poufności. Jeśli Państwa organizacja wymaga umowy NDA przed przekazaniem zakresu — podpisuję ją, to standard. Zwrot lub trwałe usunięcie pozostałych materiałów potwierdzam pisemnie.

Test wykonuję wyłącznie na podstawie pisemnego upoważnienia do działania w Państwa sieci, z określonym zakresem adresów, systemów i terminem ważności. Bez takiego dokumentu nie rozpoczynam pracy — dotyczy to również testów zdalnych.

W polskim prawie kluczowy jest art. 267 i nast. Kodeksu karnego oraz przepisy o ochronie danych, więc granice zakresu opisujemy precyzyjnie: co wolno, czego nie wolno i do kiedy. Upoważnienie podpisuje osoba umocowana do reprezentowania organizacji — przygotowuję wzór, jeśli Państwo go nie mają.

Nie musi, ale bywa to wygodne. Testy sieci wewnętrznej prowadzę tak, żeby nie zakłócać pracy zespołu: w godzinach roboczych są to działania o niskim ryzyku wpływu na wydajność, a akcje bardziej agresywne planuję w oknach serwisowych. Jeśli Państwo wolą, żeby całość szła poza godzinami pracy — zaplanuję to, tylko wydłuży to kalendarz realizacji.

Jest jeszcze jedna korzyść z pracy w godzinach roboczych: widzimy, czy Państwa zespół i narzędzia reagują na nietypowy ruch wtedy, kiedy operacyjnie powinny.

Zalecam poinformowanie wąskiego kręgu osób, które muszą wiedzieć — administratorów, działu bezpieczeństwa i osób pierwszego kontaktu, żeby nie zgłaszały fałszywych incydentów. Szerokiej informacji do wszystkich pracowników zwykle nie zalecam, bo zmienia zachowanie użytkowników i zaniża wyniki testu socjotechnicznego, jeśli jest prowadzony równolegle.

Test penetracyjny infrastruktury nie wymaga wiedzy pracowników: nikt nie odczuje, że trwa. Jedyny wyjątek to test dnia zero, w którym z góry ustalamy osobę po stronie Państwa, która może zablokować akcję w razie wątpliwości.

Zgłaszam ją natychmiast, w dniu wykrycia, bez czekania na raport — osobie wskazanej w zakresie, drogą ustaloną przed startem, przy ustalonej formie kontaktu awaryjnego. Jeśli istnieje ryzyko utraty danych lub przerwy w działaniu, wstrzymuję dalszą eksploatację tego wątku i opisuję go w raporcie od strony wpływu, nie techniki wykorzystania.

Dopiero po zamknięciu krytycznych ustaleń przechodzę do części mniej pilnych. W praktyce znacząca część mojej pracy polega na odsiewaniu problemów, które wyglądają groźnie, od tych, które realnie pozwalają wejść do sieci.

Nie. Test sieci wewnętrznej startuje z punktu, który znają Państwo: dostaję zakres, adresy, a często konto i informację o strukturze. Dnia zero to scenariusz domniemanego naruszenia — startuję z jednego nieznanego urządzenia podłączonego do sieci i bez wiedzy o środowisku, tak jak zrobiłby to intruz, który wszedł na teren lub podłączył się do gniazda w sali konferencyjnej.

Różnica jest w wartości informacyjnej: pierwszy test mówi, co jest podatne, a drugi — jak daleko intruz dojdzie, zanim Państwa monitoring to zauważy. Opisuję to osobno w teście dnia zero.

Audyt zgodności i test penetracyjny to dwie różne rzeczy i jedna nie zastępuje drugiej. Audyt ocenia spełnianie wymagań organizacyjnych i dokumentacyjnych, a wynikiem jest raport zgodności. Test penetracyjny dostarcza dowodu technicznego: pokazuje, jak faktycznie wygląda skuteczność środków technicznych.

Dla podmiotów objętych wymogami KSC i dla jednostek KRI test bywa elementem materiału dowodowego — zwłaszcza w obszarze zarządzania podatnościami i kontroli dostępu. Zestawienie tego, czego wymagają przepisy, z tym, co widzę w sieci, opisuję w osobnych serwisach: dostosowanie do wymogów KSC i audyty zgodności.

Tak — i dla większości środowisk jest to wystarczające. Test zdalny prowadzę z mojego komputera, z dostępem przez VPN albo w tunelu do sieci klienta, po zabezpieczeniu połączenia kluczami i adresacją VPN. Większość technik nie wymaga obecności na miejscu, bo liczy się dostęp sieciowy, nie fizyczny.

Obecność na miejscu ma sens w dwóch przypadkach: gdy trzeba sprawdzić sieć bezprzewodową w wielu lokalizacjach (pomiary radiowe), albo gdy scenariusz zakłada fizyczne podłączenie urządzenia — jak w teście dnia zero. Wtedy dostarczam sprzęt, montuje go Państwa zespół według mojej instrukcji, a ja pracuję dalej zdalnie.

Test wyceniam stawką 250 zł netto za godzinę pracy, a czas liczę jawnym wzorem zależnym od zakresu — liczby godzin dla typowych środowisk są w sekcji wyceny. Taniej można wtedy, gdy zakres jest wąski i dobrze opisany: lepiej zbadać dokładnie mniejszy obszar niż pobieżnie całe środowisko.

Drugą oszczędnością jest retest — po naprawach nie trzeba powtarzać całego testu, wystarczy sprawdzenie zgłoszonych punktów. Trzecią: przekazanie dokumentacji sieci przed testem, bo rozpoznanie jest wtedy krótsze. Najgorszym oszczędzaniem jest pomijanie weryfikacji podatności: raport pełen niesprawdzonych pozycji nie porządkuje napraw.