Test penetracyjny – proces polegający na przeprowadzeniu kontrolowanego ataku na system teleinformatyczny, mający na celu praktyczną ocenę bieżącego stanu bezpieczeństwa tego systemu, w szczególności obecności znanych podatności i odporności na próby przełamania zabezpieczeń[1][2]. Polega na analizie systemu pod kątem występowania potencjalnych błędów bezpieczeństwa spowodowanych niewłaściwą konfiguracją, lukami w oprogramowaniu lub sprzęcie, słabościami w technicznych lub proceduralnych środkach zabezpieczeń, a nawet niewystarczającą świadomością użytkowników. Analiza ta jest przeprowadzana z perspektywy potencjalnego włamywacza i może zawierać aktywne wykorzystywanie podatności (np. poprzez użycie exploitów)[1]. Podstawową cechą odróżniającą test penetracyjny od włamania jest zgoda atakowanej strony na tego rodzaju działania[3][4], ponadto osoba przeprowadzająca test (zwana pentesterem) jest zobowiązana do przedstawienia raportu dokumentującego znalezione problemy (często wraz ze sposobami ich usunięcia i rekomendacjami podnoszącymi bezpieczeństwo testowanego systemu)[1]. Test penetracyjny ma na celu zbadanie odporności systemu na włamanie oraz skuteczności zabezpieczeń w rzeczywistej konfiguracji lub w środowisku możliwie do niej zbliżonym[1].
Test penetracyjny jest pracochłonny i wymaga dużej wiedzy fachowej. Badane systemy mogą w jego trakcie zostać uszkodzone lub unieruchomione, a ryzyka tego nie da się całkowicie wyeliminować, choć doświadczeni testerzy mogą je ograniczyć. Z tego względu test powinien być poprzedzony starannym planowaniem[1].
W 1974 roku Siły Powietrzne Stanów Zjednoczonych opublikowały wyniki analizy podatności systemu Multics, uważanego wówczas za najbezpieczniejszy dostępny system operacyjny[5]. Analizę przeprowadzono w latach 1972–1973 na potrzeby ośrodka obliczeniowego Sił Powietrznych, który miał świadczyć usługi użytkownikom w Pentagonie na wszystkich poziomach klauzuli tajności[6]. Jej autorzy, Paul Karger i Roger Schell, nie tylko szukali podatności, ale także umieścili w systemie celowo nieszkodliwą tylną furtkę, aby sprawdzić, czy zostanie wykryta podczas kontroli jakości. W samym raporcie wspomniano o niej jedynie ogólnikowo. Producent systemu, firma Honeywell, przekazał ją następnie wraz z oprogramowaniem m.in. do ośrodka obliczeniowego Sił Powietrznych w Pentagonie, a wykryto ją dopiero około roku po publikacji raportu. Analizę prowadzono z zasadą niewyrządzania rzeczywistych szkód w atakowanych systemach, a publikację raportu wstrzymano do czasu usunięcia opisanych podatności[5].
Ataki najpierw sprawdzano na instalacji systemu w Rome Air Development Center, a następnie przeprowadzano na systemie w Massachusetts Institute of Technology, starając się, tak jak prawdziwy agent, uzyskać lub zmienić chronione dane bez wykrycia przez administratorów. Raport przypominał też, że zabezpieczenia innych ówczesnych systemów, m.in. GCOS i IBM OS/360/370, wielokrotnie przełamywano w ćwiczeniach penetracyjnych, i zwracał uwagę, że zespół ekspertów testujący zabezpieczenia (tzw. tiger team) może wykazać istnienie podatności, ale nie jest w stanie dowieść ich braku[6].
Opisany w raporcie pomysł furtki w kompilatorze, która odtwarza się przy kompilowaniu samego kompilatora[6], zainspirował Kena Thompsona. Zrealizował on taką furtkę we wczesnej wersji systemu Unix i opisał ją w artykule Reflections on Trusting Trust z 1984 roku, związanym z otrzymaniem Nagrody Turinga. W 2002 roku Karger i Schell powtórzyli, że test penetracyjny może wskazać część podatności do usunięcia, ale to, że zespół testujący ich nie znalazł, nie oznacza, że ich nie ma[5].
Wytyczne NIST SP 800-115 przedstawiają przykładowy podział testu penetracyjnego na cztery fazy, zastrzegając, że dopuszczalne są również inne sposoby grupowania wykonywanych czynności[1]:
Testy penetracyjne prowadzi się w oparciu o metodyki, które nadają im powtarzalny, ustalony przebieg i pozwalają ograniczyć związane z nimi ryzyko[1]. Poszczególne metodyki różnią się szczegółowością. PTES opisuje przebieg i organizację testu bez wytycznych technicznych, a jego autorzy określają go jako minimum wymagane od podstawowego testu penetracyjnego[7][8]. Przewodnik OWASP zawiera natomiast opisy konkretnych testów[9]. Do stosowanych metodyk należą m.in.[4]:
Penetration Testing Execution Standard (PTES) opracowała grupa praktyków z instytucji finansowych, firm świadczących usługi bezpieczeństwa i producentów zabezpieczeń. Prace rozpoczęto na początku 2009 roku, po dyskusji o wartości testów penetracyjnych w branży, a celem było wypracowanie wspólnego języka i zakresu testów zarówno dla zamawiających je firm, jak i dla wykonawców[8].
Standard dzieli test na siedem części: ustalenia poprzedzające test, zbieranie informacji, modelowanie zagrożeń, analizę podatności, wykorzystanie podatności, etap post-exploitation oraz raportowanie[7]. Celem etapu post-exploitation jest ocena wartości przejętego systemu, o której decyduje wrażliwość przechowywanych na nim danych oraz jego przydatność do przejmowania kolejnych systemów w sieci[16]. Raport ma obejmować zarówno część przeznaczoną dla kierownictwa, jak i część techniczną[8]. Sam standard nie zawiera wytycznych technicznych dotyczących przeprowadzenia testu, dlatego uzupełnia go osobny dokument techniczny[7].
Standard określa również zasady postępowania z przejętymi systemami. Tester prowadzi wykaz wykonanych na nich działań wraz z czasem ich wykonania, dołączany do raportu końcowego, a po zakończeniu testu usuwa pozostawione przez siebie pliki i narzędzia oraz utworzone konta i przywraca zmienione ustawienia. Dzienników zdarzeń nie wolno usuwać ani modyfikować bez wyraźnej zgody zamawiającego, a hasła i inne dane wrażliwe umieszczane w raporcie muszą być zamaskowane. Jeżeli w badanym środowisku zostaną znalezione ślady wcześniejszego włamania, zapis działań testera zostaje zabezpieczony i przekazany zamawiającemu, który decyduje o dalszym postępowaniu[16].
Przewodnikiem OWASP dotyczącym testowania aplikacji internetowych jest Web Security Testing Guide (WSTG), opisujący testowanie bezpieczeństwa aplikacji internetowych i usług sieciowych i tworzony wspólnie przez specjalistów i wolontariuszy. Według OWASP stanowi on zbiór dobrych praktyk stosowanych przez pentesterów i organizacje na całym świecie[9]. Aktualną stabilną wersją jest 4.2, wydana w grudniu 2020 roku[17], a trwają prace nad wersją 5.0[9].
Test penetracyjny może być prowadzony przy różnym poziomie wiedzy zespołu testującego, z dwiema skrajnymi wartościami[4]:
Test zewnętrzny prowadzi się z internetu, z perspektywy napastnika z zewnątrz. Test wewnętrzny prowadzi się z sieci lokalnej (LAN) organizacji, z pozycji zaufanego pracownika albo napastnika, który przełamał już zabezpieczenia brzegowe[1].
Test jawny prowadzi się za wiedzą i zgodą działu informatycznego organizacji, a niejawny bez jego wiedzy, lecz za zgodą najwyższego kierownictwa. Test niejawny pozwala sprawdzić także reakcję personelu na atak i ponieważ administratorzy nie są na niego przygotowani, lepiej oddaje codzienny stan bezpieczeństwa organizacji. Jest jednak bardziej czasochłonny i kosztowny, dlatego częściej stosuje się testy jawne[1].
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), stosowane od 17 stycznia 2025 roku, wymaga od podmiotów finansowych prowadzenia programu testowania, obejmującego m.in. testy penetracyjne[19][20][21]. Podmioty wyznaczone przez właściwe organy nadzoru muszą ponadto przeprowadzać, co do zasady co trzy lata, zaawansowane testy w formie testów penetracyjnych ukierunkowanych przez analizę zagrożeń (ang. threat-led penetration testing, TLPT). Jeżeli podmiot korzysta przy tych testach z własnych testerów, co trzeci test musi zlecić testerom zewnętrznym[22].
Rozporządzenie definiuje TLPT jako ramy naśladujące taktykę, techniki i procedury rzeczywistych agresorów, w których przeprowadza się kontrolowane, dostosowane do podmiotu i oparte na analizie zebranych danych testy typu red team, obejmujące działające krytyczne systemy produkcyjne podmiotu finansowego. Każdy taki test obejmuje kilka lub wszystkie krytyczne lub istotne funkcje podmiotu[20]. Europejskie urzędy nadzoru odróżniają go od klasycznego testu penetracyjnego, który szczegółowo ocenia podatności techniczne i konfiguracyjne, często pojedynczego systemu, ale nie odtwarza pełnego scenariusza ukierunkowanego ataku na całą organizację, obejmującego jej ludzi, procesy i technologie[22].
Test poprzedza analiza zagrożeń (ang. threat intelligence), na podstawie której przygotowuje się scenariusze ataku. Standardy techniczne opracowane przez europejskie urzędy nadzoru przewidują, że aktywna faza testu trwa co najmniej 12 tygodni, co ma pozwolić na naśladowanie trudnych do wykrycia napastników. Test jest niejawny, a pracownicy odpowiedzialni za obronę (blue team) dowiadują się o nim dopiero po zakończeniu fazy aktywnej[22]. Wymogi dotyczące TLPT oparto na dobrowolnych ramach TIBER-EU, opracowanych przez Europejski Bank Centralny i banki centralne państw UE i opublikowanych w maju 2018 roku[22]. Według EBC podstawowe wymagania obu ram są identyczne, dlatego test przeprowadzony zgodnie z TIBER-EU spełnia wymogi DORA, o ile podmiot dopełni formalności określonych przez organy nadzoru[21].
Audyt bezpieczeństwa teleinformatycznego nie jest tym samym co test penetracyjny. Audyt opiera się na formalnej specyfikacji stanu pożądanego (normie, akcie prawnym) i prowadzi do jednoznacznego określenia stopnia zgodności audytowanego obiektu ze specyfikacją. Test penetracyjny służy do określenia faktycznego stanu bezpieczeństwa danego obiektu i nie musi być oparty na jakiejś szczególnej specyfikacji[2].
Skanowanie podatności polega na wykryciu, uszeregowaniu i zgłoszeniu znanych podatności za pomocą narzędzi automatycznych. Test penetracyjny ma natomiast wykazać, jak podatności można wykorzystać do obejścia zabezpieczeń. Jest w zasadzie procesem ręcznym, w którym narzędzia automatyczne pełnią rolę pomocniczą, i może trwać dni lub tygodnie. Według wytycznych PCI DSS samo uruchomienie narzędzia automatycznego nie spełnia wymogu przeprowadzenia testu penetracyjnego, ponieważ narzędzie nie ocenia rzeczywistego ryzyka, a jego wyniki musi zinterpretować tester[4]. Test pozwala też wykryć połączenia podatności, które razem dają napastnikowi większy dostęp niż każda z osobna, czego skaner oceniający podatności pojedynczo nie wychwytuje[1].
Według wytycznych PCI SSC certyfikaty mogą świadczyć o umiejętnościach i kompetencjach pentestera, choć nie są wymagane. Same certyfikaty nie potwierdzają jednak kwalifikacji, dlatego przy wyborze testera istotne jest również jego doświadczenie, m.in. liczba lat pracy przy testach penetracyjnych i wcześniejsze testy środowisk o podobnej skali. Jako przykłady certyfikatów wytyczne wymieniają m.in. OSCP oraz certyfikaty GIAC[4]. Do certyfikatów z zakresu testów penetracyjnych należą m.in.:
