Paweł Goleń, blog

Często używa się zamiennie pojęć test penetracyjny i audyt bezpieczeństwa. Choć nie jestem purystą językowym (tudzież definicyjnym), to w tym przypadku jest to błąd. Terminy te oznaczają po prostu zupełnie inne rzeczy.

No właśnie, jaki jest cel przeprowadzenia testów penetracyjnych? Czy testy mają pokazać, że aplikacja nie ma błędów bezpieczeństwa? A może chodzi o to, by pokazać, że takie błędy posiada? Na przykład poprzez dopisanie czegoś, usunięcie czegoś, itp.? Może wynikiem testów ma być jakiś certyfikat, którym się można chwalić (temat "certyfikantyzmu" to inna bajka, może o niej kiedyś coś napiszę...)?

Zacznijmy od początku. Błędów bezpieczeństwa nigdy nie uda się całkowicie wyeliminować. Pojawiają się nie tylko w produktach Microsoftu, mimo, że firma ta wdrożyła SDL (którego częścią różne testy bezpieczeństwa są, jest również audyt kodu źródłowego), są w jądrze Linuksa, są w OpenBSD, znajdują się w różnych projektach, zarówno tych z otwartymi, jak i zamkniętymi źródłami. Brak wykrycia błędów w trakcie testów penetracyjnych wcale nie oznacza, że ich tam nie ma. Oznacza to jedynie tyle, że w określonym czasie przy użyciu określonych zasobów błędów (błędów, usterek, podatności), nie udało się znaleźć. Tak więc cel pokazać, że aplikacja nie ma błędów można uznać za błędny u samej swojej podstawy.

To może w drugą stronę - wykazać istnienie błędów? W pewnym sensie tak, tylko wówczas istnieje niebezpieczeństwo, że celem zespołu testującego stanie się wykorzystywanie pierwszej znalezionej większej podatności. W rezultacie zlecający testy dostaje informacje, że za pomocą takiego błędu udało się zrobić (...i tu mniej lub bardziej interesująca lista...). Tylko czy podobnych podatności nie ma więcej? Może to jest dobre podejście na konferencjach poświęconych bezpieczeństwu, znaczy się na warsztatach, bo przemawia do wyobraźni i jest efektowne. W trakcie testów rzeczywistej aplikacji, która ma służyć jakimś celom, takie podejście nie jest najlepsze. No chyba, że chodzi o działanie "otwierające oczy" na takiej zasadzie jak zadziałał na USA atak Japończyków na Pearl Harbor.

Otrzymanie "certyfikatu"... tak, niektóre firmy lubią produkować efektownie zadrukowane kartki papieru o dużej gramaturze. Ładnie coś takiego wygląda na ścianie w ramkach. I mniej więcej do tego się nadaje. No i do marketingu, jak mogłem zapomnieć. Istotnym problemem jest brak "punktów odniesienia". Certyfikat powinien potwierdzać coś. To coś, to może być na przykład spełnienie przez aplikację określonych wymagań (checklista). Jeśli aplikacja je spełnia, otrzymuje certyfikat zgodności z daną listą wymagań. Problem w tym, że brak jest takich powszechnie uznawanych list. W pewnym sensie punktem odniesienia odnośnie tego jak aplikacja powinna wyglądać może być OWASP, ale nawet tam nie ma tej hipotetycznej listy wymagań. Zakładając jednak, że taka lista istnieje i istnieje certyfikat potwierdzający zgodność z nią aplikacji, to "czas życia" tego certyfikatu będzie zwykle dość krótki. Do pierwszej zmiany w badanym środowisku. Po zmianie w konfiguracji serwera WWW, bazy danych czy instalacji nowej wersji aplikacji usuwającej prosty błąd funkcjonalny środowisko jest inne, niż środowisko, w którym badanie zgodności z wzorcem (checklistą) zostało przeprowadzone. Siłą rzeczy certyfikat przestaje być ważny. A przynajmniej tak powinno być, wspomniałem jednak "certyfikantyzm".

Można powiedzieć, że test bezpieczeństwa ma za zadanie ocenę poziomu bezpieczeństwa aplikacji. Jest nawet trochę proponowanych metodyk, które służą do określania owego poziomu bezpieczeństwa. Być może wynika to po części z raportów generowanych przez narzędzia automatyczne. Dla kadry zarządzającej takie ładne kolorki (zielony, żółty, czerwony) i łatwo zrozumiałe numery są czymś bardzo kuszącym. Moim (i nie tylko moim) zdaniem, nie istnieje w chwili obecnej żadna metodyka, która taką "wycenę" pozwala dokonać w sposób sensowny. Uważam, że wyniki testu penetracyjnego powinny być jedną z danych wyjściowych w procesie analizy ryzyka, który dopiero może odpowiedzieć na pytanie, czy aplikacja jest bezpieczna, a właściwie na pytanie, czy ryzyko związane z jej użytkowaniem jest akceptowalne.

Ja jestem zwolennikiem poglądu, że testy penetracyjne służą identyfikacji podatności. A konkretnie maksymalnej ilości podatności, jaką uda się zidentyfikować w określonym czasie. Przy okazji warto pamiętać, że "konkurencja" (czyli włamywacze) dysponują zdecydowanie większą ilością czasu, który mogą poświęcić na wyszukiwanie podatności. Robią to tym chętniej, im większe korzyści mogą osiągnąć.

Tutaj wspomnę jeszcze o tym, że na podstawie wyników testów można wyciągnąć pewne wnioski odnośnie jakości aplikacji. W szczególności można stwierdzić, czy aplikacja jest spójna, czy są stosowane środki zaradcze i prawidłowe techniki programistyczne, a jeśli są, to czy są one stosowane konsekwentnie. Gdy aplikacja jest chaotyczna i brak jest konsekwencji w jej budowie, szansa wystąpienia w niej błędów (w tym błędów bezpieczeństwa) jest duża. Mówi to też jak (prawdopodobnie) wygląda po stronie wykonawcy proces tworzenia aplikacji. Szczególnie ciekawie wygląda porównanie takiego chaosu z zapewnieniami wykonawcy złożonymi na etapie wyboru ofert, że stosuje on "sprawdzoną i wypracowaną przez lata na własnych doświadczeniach metodykę", co w wolnym tłumaczeniu oznacza często "...nikt tego nie kontroluje, na tydzień przed oddaniem projektu odprawiamy gusła, by to zadziałało...".

Za wiedzę się płaci. Za czas też. Zwłaszcza jeśli jest to wiedza i czas specjalistów. Naturalne jest, że z jednej strony każdy chce kupić coś (usługę) jak najtaniej, z drugiej - sprzedać jak najkorzystniej. Trzeba jednak uważać, by za atrakcyjną cenę nie kupić "wyrobu testopodobnego". Wyniki (raporty) narzędzi automatycznych, nawet po pewnym opracowaniu, nie zastąpią pracy specjalisty. Jest to szczególnie prawdziwe w przypadku aplikacji webowych, gdzie każda z nich jest specyficzna i wymaga indywidualnego podejścia.

W trakcie testów penetracyjnych narzędzia automatyczne są oczywiście wykorzystywane, ale raczej na etapie rekonesansu, po to, by lepiej poznać badany obiekt (aplikację) i lepiej dostosować swoje działania. Usługi polegającej wyłącznie na uruchomieniu skanera i (opcjonalnie) opracowania rezultatów nie można nazwać testem penetracyjnym.

Z drugiej strony regularne skanowanie środowiska czy aplikacji przy pomocy narzędzi automatycznych jest wskazane. Choćby po to, by obserwować zachodzące zmiany. Wspomniany Nessus dobrze sprawdza się w celu identyfikacji aktywnych hostów oraz usług. Pozwala również dość skutecznie na identyfikację znanych podatności w znanych systemach i usługach. Na podstawie wyników tego typu testów można podejmować decyzje co do dalszych działań. Jeśli jednak chodzi o testy automatyczne i testy penetracyjne, to dwie odrębne usługi, choć testy automatyczne mogą być elementem testów penetracyjnych.

Można się często spotkać ze stwierdzeniem, że testy penetracyjne przeprowadzane są według metodologii black box. Chodzi tutaj o ilość informacji na temat testowanego systemu, które posiada testujący. Można mówić o dwóch skrajnościach, czyli gdy wiedza jest zerowa (a więc czarne pudełko, nie wiadomo jak działa), lub o sytuacji, gdy wiedza jest pełna (białe pudełko). Oczywiście można jeszcze spotkać różne odcienie szarości...

Które podejście jest lepsze? To zależy od tego, co chce się osiągnąć. Jeśli jednak celem całego projektu jest udostępnienie aplikacji, która ma realizować określone cele biznesowe, uważam, że wszystkie prace powinny być wykonywane maksymalnie efektywnie, a testy są tym bardziej efektywne, im więcej informacji się posiada. Czyli jak najbielsze pudełko, łącznie z dostępem do logów, kodu źródłowego, a przede wszystkim z konkretną informacją o zadaniach aplikacji i poszczególnych przypadkach użycia.

Profil zagrożeń to charakterystyka wszystkich (zidentyfikowanych) zagrożeń (rozumianych jako cele przeciwnika) dla danego systemu. Model zagrożeń jest dokumentem, który zawiera informacje na temat systemu, profil zagrożeń dla tego systemu oraz analizę obecnego systemu odnośnie jego profilu zagrożeń. Jeśli dysponuje się modelem zagrożeń dla danego systemu, można na jego podstawie przeprowadzić testy, mające na celu sprawdzić, czy zidentyfikowane zagrożenia mogą się zrealizować. Niestety, w większości przypadków przy tworzeniu system nie poświęca się wystarczającej uwagi tematowi bezpieczeństwa, nie ma identyfikacji zagrożeń... A szkoda.

...prawdopodobnie będzie kolejna część...