Pentest

Co to jest pentest (test penetracyjny)?

Pentest (test penetracyjny) to kontrolowany test bezpieczeństwa, w którym specjaliści na zlecenie i za zgodą organizacji odtwarzają techniki stosowane przez atakujących, aby znaleźć i potwierdzić podatności w systemach, sieciach lub aplikacjach, błędy w konfiguracji rozwiązań cyberbezpieczeństwa lub luki w strategii obrony. Zgodnie z definicją NIST SP 800-115, w teście penetracyjnym testerzy naśladują rzeczywiste ataki, aby wskazać sposoby obejścia zabezpieczeń aplikacji, systemów lub sieci. Wynikiem testu jest raport z opisem wykrytych podatności i rekomendacjami ich usunięcia.

Testy penetracyjne należą do form testowania systemów, do których odwołują się przepisy obowiązujące w Polsce. Rozporządzenie DORA wymienia je wśród testów operacyjnej odporności cyfrowej sektora finansowego, a Ustawa o Krajowym Systemie Cyberbezpieczeństwa zalicza testowanie systemu informacyjnego do środków zarządzania ryzykiem.

Czym pentest różni się od skanowania podatności?

Skanowanie podatności to zautomatyzowane sprawdzanie systemów pod kątem znanych słabości, na przykład nieaktualnego oprogramowania lub błędnej konfiguracji. Skaner porównuje wersje i ustawienia systemów z bazą znanych podatności. Dzięki automatyzacji skaner może w krótkim czasie przeanalizować wiele systemów i nadaje się do regularnego stosowania.

Test penetracyjny obejmuje także praktyczną weryfikację wykrytych luk. Według NIST SP 800-115 skaner wskazuje jedynie, że podatność może występować, natomiast w fazie ataku tester próbuje ją wykorzystać, aby potwierdzić, że rzeczywiście istnieje. Tester może też połączyć kilka luk, z których każda osobno wydaje się mało groźna, w ścieżkę prowadzącą do przejęcia systemu. Brytyjskie NCSC zaznacza w wytycznych o skanerach podatności, że narzędzia automatyczne nie badają środowiska tak wszechstronnie i dogłębnie jak test penetracyjny. Z kolei w wytycznych dotyczących testów penetracyjnych NCSC wskazuje, że pentest nie powinien być podstawową metodą wyszukiwania podatności. W praktyce oba podejścia się uzupełniają: skanowanie pozwala na bieżąco wychwytywać znane problemy, a pentest weryfikuje, jak trudno jest je faktycznie wykorzystać.

Red teaming to ćwiczenie o zwykle szerszym zasięgu niż pentest. Zespół Red Team nie szuka możliwie wielu podatności w wyznaczonych systemach, lecz sprawdza, czy atakujący może osiągnąć konkretny cel w całej organizacji i czy zespół odpowiedzialny za obronę zdoła go wykryć.

Jakie są rodzaje testów penetracyjnych?

Testy penetracyjne dzieli się najczęściej według dwóch kryteriów: obiektu, który jest testowany, oraz zakresu informacji, jakie tester otrzymuje przed rozpoczęciem pracy.

Podział według obiektu testu

Zakres testu dobiera się do tego, co organizacja chce sprawdzić. Do najczęściej wykonywanych należą m.in.:

• testy infrastruktury zewnętrznej, które obejmują systemy dostępne z internetu, takie jak serwery, firewalle i bramy VPN,
• testy infrastruktury wewnętrznej, które sprawdzają, co może osiągnąć atakujący po uzyskaniu dostępu do sieci firmowej, na przykład w środowisku Active Directory,
• testy aplikacji webowych i mobilnych; dla aplikacji webowych punktem odniesienia jest zwykle metodyka OWASP Web Security Testing Guide,
• testy środowisk chmurowych, które obejmują m.in. konfigurację usług, uprawnienia i sposób izolacji zasobów,
• testy sieci bezprzewodowych, które dotyczą zabezpieczeń Wi-Fi i dostępu do sieci z otoczenia budynku,
• testy socjotechniczne, na przykład kontrolowane kampanie phishingowe, które oceniają reakcje pracowników.

Black box, grey box i white box

Drugi podział opisuje, ile informacji o testowanym środowisku tester otrzymuje na początku. W teście typu black box tester nie zna wewnętrznej budowy systemu i działa podobnie jak atakujący z zewnątrz. W teście typu white box tester otrzymuje pełne informacje o środowisku, na przykład dokumentację, konfigurację lub kod źródłowy. Test typu grey box łączy oba podejścia: tester otrzymuje część informacji lub uprawnień, na przykład dane logowania zwykłego użytkownika.

Nazewnictwo nie jest w pełni ujednolicone. NIST SP 800-115 opisuje white box i black box jako techniki testowania aplikacji, odpowiednio z dostępem do kodu źródłowego i bez niego, a brytyjskie NCSC posługuje się określeniami „open box” i „closed box”. Wybór wariantu zależy od celu testu. Black box lepiej odzwierciedla perspektywę zewnętrznego atakującego, jednak NCSC zwraca uwagę, że przy braku informacji o środowisku część podatności może pozostać niewykryta w czasie przewidzianym na test.

Jak przebiega pentest?

NIST SP 800-115 dzieli test penetracyjny na cztery fazy: planowanie, rozpoznanie, atak i raportowanie. Inne uznane metodyki opisują test w odmienny sposób. PTES (Penetration Testing Execution Standard) wyróżnia siedem etapów, od ustaleń przed rozpoczęciem testu po raportowanie. OWASP Web Security Testing Guide w wersji 4.2 zawiera katalog testów aplikacji webowych, a OSSTMM, opracowany przez ISECOM, opisuje testowanie bezpieczeństwa w kilku obszarach, które metodyka nazywa kanałami, m.in. w obszarze ludzkim, fizycznym i sieciowym.

Krok 1: Planowanie i ustalenie zakresu

W fazie planowania organizacja i zespół testujący ustalają cele testu, systemy objęte badaniem, dozwolone techniki, terminy oraz osoby kontaktowe po obu stronach. Ustalenia te zapisuje się w umowie i w zasadach testu (rules of engagement). Dzięki temu tester działa w granicach udzielonej zgody, a organizacja wie, kiedy może spodziewać się nietypowego ruchu w sieci.

Krok 2: Rozpoznanie

Faza rozpoznania (discovery) polega na zebraniu informacji o testowanym środowisku. Tester identyfikuje dostępne hosty, otwarte porty, usługi i ich wersje, a następnie porównuje zebrane dane z bazami znanych podatności. Na tym etapie zwykle wykorzystuje się skanery podatności. Ich wyniki wymagają jednak weryfikacji, ponieważ skaner może wskazać podatność, która w danym środowisku nie występuje lub której nie da się wykorzystać.

Krok 3: Atak i weryfikacja podatności

W fazie ataku tester próbuje wykorzystać znalezione podatności, aby potwierdzić, że rzeczywiście występują, i sprawdzić, jaki dostęp można dzięki nim uzyskać. Po uzyskaniu szerszego dostępu do środowiska, na przykład przez przejęcie konta lub eskalację uprawnień, tester zwykle wraca do fazy rozpoznania, ponieważ nowe uprawnienia mogą umożliwić dostęp do kolejnych systemów. Według NIST ta pętla między rozpoznaniem a atakiem jest typowym elementem testu penetracyjnego.

Krok 4: Raportowanie

Raportowanie odbywa się równolegle z pozostałymi fazami. Tester na bieżąco dokumentuje swoje działania. NIST zaleca, aby tester niezwłocznie, jeszcze w trakcie testu, informował osobę wskazaną w planie testu o podatnościach krytycznych, na przykład takich, które umożliwiają przejęcie uprawnień administratora w ważnym systemie. Po zakończeniu testu zespół testujący przygotowuje raport końcowy, który opisuje wykryte podatności, sposób ich wykorzystania i zalecane działania naprawcze.

Co powinien zawierać raport z testu penetracyjnego?

Raport z testu penetracyjnego zawiera zwykle podsumowanie dla kierownictwa oraz część techniczną dla zespołów IT. Część techniczna powinna zawierać dla każdej podatności opis, dowód jej wykorzystania, ocenę krytyczności oraz zalecenia dotyczące jej usunięcia. Dzięki temu administratorzy mogą odtworzyć problem i sprawdzić, czy wdrożona poprawka go usuwa.

Do oceny krytyczności podatności stosuje się najczęściej standard CVSS (Common Vulnerability Scoring System), obecnie w wersji 4.0 opublikowanej przez organizację FIRST w 2023 roku. FIRST zaznacza jednak, że bazowa ocena CVSS opisuje krytyczność samej podatności i nie powinna być jedynym kryterium przy szacowaniu ryzyka. Ta sama podatność może mieć inne znaczenie w systemie produkcyjnym przetwarzającym dane klientów niż w odizolowanym środowisku testowym. Dlatego kolejność napraw warto ustalać na podstawie oceny CVSS uzupełnionej o znaczenie systemu dla organizacji i dostępność publicznych exploitów.

Ostatnim elementem procesu jest zwykle test powtórny (retest), który pozwala sprawdzić, czy podatności zostały skutecznie usunięte. Bez testu powtórnego organizacja nie ma pewności, czy wdrożone poprawki rzeczywiście zablokowały ścieżki ataku opisane w raporcie.

Czy test penetracyjny jest obowiązkowy?

Obowiązek przeprowadzania testów penetracyjnych zależy od sektora i przepisów, którym podlega organizacja. Część regulacji wymienia pentesty wprost, a inne ogólnie wymagają testowania i oceny skuteczności zabezpieczeń, pozostawiając samej organizacji wybór metody.

Testy penetracyjne w rozporządzeniu DORA

Rozporządzenie DORA zobowiązuje podmioty finansowe inne niż mikroprzedsiębiorstwa do prowadzenia programu testowania operacyjnej odporności cyfrowej. Art. 25 ust. 1 wymienia testy penetracyjne wśród przykładowych testów, obok m.in. ocen podatności, przeglądów kodu źródłowego i testów scenariuszowych. Testy przeprowadzają niezależne strony wewnętrzne lub zewnętrzne (art. 24 ust. 4). Ponadto podmioty finansowe muszą co najmniej raz w roku przeprowadzić odpowiednie testy wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje (art. 24 ust. 6). Przepis nie nakazuje więc corocznego pentestu wszystkich systemów, lecz odpowiedniego testowania systemów wspierających funkcje krytyczne lub istotne. Formę tego testowania podmiot dobiera proporcjonalnie do ryzyka. DORA przewiduje dodatkowo zaawansowane testy penetracyjne pod kątem wyszukiwania zagrożeń (TLPT, Threat-Led Penetration Testing) dla podmiotów wskazanych przez organ nadzoru. Testy te przeprowadza się co najmniej raz na trzy lata, choć organ nadzoru może zmienić tę częstotliwość.

NIS2 i ustawa o krajowym systemie cyberbezpieczeństwa

Dyrektywa NIS2 i ustawa o krajowym systemie cyberbezpieczeństwa nie wymieniają testów penetracyjnych z nazwy. Ustawa w art. 8 ust. 1 pkt 2 zalicza do środków zarządzania ryzykiem m.in. testowanie systemu informacyjnego oraz polityki i procedury oceny skuteczności środków technicznych i organizacyjnych. Test penetracyjny może być jedną z metod realizacji tych wymagań, obok skanowania podatności i audytów bezpieczeństwa. Wybór metody należy do podmiotu kluczowego lub ważnego, który powinien oprzeć go na wynikach szacowania ryzyka.

Wymogi sektorowe: PCI DSS i norma ISO/IEC 27001

Standard PCI DSS w wersji 4.0 i jej aktualizacji 4.0.1, stosowany przez organizacje przetwarzające dane kart płatniczych, w wymaganiach 11.4.2 i 11.4.3 nakłada obowiązek przeprowadzania wewnętrznych i zewnętrznych testów penetracyjnych co najmniej raz na 12 miesięcy oraz po każdej istotnej zmianie infrastruktury lub aplikacji. Test musi wykonać osoba o odpowiednich kwalifikacjach, niezależna organizacyjnie od testowanego środowiska, przy czym może to być pracownik organizacji. Zgodnie z wymaganiem 11.4.4 wykryte podatności należy usunąć, a skuteczność poprawek potwierdzić testem powtórnym.

Norma ISO/IEC 27001 zawiera zabezpieczenia dotyczące testowania bezpieczeństwa i zarządzania podatnościami technicznymi, jednak certyfikacja według tej normy jest dobrowolna, o ile przepis lub umowa nie stanowi inaczej.

Dlaczego test penetracyjny wymaga pisemnej zgody?

Pentest polega na celowym przełamywaniu zabezpieczeń, dlatego bez zgody właściciela systemu mógłby zostać uznany za przestępstwo. Zgodnie z art. 267 § 2 Kodeksu karnego karze podlega ten, kto bez uprawnienia uzyskuje dostęp do całości lub części systemu informatycznego. Zlecony test penetracyjny opiera się na uprawnieniu udzielonym przez dysponenta systemu, które zapisuje się w umowie wraz z zakresem testu, dozwolonymi technikami i terminami.

Od 2017 roku Kodeks karny zawiera art. 269c, który w określonych warunkach wyłącza karalność za przestępstwa z art. 267 § 2 lub art. 269a. Przepis dotyczy osoby, która działa wyłącznie w celu zabezpieczenia systemu lub opracowania metody takiego zabezpieczenia. Osoba ta musi niezwłocznie powiadomić dysponenta systemu o ujawnionych zagrożeniach, a jej działanie nie może naruszyć interesu publicznego lub prywatnego ani wyrządzić szkody. Przepis nie zastępuje jednak zgody na zlecony test, ponieważ obejmuje tylko wybrane przestępstwa i wymaga spełnienia wszystkich wymienionych warunków.

W praktyce pisemna zgoda chroni obie strony. Tester ma podstawę prawną swoich działań, a organizacja może wcześniej określić, których systemów nie wolno testować, w jakich godzinach test może się odbywać i kogo należy powiadomić w razie awarii.

Od czego zależą koszt i częstotliwość testów penetracyjnych?

Koszt testu penetracyjnego zależy przede wszystkim od jego zakresu. Według wytycznych brytyjskiego NCSC przed testem należy określić m.in. granice techniczne badanego środowiska, rodzaje testów i scenariuszy, przewidywaną liczbę dni pracy, wymagania regulacyjne, oczekiwaną formę raportu oraz ograniczenia czasowe. Od tych ustaleń zależy czas pracy zespołu testującego, a w konsekwencji koszt testu. NIST podkreśla też, że testy penetracyjne są pracochłonne i wymagają dużej wiedzy eksperckiej.

Częstotliwość testów wynika zwykle z wymagań regulacyjnych i z tempa zmian w środowisku. PCI DSS wymaga testu co najmniej raz na 12 miesięcy i po każdej istotnej zmianie, a DORA nakłada obowiązek corocznego testowania systemów wspierających funkcje krytyczne lub istotne. Niezależnie od przepisów, test warto powtórzyć po wdrożeniu nowej aplikacji, migracji do chmury lub większej zmianie w architekturze sieci.

Pentest pokazuje stan zabezpieczeń w momencie testu, dlatego można go uzupełnić programem CTEM (Continuous Threat Exposure Management), czyli opracowanym przez firmę Gartner pięcioetapowym modelem zarządzania ekspozycją na zagrożenia. CTEM to proces ciągły i strategiczny, podczas gdy test penetracyjny jest jednorazową oceną techniczną. W odróżnieniu od pentestu program CTEM ustala priorytety na podstawie wartości biznesowej zasobów, a nie tylko technicznych podatności, i działa w trybie ciągłym.

Pojęcia powiązane z pentestem