Paweł Goleń, blog

Jaki jest cel, co chcemy osiągnąć

Jakie informacje warto przygotować/udostępnić, gdy chce się zamówić test? Na wstępie trzeba się zastanowić jaki jest cel tego testu. Do tematu można podejść na wiele sposobów, pisałem już trochę na ten temat. Warto jest jasno określić cel testu już na samym wstępie. Może to być na przykład:

• sprawdzenie zgodności aplikacji z wymaganiami (checklistą),
• weryfikacja określonych scenariuszy zagrożeń,
• (...),
• "pełny test penetracyjny",

Istnieją firmy/instytucje, które posiadają wewnętrzne uregulowania odnośnie aplikacji (internetowych). Często wymagania te wprost opierają się na dokumentach OWASP. Tego typu weryfikacja może być szybsza (wszystko jest oczywiście dość względne) niż "pełny test", są jasno przedstawione zagadnienia (w postaci punktów na liście kontrolnej), a celem projektu jest po prostu jej wypełnienie. Jeśli właśnie to ma zostać osiągnięte - warto przedstawić taką listę, to daje dość dobre wyobrażenie o pracach, które mają być wykonane. Podobne podejście można zastosować, gdy weryfikuje się zgodność implementacji z założeniami projektowymi. W szczególności może to mieć zastosowanie, jeśli testy są elementem procesu produkcji oprogramowania, a w przy jego projektowaniu zastosowany został threat modelling.

Może być też tak, że aplikacja w jakiś sposób przeanalizowana (ryzyko z nią związane) i celem testu jest zweryfikowanie określonych scenariuszy. Jeśli tak - warto przedstawić te scenariusze. Może okazać się, że przedmiotem projektu będzie niewielki obszar funkcjonalności naprawdę bardzo dużej aplikacji. Podając wyłącznie informacje o aplikacji (lub pokazując ją), można otrzymać oferty "nieco przeszacowane". Dla przykładu - ktoś chce zweryfikować, czy proces uwierzytelnienia do aplikacji oraz komunikacja z nią, są bezpieczne. Nie interesuje go sama aplikacja "w środku", bo jej użytkownicy nie mogą nic w niej więcej osiągnąć (w aplikacji nie ma "wartości", które mogą stać się celem dla użytkowników mających do niej uprawniony dostęp), natomiast sam dostęp do niej może być wartością dla intruzów z zewnątrz (konkurencji). Ilość pracy potrzebnej do realizacji tego celu jest zupełnie inna, niż do realizacji celu przedstawionego w sposób: "tu jest aplikacja, chcemy ją przetestować".

Problem pojawia się w przypadku "pełnego testu penetracyjnego". W szczególności może to oznaczać sprawdzenie każdego punktu wejścia parametr po parametrze, co po prostu trwa... Jeśli tak do końca nie wiesz, czego chcesz (a to wcale nie jest nic dziwnego) - zapytaj. Warto poświęcić trochę czasu tak, by trzymać taką usługę, jakiej się potrzebuje. Może się na przykład okazać, ze potrzebny jest szybki rekonesans w aplikacji, by na jego podstawie móc zaplanować dalsze prace. Czy jest sens płacić za "pełny test" aplikacji, jeśli okaże się, że jej stan jest opłakany, a firma, która ją wykonała, nie ma zielonego pojęcia jak to zrobić dobrze i bezpiecznie? Może być nawet tak, że zamiast testów potrzebna jest identyfikacja zagrożeń (przypominam - używam pojęcia zagrożenia jako określenia dla celu intruza świadomie odbiegając od definicji zawartych choćby w NIST SP800-30 Risk Management Guide for Information Technology Systems), która wykaże, że test penetracyjny nie jest potrzebny i lepszy efekt osiągnie się korzystając z innych środków.

Szczegóły na temat aplikacji

Określenie typu aplikacji (sklep, bankowość elektroniczna, serwis informacyjny, forum, ...) nie wystarcza. Potrzebne są dokładniejsze informacje o aplikacji, na przykład:

• wykorzystane technologie,
• interfejsy (np. poza interfejsem WWW aplikacja może oferować WebService, który też warto sprawdzić),
• poziomy dostępu, model zarządzania uprawnieniami i kontroli dostępu,
• "rozmiar aplikacji",
• czy będzie dostępny kod źródłowy (i w jaki sposób),
• (...),

Bardzo istotną informacją jest rozmiar aplikacji (pojęcie dość abstrakcyjne), co wprost przekłada się na czas (a więc i cenę) usługi. Jeśli jakieś funkcjonalności mają być wyłączone z testów, należy to wyraźnie zaznaczyć. Rozmiar aplikacji można próbować definiować poprzez ilość punktów wejścia wraz z ilością parametrów dla każdego z nich. Dobrze jest umożliwić rekonesans w aplikacji, przy czym udostępnione środowisko powinno być możliwie zbieżne z rzeczywistym zastosowaniem aplikacji, tak by wszystkie możliwe akcje/funkcje były widoczne.

Informacja na temat wykorzystanych technologii również jest istotna. Inaczej aplikacje pisze się w ASP.NET, "czystym" J2EE, JSF czy PHP - inaczej się również testuje. Może się również okazać, że wykorzystane technologie spowodują znaczny wzrost czasu trwania testów, bo trzeba będzie sobie dopisać narzędzia. Na przykład Google Web Toolkit zmusił mnie kiedyś do napisania pluginu do Fiddlera. Im bardziej niestandardowe rozwiązanie, tym ilość pracy "wstępnej" jest większa i trzeba się liczyć. Przy okazji - założenie, że wykorzystanie niestandardowej technologii stanowi istotne utrudnienie dla intruza jest błędne, intruz, w przeciwieństwie do zespołu realizującego test, ma zwykle zdecydowanie więcej czasu do dyspozycji (o ile tylko wartości znajdujące się w aplikacji są wystarczająco motywujące).

Istotnym elementem testów jest weryfikacja kontroli dostępu. W przypadku niektórych aplikacji reguły dostępu są dość złożone (nigdy nie byłem w stanie do końca pojąć wymagań biznesu odnośnie aplikacji sprzedażowych, uprawnień na poszczególnych stopniach managementu, oddziały, regiony, i tak dalej...), więc warto w miarę jasno je opisać. Zrozumienie (zamierzonego) sposobu działania kontroli dostępu pozwoli określić (przynajmniej wstępnie) jakie testy powinny zostać przeprowadzone, co z kolei znów przekłada się wprost na ocenę pracochłonności całej usługi.

Informacja czy i w jaki sposób będzie możliwy dostęp do kodu źródłowego jest również pomocna przy określeniu pracochłonności całego zadania. Może się na przykład okazać, że realizacja większości postawionych zadań jest możliwa przy pomocy "zaawansowanych narzędzi do analizy statycznej kodu", czyli na przykład poleceń typu grep, czy prostych skryptów wykorzystujących regexpy. Co prawda wówczas może nie jest to już "test penetracyjny", ale w końcu chodzi o osiągnięcie określonego celu w sposób najbardziej efektywny i może w tym przypadku nie test, a przegląd kodu źródłowego jest właściwą drogą.

Jakie są ograniczenia

Być może z testem związane są jakieś ograniczenia. Na przykład termin wykonania (od - do), możliwe godziny pracy (test musi być wykonany poza godzinami największego ruchu), dostępność środowiska testowego, dostępność kluczowych pracowników. Tego typu kwestie może nie przekładają się wprost na cenę, ale mogą być bardzo istotne przy tworzeniu harmonogramu prac.

Przy okazji - niektórzy kierownicy projektów wciąż wierzą, że dodanie ludzi/zwiększenie czasu pracy spowoduje skrócenie czasu realizacji zadania. Pewne prace skalują się lepiej, inne gorzej. Założenie o skalowaniu liniowym może jest zasadne przy kopaniu rowów (choć też nie do końca, kopiąc rów przez 16 godzin dziennie nie koniecznie wykopie się go w jednostce czasu dwa razy więcej, niż kopiąc go "tylko" przez 8 godzin), ale przy tworzeniu oprogramowania czy jego testowaniu (zarówno funkcjonalnym, jak i pod kątem bezpieczeństwa) takie oczekiwania są po prostu naiwne. Tutaj polecam zapoznanie się z książką Marsz ku klęsce. W szczególności odradzam podejście typu "no, to będziemy (będziecie) pracować 10-12 godzin na dobę, to zamiast 4 tygodni projekt się skończy w 2 i pół". Z takim życzeniowym podejściem spotkałem się wiele razy, w różnych miejscach przy różnych projektach, nie koniecznie związanych z testami bezpieczeństwa. Praktyka była taka, że wydłużenie czasu pracy powodowało spadek wydajności i jakości pracy, w związku z czym albo z 4 tygodni robiło się 6, albo i projekt niby kończył się w założonym (skróconym) czasie, przy czym jego efekty w znaczny sposób odbiegały od założeń.

Można i inaczej...

Oczywiście, jeśli ktoś chce, może upierać się przy symulowaniu "kota w worku". Tylko efekty mogą być dalekie od oczekiwanych...

Przykład (z ofert dla freelancerów): Audyt dla sklepu Potrzebuję wykonać zabezpieczanie dla sklepu internetowego SQL injection, mail injection. I o co właściwie chodzi? O "audyt" (jak w tytule), czy może o pisanie kodu, skoro mowa o "wykonaniu zabezpieczenia"?