Elementrica
03Realizacje04Referencje05Firma06Aktualności07Kontakt
PLENDE

Zakres testu penetracyjnego: jedna strona, która decyduje, czy test był wart pieniędzy

ElementricaElementrica7 min
Zakres testu penetracyjnego: jedna strona, która decyduje, czy test był wart pieniędzy

Black box czy grey box, reguły gry, metodyka i to, co świadomie zostaje poza zakresem. Rozkładamy na czynniki dokument, który zwykle podpisuje się w biegu, a który przesądza o całej reszcie.

„A sprawdziliście też portal dla partnerów?"

To pytanie pada zwykle jakieś trzy tygodnie po teście, na spotkaniu podsumowującym, kiedy raport jest już rozesłany, a większość osób zdążyła odetchnąć. I zwykle odpowiedź brzmi: nie, bo portalu dla partnerów nie było w zakresie. Nikt go nie wpisał. Nie dlatego, że ktoś zawinił, tylko dlatego, że przy ustalaniu zakresu wszyscy myśleli o głównej aplikacji, a portal partnerski żył sobie cicho na osobnej subdomenie, o której akurat nikt nie wspomniał.

I tu jest sedno, o którym rzadko mówi się na stronach usług: o wyniku testu penetracyjnego nie decyduje głównie to, jak dobry jest tester. Decyduje to, co wpiszecie w zakres, zanim tester w ogóle usiądzie do klawiatury.

Zakres brzmi jak formalność. Jest kontraktem o tym, co realnie sprawdzimy

Zakres to najmniej efektowne słowo w tej branży. Kojarzy się z załącznikiem, który podpisuje się w biegu, żeby przejść do ciekawszej części z „hakowaniem". A w praktyce to on wyznacza granicę: co jest w grze, a co poza nią. Co przetestujemy naprawdę, a czego świadomie nie dotkniemy.

Problem w tym, że atakujący nie dostał kopii Twojego zakresu. Jego nie obowiązuje lista assetów, którą ustaliłeś na spotkaniach. On wejdzie tam, gdzie jest najsłabiej, a niekoniecznie tam, gdzie było wygodnie zmieścić test w budżecie. Dlatego zakres, który nie odzwierciedla tego, jak myśli napastnik, potrafi dać Ci raport z zielonym podsumowaniem i jednocześnie zerowe realne pokrycie tam, gdzie naprawdę boli.

Za wąsko czy za szeroko? Obie skrajności mają swój koszt

Wąski zakres ma zaletę: tester wchodzi głęboko, rozbiera jedną aplikację na części pierwsze, znajduje rzeczy, których żaden automat nie dotknie. Ma też wadę: jeśli granicę wyznaczono w złym miejscu, cała ta głębia jest po sąsiedzku od prawdziwych drzwi.

Szeroki zakres ma odwrotny bilans. „Przetestuj wszystko" brzmi bezpiecznie, dopóki nie zestawisz tego „wszystkiego" z liczbą dni w harmonogramie. Pięć dni na całą infrastrukturę to nie test penetracyjny, to raczej szybki spacer z latarką. Dotkniesz wielu rzeczy, ale żadnej na tyle mocno, żeby to coś znaczyło.

Granica nie przebiega tam, gdzie kończy się budżet. Przebiega tam, gdzie realnie mógłby wejść ktoś, kto ma wobec Was złe zamiary.

Co znaleźliśmy poza zakresem (i dlaczego to boli podwójnie)

Konkret z życia. Klient zamówił test aplikacji produkcyjnej. Świadomie, rozsądnie, z jasną listą. Poza zakresem została subdomena z panelem raportowym, traktowana jako „wewnętrzne narzędzie, mało kto o nim wie".

Przy okazji, całkiem legalnie, w ramach rekonesansu, natrafiliśmy na to narzędzie z internetu. Jeden z jego endpointów zwracał dane po numerze identyfikatora, bez sprawdzania, czyje one są. Podmiana numeru w zapytaniu i wypływały raporty innego najemcy platformy.

Po technicznej stronie to klasyczny broken access control. Po biznesowej to wyciek danych między klientami, złamanie umowy o poufności i temat na zgłoszenie do UODO. Formalnie było to poza zakresem, więc w raporcie trafiło do osobnej sekcji „poza zakresem, ale trzeba to zobaczyć". Gdyby granicę postawiono kilka metrów dalej, byłoby to znalezisko numer jeden, a nie przypis.

Morał nie brzmi „testuj wszystko za każdą cenę". Brzmi: przy wyznaczaniu granicy zapytaj najpierw, gdzie realnie leżą Twoje dane, a nie gdzie leży wygodna linia w umowie.

Co powinno siedzieć w dobrym zakresie

Jeśli macie w ręku propozycję testu, ten fragment jest dla osób, które będą go czytać najuważniej. Dobry zakres odpowiada na siedem pytań:

  • Co dokładnie testujemy. Konkretne domeny, adresy IP, aplikacje webowe, API, aplikacje mobilne. Nazwane z osobna. „Cała firma" to nie zakres, to intencja.
  • Z jakiej perspektywy. Black box (tester zaczyna jak ktoś z ulicy, bez wiedzy), grey box (dostaje konto i trochę kontekstu), white box (dostaje dokumentację i kod). To decyduje, ile realnie zdąży sprawdzić w tym samym czasie. Bez wiedzy wstępnej połowa engagementu schodzi na rozpoznanie, które grey box skraca do minut.
  • Skąd atakujemy. Z internetu czy od środka sieci. Z kontem użytkownika czy bez. Inny scenariusz to inny wynik, a „z zewnątrz i z wewnątrz" to dwa osobne testy, nie jeden dłuższy.
  • Reguły gry (rules of engagement). Kiedy testujemy, czy wolno socjotechnikę, czy w ogóle dotykamy produkcji czy kopii, jaki jest zasięg skutków i kto odbiera telefon, jeśli coś zacznie się dziać. Ten punkt najczęściej ratuje wszystkim nerwy.
  • Metodyka. PTES, OWASP (WSTG dla web, MASTG dla mobile), NIST. Chodzi o to, żeby wynik był powtarzalny i sprawdzalny, a nie zależny od tego, na co danego dnia miał ochotę konkretny tester.
  • Czas, czyli ile osobodni. To nie detal administracyjny, tylko realny sufit tego, jak głęboko da się wejść. Uczciwy dostawca powie Ci wprost, kiedy budżet nie domyka zakresu, zamiast rozcieńczać test do skanu z ładniejszą okładką.
  • Co dostajesz na końcu. Raport z dowodami, priorytetami ryzyka i konkretną ścieżką naprawy, plus retest po wdrożeniu poprawek. Bez retestu nie wiesz, czy dziura naprawdę zniknęła, czy tylko przestała być widoczna z tego jednego kąta.

Zwróć uwagę, że równie ważna jak lista „co w środku" jest lista „co poza". Świadome wycięcie czegoś z zakresu to decyzja biznesowa. Nieświadome pominięcie to luka, o której dowiesz się od kogoś innego.

Zakres a DORA i NIS2: audytora interesuje nie tylko to, że test był

Jeśli robicie test pod obowiązki regulacyjne, jest jeszcze jeden powód, żeby nie podchodzić do zakresu po macoszemu. DORA i NIS2 wymagają regularnego testowania, ale audytor patrzy też na to, co faktycznie testowano. Zakres wycięty do jednej aplikacji nie zamyka obowiązku dla całej infrastruktury krytycznej. Raport, który świetnie wygląda, ale pokrywa ułamek tego, co regulator uzna za istotne, w rozmowie z audytorem broni się słabo. Zakres to miejsce, w którym zgodność zaczyna się albo sypie, na długo przed pierwszą linijką znaleziska.

Na koniec

Zakres brzmi jak zadanie domowe. Dokument o granicach, który łatwo podpisać nie czytając, żeby wreszcie ruszyć z testem. A to właśnie ta jedna strona rozstrzyga, czy dostaniecie mapę realnych dziur, czy uprzejmy PDF z zielonym podsumowaniem, obok którego prawdziwe drzwi stoją nieruszone.

Skoro doczytałeś akapit o formalnościach aż tutaj, to prawdopodobnie należysz do tych, którzy czytają też załączniki do umów. Rzadka i praktyczna cecha w tej robocie. Pytanie na koniec: kiedy ostatnio ktoś zajrzał do zakresu Twojego ostatniego testu i policzył na spokojnie, co tak naprawdę zostało poza nim?

Chcecie zobaczyć, jak wygląda to w praktyce? Zobacz przykładowy zakres testu - realny, zanonimizowany dokument, na którym widać, jak wyznaczamy granicę i co wpisujemy do sekcji „poza zakresem".

Wolisz od razu pogadać o swoim przypadku? Umów bezpłatną konsultację. 30 minut, bez zobowiązań, rozmowa z konsultantem. Wyjdziesz z niej z pierwszym szkicem sensownego zakresu, niezależnie od tego, czy zdecydujesz się na test u nas.

Pierwszy szkic sensownego zakresu w 30 minut

Umów bezpłatną konsultację. Rozmowa z konsultantem - wyjdziesz z propozycją zakresu dopasowaną do Twojego przypadku.

Poprzedni
Zakres testu penetracyjnego
Następny
Wystarczył jeden link, żeby Twój Copilot zaczął pracować dla kogoś innego