Paweł Goleń, blog

Jednym z powodów jest to, że pewnie w wielu przypadkach po prostu zrobiłbym to lepiej, w końcu o brakach w skillach związanych z "cyberbezpieczeństwem" nie mówi się bez powodu i w efekcie wszystkie powiedzenia o rakach na bezrybiu czy lubieniu co się ma stają się boleśnie prawdziwe. Niestety(?), pomimo tego, że nie zajmuję się aktywnie testowaniem od wielu już lat, ciągle umiem więcej niż "statystyczny" tester.

Drugi, nie mniej ważny powód, to to, że raportowanie jest po prostu trudne. Czasami widać, że raport jest słaby z uwagi na ograniczone umiejętności, tylko nie do końca wiadomo, czy chodzi o ograniczone umiejętności techniczne (testowania) czy może raczej raportowania.

Jeśli czytam raport, to chciałbym wiedzieć kilka prostych rzeczy:

• co właściwie było testowane;
• z jakiej perspektywy test był przeprowadzony;
• jakie były cele testu;
• jakie ograniczenia wystąpiły w trakcie testowania;
• co ostatecznie udało się osiągnąć.

Co było testowane? Czy to nie jest oczywiste? No właśnie nie jest, przynajmniej przestaje być oczywiste przy pewnej skali organizacji. W pewnej chwili naprawdę trudno jest znaleźć kogoś, kto zna wszystkie aplikacje i wie dokładnie do czego one służą, więc dobrze jest w raporcie umieścić krótki opis aplikacji tak, by czytający raport zrozumiał do czego ona służy, jaki proces biznesowy wspiera, jakie „wartości” może w sobie zawierać i co może chcieć osiągnąć atakujący.

No właśnie, skoro jesteśmy przy atakującym to jak go właściwie definiujemy? Czy test został przeprowadzony z perspektywy użytkownika zewnętrznego (klienta) czy może „od środka”? Podejście do testu i jego cele trochę będą się różnić w zależności od tego, kogo symulujemy. Czego innego można się spodziewać po zdeterminowanym, zmotywowanym przestępcy, a czego innego po oportunistycznym insiderze, który korzysta z tego, że coś leży na widoku i nikt na to nie patrzy. Naszego hipotetycznego atakującego mogą opisać trzy proste pytania - kto, dlaczego (lub po co), co potrafi.

I tutaj właśnie dochodzimy do tematu celów. Oczywiście, można zrobić testy z perspektywy czysto technicznej (te wszystkie XSS, SQLi, XXE, RCE, ...), czasami to nawet działa. Z drugiej strony warto mieć z tyłu głowy to, co co mogłoby być „najgorsze” w danej sytuacji. Przykładowo skupianie się na testowaniu kontroli dostępu w przypadku, gdy aplikacja zawiera dane publiczne i/lub wszyscy i tak widzą w aplikacji to samo trochę mija się z celem.

Jeśli wiemy co miało być zrobione, dobrze też wiedzieć czego nie udało się przetestować. Bo było za mało czasu. Bo aplikacja była niestabilna. Bo coś nie zostało skonfigurowane do końca. Bo tester dostał tylko jedno konto zamiast kilku. Bo dane testowe nie były wystarczająco reprezentatywne. Dziwi mnie, że takie rzeczy często nie są wystarczająco jasno dokumentowane, przecież to jest oczywiste „ubezpiecznie” na wypadek gdyby później jednak okazało się, że w jednym z nieprzetestowanych miejsc coś było.

I ostatni punkt - co udało się osiągnąć. Z tym mam chyba największy problem. Dlaczego? Dlatego, że test jest z natury dość subiektywny. Subiektywny w tym sensie, że zależy od podejścia i umiejętności testera. To nie jest tak, że dla tej samej aplikacji testowanej przez n losowo wybranych testerów lista znalezionych podatności będzie zawsze taka sama. Podejrzewam, że nawet gdyby ten sam tester testował tę samą aplikację dwa razy i gdyby w jakiś sposób usunąć z jego pamięci pierwszy test, wyniki drugiego testu mogłyby być delikatnie inne. Tak, można próbować czynić proces testowania bardziej powtarzalnym (nieśmiertelne checklisty), przy czym ceną powtarzalności może być brak kreatywności, nie wiadomo co gorsze.

Dla jasności, nieodmiennie jestem wielkim fanem OWASP ASVS (i pokrewnych), ale trzeba zwrócić uwagę, że ASVS raczej mówi co sprawdzić, nie jak. Dla odmiany OWASP Web Security Testing Guide mówi bardziej jak konkretny test przeprowadzić. Obie rzeczy są potrzebne, trzeba wiedzieć zarówno co testować oraz jak to zrobić, jest między nimi jednak dość znacząca różnica. Jakoś wolę punkt na liście „sprawdź dostępne usługi” niż „uruchom polecenie nmap (...)”.

Wracając do głównego wątku - podejścia do testowania są różne, dla przykładu dwa:

• test „eksploracyjny” - testujemy aplikację przez określony czas i zobaczmy co się uda znaleźć;
• test skupiony na weryfikacji konkretnych scenariuszy.

W pierwszym przypadku chciałbym wiedzieć co ten test „eksploracyjny” pokrył i dlaczego akurat to. W drugim przypadku chciałbym wiedzieć jakie konkretnie scenariusze miały zostać poddane weryfikacji i jaki był wynik tego sprawdzenia.

Osobiście preferowałem podejście mieszane, czyli na początku eksplorację aplikacji (happy hunting), podczas której miałem okazję zapoznać się dokładniej z tym jak działa (technicznie) i do czego służy (biznesowo). W kolejnym kroku skupiałem się na wymyślaniu scenariuszy, często na poziomie konkretnej formatki, które następnie były weryfikowane. Moje notatki pozwalały stwierdzić dokładnie co było zrobione i kiedy. Scenariusze, które wymyśliłem i przetestowałem, również były wynotowane razem z rezultatem testu (sukces / niepowodzenie) oraz technicznymi obserwacjami - co było testowane i jaki był dokładnie rezultat testu.

Dla przypomnienia, moje notatki prowadziłem w FreePlane, dzięki temu, że każda notatka miała dodawany automatycznie timestamp, w razie potrzeby łatwo było odnaleźć logi z czasu, kiedy dana rzecz była testowana.

W tej chwili bardzo brakuje mi tej szczegółowości i dostępu do technicznego mięsa. I właśnie dlatego jestem jak teściowa - czuję, że zrobiłbym to lepiej :)