Man vs. Machine

Tak, to pierwszy odcinek zapowiadanej serii wpisów. I dotyczy on często powracającego pytania o to, co jest lepsze. Człowiek czy automat?

Odpowiedź na to pytanie zwykle zależy od tego, kto odpowiada. Producenci narzędzi automatycznych oraz firmy oferujące usługi na tych narzędziach oparte będą twierdziły, że skanery są lepsze albo co najmniej równie dobre jak człowiek. Według mnie i człowiek, i automat mają swoje wady i zalety. To, czy bardziej efektywne jest wykorzystanie automatu, czy człowieka zależy od konkretnej sytuacji. Poza tym fakt “ręcznych testów” wcale nie oznacza, że narzędzia, w tym narzędzia automatyczne, nie są w tym procesie wykorzystane.

Zacznę od ponownego przypomnienia o istnieniu OWASP Application Security Verification Standard. Istotny jest ten cytat:

ASVS defines four levels of Web application security verification. Each level includes a set of requirements for verifying the effectiveness of security controls that are being used.

Te cztery poziomy to:

Na wszystkich tych poziomach możliwe jest wykorzystanie narzędzi (automatycznych). Ale tylko na poziomie pierwszym, przeznaczonym do weryfikacji najmniej istotnych aplikacji, wykorzystanie narzędzi automatycznych jest wystarczające. Na poziomach wyższych wymagany jest już “czynnik ludzki”.

Jeśli miałbym określić na jakim poziomie działam, byłby to zdecydowanie poziom Level 2 , a konkretnie Level 2A: Security Test (Partial Manual Verification) , tak więc z narzędzi korzystam, ale na nich się nie opieram i trochę im nie ufam. Co więcej muszę stwierdzić, że wiele dostępnych narzędzi mniej lub bardziej automatycznych kompletnie gubi się w przypadku testowania “złożonych” aplikacji. Przykładowo praktycznie nigdy nie udało mi się wykorzystać sqlmap do wykrywania lub exploitowania sqlinjection. To bynajmniej nie znaczy, że sqlmap jest złym narzędziem, po prostu nie radzi sobie w scenariuszu, gdy payload jest wprowadzany w jednym miejscu, wywoływany w drugim, a wynik sprawdza się w trzecim (tak, były takie przypadki).

Tu jeszcze warto nadmienić, że fakt, iż “pozycjonuję się” w poziomie L2A nie oznacza, że zagadnienia zdefiniowane dla L2B czy L3 lub L4 są zupełnie pomijane. By jednak zrobić przegląd kodu źródłowego, trzeba mieć do niego dostęp (i bynajmniej nie chodzi tu o przypadki, w których taki kod udaje się pobrać w trakcie testów poprzez wykorzystanie jakiejś podatności), trzeba mieć opis architektury by ją weryfikować (...) W praktyce często końcowy zakres usługi to pewna kompilacja poziomu L2 (A i częściowo B) z elementami poziomów wyższych.

W przypadku poziomu L1 warto pamiętać, że narzędzia (skanery automatyczne) wbrew hasłom reklamowym, nie działają na zasadzie “fire and forget”. Trzeba je jeszcze skonfigurować w sposób adekwatny do testowanej aplikacji. A robić powinien to (niespodzianka) człowiek, który nie tylko zna narzędzie, ale również sam temat “testów bezpieczeństwa aplikacji”. Patrząc w ten sposób, to nawet testy narzędziami automatycznymi całkiem “czynnika ludzkiego” nie eliminują.

Cztery poziomy zdefiniowane w ASVS nie zostały wyodrębnione dlatego, że komuś tak się podobało. Po prostu można wyróżnić kilka “klas” aplikacji i w zależności od nich (od tego jak bardzo istotne są te aplikacje i przetwarzane w nich dane) ich bezpieczeństwo powinno być weryfikowane z określonym stopniem pewności. Oznacza to, że “ważność” aplikacji powinna być określona i w zależności od niej powinny zostać dobrane odpowiednie działania. Niestety, czasami pojawiają się zapytania ofertowe, które można określić jako oderwane od rzeczywistości granatem , czyli takie, gdzie nieistotne aplikacje (ten wątek chyba rozwinę w przyszłości by odróżnić je od “mniej ważnych aplikacji”) mają być testowane w taki sam sposób, jak te najbardziej istotne. Oczywiście przypadki odwrotne (istotne aplikacje traktowane “po macoszemu”) również się zdarzają.

Podsumowując: odpowiedź na pytanie człowiek czy automat powinna brzmieć to zależy od oczekiwanych efektów. Weryfikacja bezpieczeństwa (świadomie nie używam tu pojęcia “testy penetracyjne”) wykonana wyłącznie przy pomocy narzędzi automatycznych daje, co do zasady, mniejszy “poziom pewności”. W niektórych przypadkach jest to jednak zupełnie wystarczający rezultat.

W tekście użyłem określenia “czynnik ludzki” w odniesieniu do wkładu człowieka (specjalisty) w proces weryfikacji bezpieczeństwa aplikacji. Pojęcie to często jest używane po to, by podkreślić niedoskonałość człowieka, na przykład: powodem katastrofy mógł być czynnik ludzki (czytaj: powodem katastrofy mógł byćbłąd człowieka).

Cóż, (pen)testerzy też są tylko ludźmi a ich działania obarczone są prawdopodobieństwem błędu. Nobody's perfect all of the time. W tym kontekście automaty mają kilka zalet. Są niedoskonałe, ale przynajmniej powtarzalne.

Oryginał tego wpisu dostępny jest pod adresem Man vs. Machine

Autor: Paweł Goleń