Jak czytać raport z pentestu - krytyczność, priorytety i co dalej

Po teście dostajecie dokument na kilkadziesiąt stron, pełen skrótów, zrzutów ekranu i fragmentów kodu. Łatwo go przeczytać pobieżnie, zobaczyć kilka czerwonych pozycji i odłożyć „na później”. Tymczasem to właśnie raport jest produktem pentestu. Sam test niczego nie naprawia, robią to dopiero poprawki, a one zaczynają się od zrozumienia, co jest w dokumencie.

Z czego składa się raport

Układ bywa różny, ale większość rzetelnych raportów zawiera te same elementy:

• Podsumowanie dla zarządu. Jedna do dwóch stron bez żargonu: co testowano, jaki jest ogólny obraz bezpieczeństwa, co jest najpilniejsze.
• Zakres i metodyka. Co dokładnie było w teście, a co poza nim, w jakim terminie, z jakimi uprawnieniami i według jakich standardów (np. OWASP). To część łatwa do pominięcia, a ważna: wszystko, czego tu nie ma, nie zostało sprawdzone.
• Lista znalezisk. Zwykle tabela z krytycznością, a pod nią opis każdej pozycji.
• Opis pojedynczego znaleziska. Gdzie występuje, jak to wykorzystać, jaki ma skutek, jak to powtórzyć i jak naprawić.
• Rekomendacje i kolejność działań. Czasem osobna sekcja, czasem tylko uwagi przy znaleziskach.
• Załączniki. Surowe wyniki narzędzi, listy sprawdzonych adresów, szczegóły techniczne.

Jeśli w raporcie brakuje opisu zakresu albo kroków reprodukcji, to sygnał ostrzegawczy. Bez nich nie da się ani zweryfikować wyniku, ani sprawdzić, czy poprawka zadziałała.

Podsumowanie dla zarządu

Ta część powinna odpowiadać na trzy pytania: czy napastnik mógłby zrobić coś, co naprawdę szkodzi firmie, jak łatwo by mu to poszło i co trzeba zrobić najpierw. Dobre podsumowanie mówi językiem skutków („dało się odczytać dane wszystkich klientów po zalogowaniu na zwykłe konto”), a nie samych podatności („IDOR w module zamówień”).

Uwaga na pozorny komfort. Raport z kilkoma znaleziskami o niskiej krytyczności nie oznacza, że wszystko jest w porządku. Oznacza, że w tym zakresie, w tym czasie i z tymi uprawnieniami nie znaleziono więcej. Dlatego zakres jest tak ważny.

Krytyczność: skąd się bierze i czemu nie wystarczy

Znaleziska mają zwykle poziomy: krytyczne, wysokie, średnie, niskie i informacyjne. Często obok jest liczba w skali CVSS od 0 do 10. To użyteczny punkt wyjścia, bo daje wspólny język i pozwala porównywać pozycje, ale ma ograniczenia:

• CVSS ocenia podatność w oderwaniu od Waszej firmy. Ta sama luka bywa groźna w systemie z danymi klientów i prawie bez znaczenia w odizolowanym narzędziu wewnętrznym.
• Nie widzi łańcuchów. Trzy znaleziska „średnie” mogą razem dać pełne przejęcie systemu. Dobry raport opisuje takie połączenia osobno, a pojedyncze oceny mogą tego nie oddać.
• Nie wie, co macie wokół. Czy podatny serwer stoi w internecie, czy za zaporą? Czy ktoś zauważyłby atak? Czy są kopie zapasowe? To zmienia realne ryzyko.

Dlatego autor raportu powinien umieć uzasadnić ocenę słowami: co konkretnie da napastnikowi ta luka i jakie warunki muszą być spełnione. Jeśli ocena krytyczności nie zgadza się z Waszą wiedzą o systemie, zapytajcie. Zmiana poziomu po rozmowie to normalna praktyka, o ile jest uzasadniona.

Jak ustalić kolejność poprawek

Nie wszystko trzeba naprawiać naraz, ale warto mieć prostą zasadę. Sprawdza się układanie pozycji w trzech koszykach:

• Od razu. Wszystko, co daje dostęp do danych lub kontroli nad systemem bez dużego wysiłku, zwłaszcza z internetu. Często jest to szybka poprawka konfiguracji, a nie zmiana architektury.
• W ciągu kilku tygodni. Znaleziska, które wymagają zmian w kodzie, testów lub uzgodnień z dostawcą. Warto im przypisać właściciela i termin, bo bez nich zostają na liście miesiącami.
• W planie. Poprawki strukturalne: zmiana sposobu zarządzania uprawnieniami, wymiana przestarzałego komponentu, uporządkowanie logowania. Nie da się ich zrobić szybko, ale warto je wpisać do planów zespołu.

Przy układaniu kolejności liczy się też koszt poprawki. Pozycja „średnia”, którą naprawia się jedną zmianą ustawienia, powinna zniknąć od ręki, nawet jeśli formalnie nie jest najważniejsza. Często jedna zmiana likwiduje kilka znalezisk naraz, np. wyłączenie starego protokołu czy zmiana domyślnej konfiguracji frameworka.

Czego nie robić z raportem

• Nie przekazywać całości wszystkim. Raport zawiera mapę słabych punktów firmy. Dostęp powinny mieć osoby, które muszą działać, a plik nie powinien krążyć w mailach bez zabezpieczenia.
• Nie naprawiać tylko przykładów. Raport pokazuje, że podatność występuje w jednym miejscu, ale jej przyczyna często jest szersza. Jeśli jeden formularz nie sprawdza uprawnień, to warto przejrzeć pozostałe, nie tylko ten z raportu.
• Nie ukrywać wyniku przed zarządem. Zły raport nie świadczy o tym, że ktoś źle pracował. Świadczy o tym, że ktoś znalazł problemy, zanim zrobił to napastnik, i po to właśnie robi się test.
• Nie odkładać aż „skończymy projekt”. Znaleziska starzeją się razem z systemem, a po zmianach w kodzie i infrastrukturze trudniej odtworzyć kontekst.

Retest, czyli sprawdzenie poprawek

Po wprowadzeniu zmian warto zlecić retest, czyli ponowne sprawdzenie znalezisk z raportu. Zwykle jest on znacznie krótszy od pierwszego testu, bo dotyczy tylko konkretnych pozycji. Dzięki niemu wiecie, że luka faktycznie została zamknięta, a nie tylko zasłonięta. Zdarza się, że poprawka usuwa objaw zgłoszony w raporcie, ale ten sam błąd da się wywołać innym żądaniem.

Wynik retestu bywa też dokumentem, który pokazuje się dalej: audytorowi, klientowi albo ubezpieczycielowi. Pozycje oznacza się wtedy jako naprawione, naprawione częściowo lub nadal obecne.

Co zrobić, gdy czegoś nie rozumiecie

Dobra firma testująca nie kończy współpracy na wysłaniu pliku. Po przekazaniu raportu powinna być rozmowa, na której przejdziecie przez najważniejsze znaleziska, zapytacie o szczegóły i ustalicie, co jest wykonalne u Was. Jeśli raport zawiera pozycje, których Wasz zespół nie umie odtworzyć, poproście o pokazanie kroków. To nie jest dowód nieufności, tylko normalny element pracy.

Jak powinien wyglądać dobry raport

Kilka cech, po których poznacie dokument, z którym da się pracować:

• każde znalezisko ma kroki do powtórzenia i dowód (zrzut ekranu, żądanie, odpowiedź),
• rekomendacja jest konkretna („włącz sprawdzanie właściciela zasobu w endpointcie X”), a nie ogólnikowa („popraw autoryzację”),
• ocena krytyczności ma uzasadnienie, a łańcuchy znalezisk są opisane osobno,
• zakres i ograniczenia testu są wprost nazwane,
• podsumowanie da się przeczytać bez wiedzy technicznej.

Jak wygląda sam proces przed raportem, opisujemy we wpisie jak przygotować firmę do pentestu, a czym test różni się od audytu, w tekście pentest a audyt bezpieczeństwa. Przykładowe kategorie błędów, które pojawiają się w raportach z testów aplikacji, opisujemy w artykule OWASP Top 10 w praktyce. Więcej o naszej usłudze znajdziecie na stronie testów penetracyjnych.