Black box, white box czy grey box – który model testu wybrać?

Black box, white box i grey box to trzy modele testu bezpieczeństwa, które różnią się przede wszystkim zakresem wiedzy, jaką tester otrzymuje o testowanym środowisku przed rozpoczęciem pracy – od pełnej anonimowości napastnika z zewnątrz, przez częściowy dostęp do informacji, po pełny wgląd w architekturę i kod. Wybór modelu wpływa bezpośrednio na to, jaki rodzaj podatności zostanie wykryty, ile czasu zajmie test i jak realistycznie odwzoruje on rzeczywisty atak.

Decyzja o wyborze wariantu ma znaczenie praktyczne dla każdej organizacji zamawiającej testy penetracyjne – błędnie dobrany model może pominąć krytyczne luki albo niepotrzebnie wydłużyć projekt bez proporcjonalnej korzyści.

W tym artykule pokazujemy, czym różnią się black box, white box i grey box testing, czego każdy z nich nie wykrywa, oraz jakie kryteria – cel testu, dojrzałość zabezpieczeń, dostępny czas i wymagania regulacyjne takie jak RODO, DORA czy ISO 27001 – pozwalają dobrać model do konkretnej sytuacji.

Black box testing – na czym polega test bez wiedzy o systemie?

Black box testing, czyli test czarnej skrzynki, to model testu bezpieczeństwa, w którym tester nie ma żadnej wcześniejszej wiedzy o architekturze, kodzie ani infrastrukturze ocenianego środowiska – działa wyłącznie na podstawie tego, co widoczne jest z zewnątrz, tak jak zrobiłby to nieznający systemu napastnik. Architektura testowania czarnej skrzynki opiera się właśnie na tym ograniczeniu dostępu do informacji, dzięki czemu wynik testu odzwierciedla realne ryzyko, jakie organizacja ponosi wobec anonimowego atakującego z zewnątrz.

Test black box – co to jest i jak wygląda w praktyce?

Test black box wywodzi się z testowania oprogramowania (QA), gdzie od dekad służy do sprawdzania funkcjonalności aplikacji bez znajomości jej wewnętrznego kodu – stąd inna nazwa tego podejścia, testowanie behawioralne, skupione wyłącznie na tym, jak system testowany (SUT) reaguje na konkretne dane wejściowe. W testowaniu oprogramowania do projektowania przypadków testowych wykorzystuje się różne techniki testowania:

• analizę wartości brzegowych (nazywaną też analizą wartości granicznych),
• partycjonowanie ekwiwalentne (podział ekwiwalentny, czyli grupowanie danych wejściowych w klasy o podobnym zachowaniu),
• testowanie tabeli decyzyjnej,
• testowanie przejść stanów,
• zgadywanie błędów oparte na doświadczeniu testera. 

Każda z tych metod inaczej definiuje oczekiwany wynik, określany jako Test Oracle, względem którego porównuje się faktyczne odpowiedzi systemu i funkcjonalność aplikacji.

W testowaniu oprogramowania techniki te obejmują również walidację wejścia oraz walidację wejścia-wyjścia, a także walidację interfejsu użytkownika (UI), która sprawdza, czy warstwa wejściowa i warstwa wyjściowa aplikacji działają zgodnie ze specyfikacją z perspektywy użytkownika końcowego. Testowanie funkcjonalne, eksploracyjne i losowe pozwala dodatkowo wychwycić problemy z użytecznością, zanim aplikacja trafi do produkcji, choć to już zagadnienia z obszaru testowania aplikacji, a nie testów bezpieczeństwa.

W testach bezpieczeństwa ten sam model wygląda inaczej. Tester dysponuje minimalną wiedzą techniczną o organizacji – najwyżej nazwą firmy i adresem domeny – i musi samodzielnie zbudować obraz infrastruktury, zanim w ogóle przystąpi do prób ataku. Punktem wyjścia jest wtedy to, co o organizacji można ustalić z otwartych źródeł – ten sam materiał, na którym opiera się biały wywiad (OSINT). Dopiero na tej podstawie tester identyfikuje typy testowania czarnej skrzynki adekwatne do celu – od testów sieciowych po testy aplikacji webowych czy mobilnych.

Kiedy warto wybrać black box testing do oceny bezpieczeństwa?

Black box testing sprawdza się najlepiej wtedy, gdy organizacja chce poznać realny obraz swojego bezpieczeństwa z perspektywy zewnętrznego, nieuprzywilejowanego napastnika – bez założenia, że atakujący dysponuje jakąkolwiek wiedzą wewnętrzną. To naturalny wybór w kilku sytuacjach:

• to pierwszy test penetracyjny w organizacji i celem jest ogólna ocena odporności na atak z zewnątrz,
• priorytetem jest sprawdzenie, co realnie widać i co da się wykorzystać bez dostępu do dokumentacji czy kont testowych,
• budżet lub termin nie pozwalają na głębszą analizę architektury, a wystarczający jest obraz ryzyka z perspektywy zewnętrznej.

Ograniczenia testowania czarnej skrzynki wynikają wprost z braku wiedzy testera – część czasu projektu pochłania sam rekonesans, przez co pokrycie testu bywa węższe niż w modelach z dostępem do kodu czy infrastruktury, a błędy logiczne ukryte głęboko w aplikacji mogą pozostać niewykryte. Black box, podobnie jak pozostałe modele testu technicznego, nie obejmuje też warstwy ludzkiej organizacji – nie sprawdza, czy pracownicy rozpoznają próbę manipulacji, dlatego wiele firm uzupełnia go Praktycznym Treningiem Antyphishingowym Secawa, który mierzy tę część ryzyka niezależnie od wyników testu technicznego.

White box testing – jak przebiega test z pełnym dostępem do systemu?

White box testing to model testu bezpieczeństwa, w którym tester otrzymuje pełny dostęp do dokumentacji architektury, kodu źródłowego oraz kont testowych ocenianego systemu, zanim rozpocznie właściwą analizę. Testowanie wewnętrzne tego typu pozwala ocenić bezpieczeństwo aplikacji znacznie głębiej niż z perspektywy zewnętrznego atakującego, bo tester nie musi odgadywać architektury metodą prób i błędów – a wybrany model wpływa na to, jak krok po kroku przebiega test penetracyjny, zwłaszcza na etapie rekonesansu, który w tym wariancie jest znacznie krótszy.

Jakie informacje i uprawnienia otrzymuje tester w modelu white box?

W modelu white box tester otrzymuje zestaw materiałów i uprawnień od klienta, które pozwalają ocenić bezpieczeństwo od wewnątrz, a nie tylko z perspektywy efektu końcowego widocznego na zewnątrz. Zakres udostępnianych informacji obejmuje zwykle:

• dokumentację architektury systemu wraz z opisem integracji pomiędzy poszczególnymi komponentami,
• dostęp do kodu źródłowego, co umożliwia code review i analizę tego, jak aplikacja obsługuje błędy oraz nietypowe dane wejściowe,
• konta testowe o różnych poziomach uprawnień, dzięki czemu można sprawdzić, czy separacja ról rzeczywiście działa zgodnie z założeniami,
• wymagania systemu i specyfikacje funkcjonalne, które pozwalają zweryfikować, czy zabezpieczenia odpowiadają realnym wymaganiom biznesowym, a nie tylko ogólnym dobrym praktykom.

Taki poziom dostępu ma znaczenie zwłaszcza tam, gdzie o bezpieczeństwie aplikacji decyduje nie tylko pojedyncza podatność, ale też integracja systemu z innymi usługami – błąd w miejscu łączenia dwóch komponentów bywa trudny do wykrycia bez wglądu w kod po obu stronach. Dlatego white box dobrze sprawdza się na etapie wytwarzania oprogramowania, zanim błędy trafią do środowiska produkcyjnego – to obszar, w którym pomocne bywają konsultacje SSDLC, pozwalające wychwycić podatności jeszcze przed wdrożeniem.

Black box a white box – różnice w zakresie, czasie i dokładności testów

Black box a white box różnice widać najwyraźniej w trzech wymiarach: ile tester wie na starcie, ile czasu zajmuje test i jak dokładne jest pokrycie testów. Poniższe zestawienie pokazuje to praktycznie:

Wybór wariantu wpływa też na wycenę projektu, bo szerszy dostęp i głębsza analiza kodu wymagają więcej godzin pracy zespołu – co wpływa na cenę testów penetracyjnych opisujemy szerzej w osobnym artykule, tutaj warto jedynie zaznaczyć, że white box zwykle oznacza wyższy nakład pracy niż porównywalny zakresowo black box.

Głębsze pokrycie testów w modelu white box ma znaczenie zwłaszcza tam, gdzie liczy się nie tylko wykrycie luki, ale też ocena wydajności i niezawodności systemu pod obciążeniem błędnych danych, a niekiedy również testy niefunkcjonalne sprawdzające, czy aplikacja zachowuje się przewidywalnie w warunkach brzegowych. Ponieważ tester ma wgląd w kod, dostęp do niego bywa ograniczany dodatkowymi klauzulami poufności – ochrona własności intelektualnej klienta jest tu równie ważna jak sam wynik testu. Z perspektywy organizacji efektywność kosztowa całego projektu zależy więc od tego, czy głębsze pokrycie faktycznie odpowiada poziomowi ryzyka danego systemu, czy jest nadmiarowe względem realnych potrzeb.

Sam proces testu white box, mimo że dotyczy bezpieczeństwa, a nie jakości oprogramowania, korzysta z podobnej dyscypliny organizacyjnej. Zespół ustala plan testowania i zakres wraz z klientem, definiuje procedury testujące dla poszczególnych komponentów, dobierając przy tym narzędzia do testowania dostępne na rynku i dopasowane do konkretnej technologii. Wykonanie testów kończy się analizą wyników, weryfikacją wymagań funkcjonalnych pod kątem bezpieczeństwa oraz dokumentowaniem błędów w raporcie, który część organizacji integruje z własnymi systemami zarządzania błędami, by śledzić status poprawek razem z innymi zgłoszeniami technicznymi. Ocena obejmuje wtedy nie tylko pojedyncze podatności, ale też niezawodność systemu jako całości.

Grey box testing – kompromis między black box a white box

Grey box testing (gray box testing) to model testu bezpieczeństwa łączący cechy black box i white box – tester dysponuje częściową wiedzą o systemie, wystarczającą, by pracować efektywniej niż przy zerowym dostępie, ale bez pełnego wglądu w kod i architekturę, jaki zapewnia white box. To podejście najczęściej stanowi punkt wyjścia do rozmowy o zakresie testu, bo pozwala łączyć realizm ataku zewnętrznego z częścią korzyści płynących z wiedzy wewnętrznej.

Na czym polega grey box testing i czym różni się od pozostałych modeli?

Grey box testing, w testach bezpieczeństwa, oznacza sytuację, w której tester otrzymuje wiedzę częściową o testowanym środowisku – wystarczającą, by ograniczyć czas poświęcony na czysty rekonesans, ale nie na tyle szeroką, by mówić o pełnym dostępie do kodu czy dokumentacji. Może to oznaczać konto testowe o standardowych uprawnieniach użytkownika, ogólny schemat architektury bez szczegółów implementacyjnych albo wiedzę o tym, z jakich technologii korzysta aplikacja, bez wglądu w sam kod.

W odróżnieniu od black box, grey box nie wymaga od testera odgadywania całej architektury od zera, a w odróżnieniu od white box nie daje pełnego wglądu w logikę wewnętrzną każdego komponentu. Model ten sprawdza się szczególnie przy testowaniu systemów złożonych z wielu integracji, gdzie liczy się nie tylko pojedyncza podatność, ale też kompatybilność poszczególnych elementów – błędy i problemy ujawniają się często właśnie na styku dwóch usług, a nie wewnątrz jednej z nich.

Grey box czy gray box testing – który model testu wybrać?

Grey box czy gray box testing – to pytanie o pisownię, nie o różne modele testu: „grey” to zapis brytyjski, „gray” to wariant amerykański, a oba określają dokładnie to samo podejście testowe, oparte na częściowej wiedzy testera o systemie. Wybór między black box, white box i grey box nie sprowadza się jednak do nazewnictwa, tylko do dopasowania modelu do sytuacji organizacji. Warto wziąć pod uwagę:

• cel testu – czy priorytetem jest realistyczna symulacja ataku zewnętrznego, dogłębna analiza kodu, czy złoty środek między nimi,
• dojrzałość zabezpieczeń – organizacje na wczesnym etapie budowania bezpieczeństwa zyskują więcej na testach z szerszym dostępem, bo łatwiej wskazać podstawowe luki,
• dostępny czas i budżet – black box wymaga więcej czasu na rekonesans, white box więcej czasu na analizę kodu, grey box zwykle mieści się pomiędzy tymi wariantami,
• wymagania regulacyjne – normy takie jak RODO (w tym art. 32 ust. 1 lit. d, nakładający obowiązek regularnego testowania i oceniania skuteczności zabezpieczeń), DORA, ISO 27001, NIS2 czy PCI-DSS nie narzucają jednego modelu, ale wpływają na zakres i częstotliwość testów,
• etap testowania organizacji – pierwszy test w historii firmy często zaczyna się od black box lub grey box, a kolejne iteracje mogą przechodzić w stronę white box, jeśli poprzednie wyniki wskazują na potrzebę głębszej analizy.

Żaden z trzech modeli nie jest obiektywnie lepszy – to trzy różne narzędzia do różnych sytuacji, a dobór właściwego wariantu ma większe znaczenie dla jakości wyniku niż sama nazwa metodyki.