Jak czytać raporty z testów penetracyjnych (bez doktoratu z informatyki)
Większość prawników traktuje raport z testów penetracyjnych jak zło konieczne, które trzeba wpiąć do segregatora przed audytem ISO. To błąd, bo te 30 lub 40 stron dokumentacji technicznej mówi dokładnie, gdzie Twoja firma może stracić dane klientów w ciągu najbliższych 4 miesięcy.
Raport to nie certyfikat, to lista dziur w płocie
Kiedy firma zewnętrzna kończy testy penetracyjne, przesyła plik PDF, który często ląduje w dziale IT i nigdy go nie opuszcza. Jako prawnik musisz zrozumieć, że ten dokument nie jest dowodem na to, że system jest bezpieczny. Wręcz przeciwnie – to szczegółowa lista błędów, które haker może wykorzystać do przejęcia bazy danych. W październiku 2024 roku analizowaliśmy raport jednej z kancelarii w Kielcach, gdzie testerzy znaleźli 7 krytycznych podatności, a zarząd dowiedział się o nich dopiero po 3 miesiącach od zakończenia prac. To ogromne ryzyko prawne w kontekście RODO i odpowiedzialności za wyciek danych osobowych.
W Itcompiled uczymy, że raport należy czytać od końca, a konkretnie od sekcji 'Recommendations'. Zamiast skupiać się na technicznych opisach protokołów, sprawdź, ile znaleziono błędów oznaczonych jako 'Critical' oraz 'High'. Jeśli w podsumowaniu widzisz cyfrę 0 przy tych kategoriach, nie ciesz się od razu. Sprawdź zakres testów. Często firmy zlecają sprawdzenie tylko jednej strony wizytówki, ignorując system do obiegu dokumentów, gdzie faktycznie leżą skany dowodów osobistych i umowy 47 kluczowych klientów. Sprawdzamy kod, nie tylko paragrafy, dlatego wiemy, że diabeł tkwi w tym, czego w teście nie ujęto.
Jeśli raport ma 40 stron i żadnej podatności 'Critical', to prawdopodobnie tester nie sprawdził tego, co naprawdę ważne.
Zrozumienie skali CVSS w 2 minuty
W każdym rzetelnym raporcie spotkasz skrót CVSS i cyfry od 0.0 do 10.0. To nie są oceny szkolne, tylko międzynarodowy standard oceny ryzyka. Jeśli przy jakimś błędzie widzisz wynik 9.8, oznacza to, że haker może wejść do Twojego systemu z zewnątrz, bez żadnego hasła i ukraść wszystko w 14 minut. Dla prawnika to czerwona flaga. W marcu ubiegłego roku jeden z naszych klientów miał właśnie taki błąd w systemie rezerwacji. Naprawa zajęła informatykom 3.2 godziny, ale gdyby o tym nie wiedzieli, kara od UODO mogłaby sięgnąć 4% rocznego obrotu za rażące zaniedbanie podstawowych zabezpieczeń.
Nie musisz wiedzieć, jak działa SQL Injection czy Cross-Site Scripting. Musisz jednak wiedzieć, że jeśli podatność ma wysoką ocenę, to czas na jej załatanie liczy się w godzinach, a nie w tygodniach. W Itcompiled pokazujemy, jak przełożyć te cyfry na język ryzyka operacyjnego. Przykładowo, błąd o wartości 7.5 często oznacza, że ktoś z wewnątrz firmy, np. niezadowolony pracownik z 8-letnim stażem, może uzyskać dostęp do pensji zarządu. To są konkretne informacje, które powinny trafić do Twojej analizy ryzyka, a nie techniczny bełkot, który nikogo w dziale prawnym nie interesuje.
Pytania, które musisz zadać działowi IT po lekturze
Zanim podpiszesz protokół odbioru audytu bezpieczeństwa, przygotuj sobie 3 pytania. Pierwsze: 'Które z tych błędów pozwalają na wyciek danych osobowych z bazy SQL?'. To kluczowe dla Twojej dokumentacji RODO. Drugie pytanie: 'Jaki jest harmonogram naprawy dla podatności oznaczonych jako High?'. Nie daj się zbyć odpowiedzią, że 'zrobimy to w wolnej chwili'. Standardy ISO, które wdrażamy w Twoim biurze, wymagają jasnych terminów. Zazwyczaj dla błędów krytycznych to 48 godzin, a dla wysokich 14 dni roboczych. Jeśli dział IT twierdzi inaczej, masz problem z zachowaniem ciągłości bezpieczeństwa.
Trzecie i najważniejsze pytanie brzmi: 'Czy przeprowadzono re-testing?'. Raport z poniedziałku pokazuje dziury, ale tylko raport z następnego czwartku może potwierdzić, że te dziury zostały załatane. Widzieliśmy dziesiątki przypadków, gdzie firmy płaciły za testy penetracyjne 11 000 zł, dostawały listę błędów i na tym kończyły współpracę. Bez re-testingu masz tylko dowód na to, że Twój system jest dziurawy, co w sądzie zadziała przeciwko Tobie. Bez technicznego bełkotu – potrzebujesz potwierdzenia na piśmie, że wykryte luki już nie istnieją i system jest obecnie odporny na te konkretne ataki.
Różnica między skanem a testem penetracyjnym
Często firmy sprzedają 'audyt bezpieczeństwa', który w rzeczywistości jest tylko automatycznym skanem wykonanym darmowym programem w 15 minut. To tak, jakbyś sprawdził, czy drzwi do biura są zamknięte, ale nie sprawdził, czy okno na parterze jest otwarte. Prawdziwy pentester to człowiek, który próbuje oszukać system logiką. W kwietniu 2024 roku prowadziliśmy warsztaty dla 9 prawników z dużej firmy budowlanej. Pokazaliśmy im raport, który wyglądał profesjonalnie, ale po 5 minutach analizy okazało się, że był to tylko wydruk z automatu. Brakowało tam analizy ścieżek dostępu i testów socjotechnicznych.
Jako prawnik musisz wymagać 'manualnych testów penetracyjnych'. Tylko one dają realny obraz tego, czy haker jest w stanie ominąć Twoje procedury. W Itcompiled uczymy, jak rozpoznać tę różnicę w fakturze i umowie z dostawcą. Jeśli usługa kosztuje 1500 zł i trwa 2 godziny, to nie jest test penetracyjny. Rzetelny test dla małej firmy z 47 pracownikami trwa minimum 5-8 dni roboczych i angażuje przynajmniej dwóch specjalistów. Praktyka zamiast slajdów – nauczymy Cię, jak weryfikować te kompetencje u podwykonawców, by nie przepłacać za iluzję bezpieczeństwa.
Automat znajdzie błędy w konfiguracji, ale to człowiek znajdzie dziurę w logice Twojego systemu i wyniesie dane.
Jak wpisać wyniki testów do dokumentacji RODO?
Wyniki testów penetracyjnych są najlepszym dowodem na to, że realizujesz zasadę rozliczalności z RODO. Nie wystarczy napisać w polityce bezpieczeństwa, że 'dbamy o dane'. Musisz mieć dowód, że regularnie weryfikujesz skuteczność środków technicznych. Zalecamy, aby streszczenie menedżerskie z raportu (tzw. Executive Summary) było załącznikiem do corocznego przeglądu systemu ochrony danych. W lipcu 2024 roku pomogliśmy jednemu z naszych klientów uniknąć kary, właśnie dzięki temu, że miał udokumentowany proces: testy w marcu, naprawa w kwietniu, re-test w maju.
Pamiętaj jednak, by nie trzymać całego raportu technicznego w ogólnodostępnym folderze na dysku wspólnym. To paradoks, ale pełny raport jest instrukcją obsługi dla włamywacza. Przechowuj go z ograniczonym dostępem, np. tylko dla zarządu i szefa IT. W Itcompiled stosujemy zasadę 'need to know'. Prawnik powinien znać skalę ryzyka i terminy naprawy, ale nie musi znać dokładnych skryptów użytych do ataku. Dzięki takiemu podejściu Twoje standardy ISO w Twoim biurze będą realnie działać, chroniąc nie tylko dane klientów, ale i Twój spokój podczas kontroli z zewnątrz.
