Testy bezpieczeństwa i testy penetracyjne: co sprawdzają, rodzaje, etapy i jak je zlecić

Czas czytania: około 13 minut

Firma dowiaduje się o luce w zabezpieczeniach na jeden z trzech sposobów: od własnego testera, od wynajętego pentestera albo od kogoś, kto właśnie pobrał bazę klientów. Dwa pierwsze kosztują dni pracy. Trzeci kosztuje zgłoszenie do urzędu ochrony danych, komunikat do klientów, tydzień gaszenia pożaru i pytanie zarządu, dlaczego nikt tego nie sprawdził wcześniej. Testy bezpieczeństwa i testy penetracyjne istnieją po to, żeby pierwszy sposób był regułą, a trzeci nigdy nie wystąpił.

W tym tekście wyjaśniamy, czym różnią się testy bezpieczeństwa od testów penetracyjnych, a te od skanu podatności i red teamingu, co sprawdza pentest i jakie ma rodzaje, jak przebiega krok po kroku, kto i jak często powinien go zlecać, jak wybrać wykonawcę, co wpływa na koszt, co może zrobić własny zespół QA i jak czytać raport. Piszemy dla osób, które podpisują zlecenie albo mają je przygotować, nie dla pentesterów.

Czym są testy bezpieczeństwa, a czym testy penetracyjne?

Testy bezpieczeństwa to szeroka kategoria testów sprawdzających, czy system chroni dane i funkcje zgodnie z wymaganiami; testy penetracyjne to ich najbardziej praktyczna odmiana, w której tester wciela się w atakującego i próbuje wykorzystać podatności, żeby pokazać, co naprawdę da się zrobić, a nie tylko co teoretycznie może pójść źle.

Słownik ISTQB definiuje testowanie bezpieczeństwa jako testowanie mające określić bezpieczeństwo produktu, a test penetracyjny jako technikę oceny zabezpieczeń polegającą na próbie skompromitowania systemu przy użyciu metod, jakich użyłby atakujący. Różnica jest jak między przeglądem instalacji elektrycznej a próbą włamania na zlecenie właściciela: pierwszy mówi, co jest niezgodne z normą, drugi pokazuje, którędy ktoś wejdzie i co zabierze.

W praktyce oba pojęcia są używane zamiennie w ofertach i przetargach, co prowadzi do kupowania skanu podatności w cenie pentestu albo oczekiwania od pentestu tego, co daje audyt bezpieczeństwa. Zanim podpiszecie zlecenie, ustalcie jedno zdanie: czy chcecie wiedzieć, jakie macie podatności, czy chcecie wiedzieć, co atakujący z nimi zrobi. To dwie różne usługi o różnym koszcie.

Czym różni się skan podatności od pentestu i od red teamingu?

Skan podatności to automatyczne wyliczenie znanych słabości, pentest to ręczna próba ich wykorzystania w uzgodnionym zakresie, a red teaming to długotrwała symulacja realnego przeciwnika, w której zespół obrony nie wie, że jest testowany; różnią się głębokością, kosztem i tym, na jakie pytanie odpowiadają.

Sektor finansowy ma te trzy poziomy rozpisane wprost w rozporządzeniu DORA: podstawowe testy bezpieczeństwa co najmniej raz w roku dla krytycznych systemów, a testy penetracyjne ukierunkowane na zagrożenia (TLPT), czyli odmiana red teamingu, co najmniej raz na trzy lata dla wyznaczonych podmiotów. Reszta rynku nie ma takiego przepisu, ale ma tych samych atakujących.

Co sprawdzają testy penetracyjne?

Testy penetracyjne sprawdzają, czy da się obejść uwierzytelnianie i uprawnienia, wstrzyknąć kod przez dane wejściowe, wyciągnąć dane przez błędy konfiguracji, wykorzystać podatne komponenty, nadużyć logiki biznesowej oraz czy system loguje i wykrywa próby ataku; punktem odniesienia jest lista OWASP Top 10 i przewodnik OWASP WSTG.

OWASP Top 10 to lista dziesięciu najpoważniejszych kategorii ryzyka w aplikacjach webowych, aktualizowana co kilka lat na podstawie danych z realnych testów. OWASP Web Security Testing Guide to przewodnik opisujący, jak każdą z tych kategorii testować, a OWASP ASVS to lista wymagań, wobec których można ocenić aplikację. Wykonawca, który nie potrafi powiedzieć, którego z tych dokumentów używa i w jakim zakresie, nie ma metodyki.

Jakie są rodzaje testów penetracyjnych?

Testy penetracyjne dzieli się według celu (aplikacje webowe, API, aplikacje mobilne, infrastruktura zewnętrzna i wewnętrzna, chmura, socjotechnika) oraz według wiedzy testera o systemie: black box bez wiedzy, grey box z kontem użytkownika i częściową dokumentacją, white box z kodem i pełną dokumentacją.

Jak przebiega test penetracyjny krok po kroku?

Test penetracyjny przebiega w siedmiu etapach według metodyki PTES: uzgodnienie zakresu i zasad, rozpoznanie, modelowanie zagrożeń, analiza podatności, eksploatacja, działania po włamaniu oraz raport; potem następuje naprawa po stronie klienta i retest, bez którego cały test jest tylko listą problemów.

Metodyka PTES (Penetration Testing Execution Standard) opisuje te etapy szczegółowo i jest, obok OWASP WSTG, najczęstszym punktem odniesienia w ofertach. Siódmy etap, retest po naprawach, formalnie nie należy do PTES, ale bez niego nie wiadomo, czy naprawa zadziałała, a raport z podatnościami krytycznymi bez retestu jest w audycie dowodem przeciwko Wam, nie za Wami.

Kto powinien zlecać testy bezpieczeństwa i jak często?

Testy bezpieczeństwa powinna zlecać każda firma, która udostępnia w internecie aplikację, sklep, API albo panel klienta, a obowiązek prawny lub umowny mają podmioty finansowe, operatorzy usług kluczowych, przetwarzający dane medyczne i dostawcy dla sektora publicznego; rozsądne minimum to pełny pentest raz w roku i po każdej większej zmianie, plus skany automatyczne w pipeline przy każdym wydaniu.

• Raz w roku, pełny zakres. Aplikacje, API, infrastruktura zewnętrzna. Obraz na dzień testu starzeje się z każdym wydaniem, a rok to granica, po której nikt już nie wie, co się zmieniło.
• Po każdej większej zmianie. Nowy moduł płatności, nowa integracja, migracja do chmury, zmiana uwierzytelniania. Test zakresowy, nie pełny.
• Przed wdrożeniem nowego systemu. Szczególnie dostarczonego przez zewnętrznego wykonawcę. Test bezpieczeństwa jako część odbioru, obok testów akceptacyjnych.
• Ciągle, automatycznie. Skan podatności i sprawdzenie wersji komponentów w pipeline przy każdym wydaniu. Nie zastępuje pentestu, ale łapie najtańsze błędy w dniu ich powstania.
• Po incydencie. Jeśli coś się wydarzyło, test sprawdza, czy droga została zamknięta i czy nie ma innych.

W sektorze regulowanym częstotliwość wynika z przepisów, nie z oceny ryzyka. Rozporządzenie DORA wymaga od podmiotów finansowych testowania krytycznych systemów co najmniej raz w roku, a od wyznaczonych podmiotów TLPT co najmniej raz na trzy lata, z udziałem niezależnych testerów. Szczegóły, w tym kto może testować, rozkładamy w tekście o DORA i testach niezależnych, a rolę testów bezpieczeństwa przy odbiorze systemu w tekście o testach akceptacyjnych.

Jak wybrać wykonawcę testów penetracyjnych?

Dobrego wykonawcę pentestów poznaje się po tym, że pyta o zakres i cel zamiast wysyłać cennik, nazywa metodykę (OWASP WSTG, PTES, ASVS), pokazuje przykładowy raport z dowodami i zaleceniami, wlicza retest w cenę, ma ubezpieczenie odpowiedzialności i referencje z Waszej branży oraz podpisuje umowę o poufności przed pierwszym pytaniem o system.

Ostatni wiersz jest ważniejszy, niż się wydaje. Wykonawca systemu, który sam testuje jego bezpieczeństwo, ma powód, żeby znaleźć mniej. Niezależność wykonawcy testów od wykonawcy systemu jest w sektorze regulowanym wymogiem, a wszędzie indziej najtańszym sposobem na raport, któremu można wierzyć.

Ile kosztują testy bezpieczeństwa?

Koszt testów bezpieczeństwa zależy od zakresu (liczba aplikacji, funkcji, adresów), podejścia (black box wymaga więcej czasu na rozpoznanie, white box więcej na analizę), głębokości (skan, pentest, red teaming), wymagań formalnych (raport pod audyt, zgodność z DORA) i tego, czy retest jest wliczony; nie podajemy tu widełek, bo pentest aplikacji z trzema formularzami i pentest bankowości internetowej to różne rzędy wielkości.

• Zakres. Liczba aplikacji i funkcji, liczba ról użytkowników do sprawdzenia, liczba adresów w infrastrukturze. Najczęstszy sposób szacowania to dni pracy testera.
• Podejście. Grey box jest zwykle najtańszy w przeliczeniu na znalezioną podatność. Black box wydłuża rozpoznanie, white box wydłuża analizę.
• Głębokość. Skan automatyczny z ręczną weryfikacją to ułamek kosztu pentestu, red teaming to jego wielokrotność.
• Formalności. Raport pod audyt, zgodność z wymaganiami regulatora, udział w spotkaniach z zarządem, obecność przy reteście.
• Powtarzalność. Umowa na cykliczne testy kosztuje mniej na jeden przebieg niż test jednorazowy, bo rozpoznanie i skrypty zostają.

Zanim poprosicie o wycenę, spiszcie, co ma być testowane, kto ma dostęp do środowiska testowego i jaki wynik chcecie dostać: listę podatności, raport pod audyt czy dowód dla klienta. To skraca wycenę z tygodnia do dnia. Ten sam sposób myślenia opisujemy w tekście o audycie procesów QA, w którym bezpieczeństwo jest jednym z obszarów.

Czy testy bezpieczeństwa może robić własny zespół QA?

Własny zespół QA może i powinien robić część testów bezpieczeństwa: automatyczne skany w pipeline (na przykład OWASP ZAP), sprawdzanie wersji komponentów, testy uprawnień i kontroli dostępu na poziomie przypadków testowych oraz przegląd wymagań pod kątem bezpieczeństwa; pentest zostaje dla specjalistów, ale zespół, który rozumie OWASP Top 10, znajduje najtańsze błędy w dniu ich powstania.

Największa część podatności z OWASP Top 10 to nie wyrafinowane ataki, tylko brak sprawdzenia, czy użytkownik A widzi dane użytkownika B, czy formularz przyjmuje wszystko, co się do niego wpisze, i czy komponent ma aktualną wersję. Te rzeczy tester funkcjonalny może sprawdzić, jeśli wie, na co patrzeć. Dlatego prowadzimy szkolenia Cybersecurity: testy bezpieczeństwa dla testerów, Automatyczne testy bezpieczeństwa z OWASP ZAP dla zespołów z pipeline, Bezpieczne tworzenie aplikacji (OWASP) dla programistów oraz Testy penetracyjne aplikacji webowej dla osób, które chcą iść dalej.

Podział ról jest prosty: zespół QA pilnuje, żeby podatności nie powstawały i łapie te najprostsze przy każdym wydaniu, pentester raz w roku sprawdza, co przeszło przez to sito. Jak rozłożyć to między testy manualne i automatyczne, opisujemy w tekście o roli testowania manualnego i automatycznego w bezpieczeństwie, a jak tester może rozwinąć się w tę stronę, w tekście Jak z perspektywy testera wejść do cybersecurity.

Jak wygląda raport z pentestu i co zrobić z wynikami?

Raport z pentestu zawiera podsumowanie dla zarządu, listę podatności z wagą (najczęściej według CVSS: krytyczna, wysoka, średnia, niska), dowód wykorzystania, skutek biznesowy i zalecenie naprawy dla każdej, opis zakresu i metodyki oraz to, czego nie testowano; z wynikami robi się trzy rzeczy: naprawia według wagi i wykorzystywalności, retestuje i wpisuje wnioski do procesu, żeby ta sama klasa błędu nie wróciła.

Podatność z raportu, przykład zapisu

Identyfikator:  WEB-03
Tytuł:          Dostęp do cudzych zamówień przez zmianę identyfikatora w adresie (IDOR)
Waga:           wysoka (CVSS 3.1: 7,5), kategoria OWASP: kontrola dostępu
Gdzie:          GET /api/orders/{id}, konto zwykłego użytkownika
Dowód:          użytkownik testowy A pobrał zamówienie 10234 użytkownika B:
                adres, telefon, cztery ostatnie cyfry karty, historia zakupów
Skutek:         wyciek danych osobowych wszystkich klientów przez proste
                zliczanie identyfikatorów; obowiązek zgłoszenia naruszenia
Zalecenie:      sprawdzanie właściciela zasobu po stronie serwera dla każdego
                żądania, identyfikatory nieprzewidywalne, test automatyczny w pipeline
Retest:         do wykonania po wdrożeniu poprawki, w oknie 30 dni

Waga według CVSS mówi, jak groźna jest podatność technicznie, ale kolejność napraw ustala się także po tym, jak łatwo ją wykorzystać i co chroni: średnia podatność w module płatności bywa pilniejsza niż wysoka w wewnętrznym narzędziu bez danych. Zgłoszenia z raportu trafiają do tego samego systemu co inne błędy, z tą samą dyscypliną opisu, o której piszemy w tekście Jak poprawnie zgłosić błąd. Retest zamyka cykl: bez niego nikt nie wie, czy naprawa zadziałała, a raport z otwartymi podatnościami krytycznymi to w razie incydentu dowód, że firma wiedziała i nie zareagowała.

Jakie są najczęstsze błędy w podejściu do testów bezpieczeństwa?

Najczęstsze błędy to kupowanie skanu w cenie pentestu, test raz na kilka lat, zakres bez API i infrastruktury, brak retestu, raport w szufladzie bez planu napraw, testowanie przez dostawcę systemu oraz przekonanie, że zapora sieciowa i certyfikat SSL załatwiają temat.

1. Skan jako pentest. Raport ze skanera z listą 400 „podatności”, z których 380 to fałszywe alarmy, a żadna z 20 prawdziwych nie została sprawdzona ręcznie.
2. Test raz na kilka lat. Obraz z dnia testu, po którym system przeszedł trzydzieści wydań i dwie migracje.
3. Zakres bez API. Aplikacja mobilna przetestowana, API, z którym rozmawia, nie. Atakujący nie używa aplikacji, używa API.
4. Brak retestu. Raport z podatnościami krytycznymi, naprawa „zrobiona”, nikt nie sprawdził.
5. Raport w szufladzie. Bez właściciela, terminów i priorytetów. Za rok ten sam raport z tymi samymi wynikami.
6. Dostawca testuje własny system. Ma powód, żeby znaleźć mniej, i nie jest niezależny w rozumieniu żadnego regulatora.
7. „Mamy zaporę i SSL.” Zapora nie widzi, że użytkownik A pobiera dane użytkownika B przez poprawne, zaszyfrowane żądanie. Większość podatności z OWASP Top 10 przechodzi przez zaporę bez śladu.

Bezpieczeństwo jest jednym z obszarów Testing Ground Conference, gdzie pentesterzy i testerzy pokazują na żywo, jak wyglądają te błędy w realnych systemach; program na testingground.pl. Wiedzę dla liderów jakości publikujemy na portalu Strefa QA.

Najczęstsze pytania o testy bezpieczeństwa i pentesty

Co to są testy penetracyjne?

Testy penetracyjne (pentesty) to kontrolowana symulacja realnego ataku, w której specjaliści w uzgodnionym zakresie próbują znaleźć i wykorzystać podatności systemu, żeby pokazać, co atakujący mógłby zrobić. Wynikiem jest raport z podatnościami ocenionymi według wagi, dowodami, skutkiem biznesowym i zaleceniami naprawy.

Czym różnią się testy bezpieczeństwa od testów penetracyjnych?

Testy bezpieczeństwa to szeroka kategoria: przeglądy konfiguracji i kodu, skany automatyczne, testy uprawnień, audyty zgodności. Testy penetracyjne to ich najbardziej praktyczna forma, w której tester wciela się w atakującego i próbuje wykorzystać podatności, a nie tylko je wyliczyć.

Czym różni się skan podatności od pentestu?

Skan podatności to automatyczne porównanie systemu ze znanymi słabościami, szybkie i tanie, ale z wieloma fałszywymi alarmami i bez logiki biznesowej. Pentest to ręczna praca specjalistów, którzy weryfikują i wykorzystują podatności, w tym błędy uprawnień i logiki, których skaner nie widzi.

Jak często wykonywać testy penetracyjne?

Rozsądne minimum to pełny pentest raz w roku i test zakresowy po każdej większej zmianie, plus skany automatyczne w pipeline przy każdym wydaniu. W sektorze finansowym DORA wymaga testowania krytycznych systemów co najmniej raz w roku, a TLPT co najmniej raz na trzy lata.

Czym różnią się testy black box, grey box i white box?

Black box: tester nie ma wiedzy o systemie, jak atakujący z zewnątrz. Grey box: ma konto użytkownika i część dokumentacji, najlepszy stosunek wyników do czasu. White box: ma kod źródłowy i pełną dokumentację, najgłębszy i najdroższy, dla systemów krytycznych.

Ile kosztują testy penetracyjne?

Zależy od zakresu (liczba aplikacji, funkcji, ról, adresów), podejścia, głębokości i wymagań formalnych. Szacuje się je najczęściej w dniach pracy testera. Przed wyceną warto spisać, co ma być testowane, kto ma dostęp do środowiska i jaki wynik ma powstać.

Czy własny zespół QA może testować bezpieczeństwo?

Tak, w części: skany automatyczne w pipeline, sprawdzanie wersji komponentów, testy uprawnień i kontroli dostępu, przegląd wymagań pod kątem bezpieczeństwa. Pentest zostaje dla specjalistów, ale zespół rozumiejący OWASP Top 10 wyłapuje najtańsze błędy w dniu ich powstania.

Co powinien zawierać raport z pentestu?

Podsumowanie dla zarządu, listę podatności z wagą według CVSS, dowodem wykorzystania, skutkiem biznesowym i zaleceniem naprawy, opis zakresu i metodyki oraz listę tego, czego nie testowano. Po naprawach powinien nastąpić retest potwierdzający zamknięcie podatności.

Powiązane na blogu Quality Island

• Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie
• Testowanie bezpieczeństwa: rola testowania manualnego i automatycznego
• Jak z perspektywy testera wejść do obszaru cybersecurity?
• Testy wydajnościowe: co to jest, rodzaje, metryki, narzędzia i jak je przeprowadzić przed sezonem
• Testy niefunkcjonalne: wydajność, bezpieczeństwo, użyteczność i niezawodność
• Testowanie e-commerce: jak przygotować sklep na Black Friday

Pełna lista źródeł

• ISTQB Glossary, hasła security testing i penetration testing
• OWASP, Top 10, Web Security Testing Guide oraz Application Security Verification Standard
• PTES, Penetration Testing Execution Standard
• FIRST, Common Vulnerability Scoring System
• MITRE, CWE Top 25 Most Dangerous Software Weaknesses
• Rozporządzenie (UE) 2022/2554 (DORA), artykuły 24 do 27, tekst w EUR-Lex
• Dane własne Quality Island: ponad 152 zrealizowane projekty, ponad 100 firm, w tym PKO BP (strategia jakości, audyt procesów QA, szkolenia zespołów); Testing Ground Conference obejmuje obszar bezpieczeństwa