Raport z testów penetracyjnych to dokument zawierający informacje o podatnościach występujących w aplikacji internetowej, segmencie sieciowym lub aplikacji mobilnej. Co ważniejsze, przedstawia także rekomendowane działania mające na celu ich eliminację lub ograniczenie ryzyka.

Jednak istnieją pewne elementy, których w takim raporcie nie znajdziesz.

Gwarancja bezpieczeństwa

Żaden zespół przeprowadzający testy penetracyjne nigdy nie zagwarantuje wykrycia wszystkich podatności w Twojej aplikacji. Jest to po prostu niemożliwe. Dotyczy to nie tylko testów penetracyjnych, ale każdej formy weryfikacji bezpieczeństwa.

Współczesne oprogramowanie charakteryzuje się ogromną złożonością, która stale rośnie. Typowa aplikacja internetowa składa się z wielu warstw, takich jak:

• front-end odpowiedzialny za prezentację danych użytkownikom,
• back-end przetwarzający żądania,
• API umożliwiające programistyczny dostęp do aplikacji,
• modele obsługujące połączenia z bazami danych lub zewnętrznymi źródłami danych.

Programiści nie tworzą wszystkiego od podstaw – korzystają z bibliotek i frameworków, aby szybciej dostarczać funkcjonalność oraz ułatwiać jej dalszy rozwój. Aby to wszystko działało, konieczne jest środowisko serwera WWW obsługujące żądania HTTP, mechanizmy cache’owania oraz load balancery umożliwiające skalowanie ruchu. Serwer WWW często wykorzystuje dodatkowe rozszerzenia, a całość może być wdrażana w kontenerach i hostowana w chmurze, co upraszcza zarządzanie oraz obniża koszty.

Myślę, że wiesz, do czego zmierzam. Nawet zanim aplikacja internetowa zostanie wdrożona, wykorzystuje ogromną liczbę linii kodu pochodzących z różnych komponentów. Jak możesz sobie wyobrazić, wiele z tych linii kodu może wprowadzać podatności do całego systemu.

Nie wspominając już o architekturze niskopoziomowej, gdzie procesory różnych fizycznych maszyn mogą wykonywać niepożądane operacje.

To jednak dotyczy jedynie złożoności systemu. Dochodzi do tego jeszcze fakt, że technologie wykorzystywane przez Twoją aplikację są aktualizowane każdego dnia.

Poniższa ilustracja przedstawia niektóre technologie wykorzystywane w typowym procesie działania aplikacji.

Nie trzeba dodawać, że żaden inżynier ds. bezpieczeństwa, tester penetracyjny, programista ani żadne rozwiązanie zabezpieczające nie jest w stanie w pełni ochronić całego zaangażowanego oprogramowania.

Jest to podobne do inwestycji finansowych, gdzie nikt nie może zagwarantować, że zarobisz pieniądze, inwestując w akcje X.

Ryzyko a istotność podatności (Risk vs severity)

Kolejną rzeczą, której nie znajdziesz w większości raportów z testów penetracyjnych, są informacje o ryzyku związanym z wykrytymi podatnościami oraz ich wpływie na biznes. Jeśli w raporcie widzisz podatność oznaczoną jako „krytyczna, wysoka, średnia, niska, informacyjna, brak”, nie jest to ocena ryzyka, lecz określenie istotności podatności (chyba że przeprowadzono odpowiednią analizę ryzyka).

Istotność podatności można obliczyć lub przypisać ręcznie przez testera penetracyjnego, który ją odkrył. W Zigrin Security korzystamy z powszechnie znanego systemu Common Vulnerability Scoring System (CVSS) do jej określania. Ocena ta odzwierciedla m.in. techniczne skutki podatności dla poufności, integralności i dostępności systemu. Na przykład podatność pozwalająca na eksfiltrację bazy danych aplikacji może zostać oceniona jako wysoka. Nie odzwierciedla ona jednak wpływu na biznes, prawdopodobieństwa ataku ani umiejętności cyberprzestępców, którzy mogliby ją wykorzystać.

Jest tak, ponieważ te czynniki nie są znane testerowi penetracyjnemu analizującemu Twoją aplikację. Przykładowo tester nie ma wiedzy, czy baza danych, którą można wykradać, zawiera dużą czy małą część informacji Twojej firmy. Jeśli jest niewielka, to mimo wysokiego technicznego ryzyka wpływ na biznes może być niski. W konsekwencji ważniejsze może być usunięcie innych podatności, które dotyczą większej liczby użytkowników lub bardziej krytycznych zasobów biznesowych.

Różnica ta jest szczególnie istotna w sytuacji, gdy wykryto liczne podatności, a budżet na ich naprawę jest ograniczony. W takim przypadku firma powinna priorytetowo traktować te podatności, które stanowią największe zagrożenie dla działalności, użytkowników i systemów biznesowych, a niekoniecznie te, które mają najwyższą istotność techniczną.

Bezpieczne elementy

Głównym celem testów penetracyjnych jest wykrycie podatności, które można później naprawić lub złagodzić. Proces ich identyfikacji może się różnić w zależności od przyjętej metodologii, testera i innych czynników. Jedno jest jednak pewne – testerzy wykonują setki testów manualnych i tysiące testów półautomatycznych. W wyniku tej intensywnej analizy jedynie niewielki odsetek testów prowadzi do wykrycia faktycznie wykorzystywalnej podatności.

Z tego powodu niemożliwe, a raczej nieproduktywne, byłoby raportowanie wszystkich nieudanych prób eksploatacji. Tworzenie raportu zawierającego wszystkie przypadki testowe, które nie wykazały podatności, byłoby wręcz szkodliwe – tester musiałby poświęcać czas na dokumentowanie ich zamiast na dalsze poszukiwanie rzeczywistych zagrożeń. Ponadto odbiorca raportu mógłby odnieść fałszywe wrażenie bezpieczeństwa, widząc, że 99,9% testów zakończyło się wynikiem „bezpieczny”.

Dodatkowo istnieje wiele metod testowania tej samej podatności. Oznacza to, że nawet jeśli tester nie zdołał wykorzystać podatności w konkretnym komponencie aplikacji webowej, mogły istnieć inne sposoby jej eksploatacji. Możliwe jest również odkrycie innej podatności w tym samym komponencie.

Mam nadzieję, że ten artykuł pokazuje, czego nie należy oczekiwać w raporcie z testów penetracyjnych, w kontraście do poprzednich artykułów z tej serii.