Test penetracyjny

Artykuł ten został zgłoszony do umieszczenia na stronie głównej w rubryce „Czy wiesz”.
Pomóż nam go sprawdzić: oceń zgłoszoną nominację.

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ń. 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). Podstawową cechą odróżniającą test penetracyjny od włamania jest zgoda atakowanej strony na tego rodzaju działania, 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). 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.

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.

Historia

W październiku 1972 roku James P. Anderson stwierdził w opracowanym dla Sił Powietrznych Stanów Zjednoczonych studium Computer Security Technology Planning Study, że ówczesne komercyjnie dostępne komputery i systemy operacyjne nie zapewniają odpowiedniego wsparcia dla bezpieczeństwa, a doświadczeni programiści bez większych trudności przełamywali ich zabezpieczenia i odczytywali potrzebne dane. Próby certyfikacji systemów oparte na testach penetracyjnych kończyły się zwykle odmową certyfikacji, ale nawet nieudana próba przełamania zabezpieczeń nie dawałaby podstaw do certyfikacji, ponieważ w dużym, istniejącym systemie zawsze może istnieć jeszcze nieodkryta droga dostępu.

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. 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. 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.

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.

Opisany w raporcie pomysł furtki w kompilatorze, która odtwarza się przy kompilowaniu samego kompilatora, 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.

Fazy testu penetracyjnego

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:

Zasady zaangażowania

Przed rozpoczęciem testu należy udokumentować i uzgodnić warunki, w jakich będzie on prowadzony, oraz dopuszczalny stopień wykorzystania podatności, o ile w ogóle jest ono dozwolone. Takie zasady zaangażowania (ang. rules of engagement) upoważniają testera do badania środowiska i pozwalają organizacji zrozumieć, czego może się spodziewać po teście. Wytyczne PCI SSC podają przykłady kwestii, które można w nich rozstrzygnąć: w jakim oknie czasowym prowadzić test, jak testować starsze systemy sprawiające problemy przy automatycznym skanowaniu, w jaki sposób komunikować się w trakcie testu, czy zabezpieczenia mogące wykryć lub zablokować test wyłączyć albo tak skonfigurować, by mu nie przeszkadzały, czy tester ma ujawnić listę haseł i innych danych wrażliwych, do których uzyskał dostęp, jak zapewnić, by sprzęt testera przyłączany do sieci organizacji nie stanowił dla niej zagrożenia, czy tester ma podać adresy IP, z których będzie prowadzony test, oraz co zrobić w razie wykrycia wcześniejszego lub trwającego włamania, na przykład uruchomić procedury reagowania na incydenty i wstrzymać test do czasu wyjaśnienia sytuacji.

Jeżeli umowa o poziomie usług z podmiotem zewnętrznym, takim jak dostawca usług hostingowych lub chmurowych, wymaga jego zgody na przeprowadzenie testu, organizacja musi ją uzyskać przed rozpoczęciem testu. Zasady zaangażowania powinny też określać kryteria powodzenia testu, czyli moment, w którym test uznaje się za zakończony, co pozwala ograniczyć jego głębokość. Bez takiego ustalenia tester może przekroczyć granice i oczekiwania zamawiającego.

Raport i działania po teście

Według wytycznych PCI SSC raport z testu ma pomóc organizacji w poprawie stanu bezpieczeństwa przez wskazanie obszarów potencjalnego ryzyka, które mogą wymagać usunięcia. Samo przedstawienie listy podatności nie służy temu celowi i nie odpowiada założeniom testu penetracyjnego, a raport powinien jasno przedstawiać, co przetestowano, w jaki sposób i z jakim wynikiem. Wytyczne zastrzegają, że proponowany przez nie układ raportu ma charakter przykładowy i odzwierciedla dane zebrane od wielu firm prowadzących testy oraz oczekiwania klientów. Układ ten obejmuje krótkie streszczenie zakresu testu i najważniejszych ustaleń, szczegółowy opis zakresu, opis zastosowanej metodyki, ograniczenia nałożone na test, takie jak wyznaczone godziny testów, limity przepustowości czy szczególne wymagania dotyczące starszych systemów, opis przebiegu testu, podsumowanie testów segmentacji sieci, jeżeli segmentacja służy ograniczeniu zakresu objętego standardem PCI DSS, opis ustaleń, wykaz użytych narzędzi oraz wskazówki dotyczące czynności potrzebnych do przywrócenia środowiska po teście. Opis każdego ustalenia obejmuje to, czy i w jaki sposób daną podatność można wykorzystać do ataku na środowisko danych posiadaczy kart, ocenę ryzyka lub wagi podatności, systemy, których dotyczy, odwołania do baz takich jak CVE i CWE oraz opis ustalenia.

Organizacja powinna w rozsądnym czasie po teście usunąć każdą podatność możliwą do wykorzystania, a po wdrożeniu poprawek tester powinien przeprowadzić test ponowny, aby sprawdzić, czy nowe zabezpieczenia ograniczają pierwotne ryzyko. Tester powinien też udokumentować i przekazać organizacji wszystkie zmiany wprowadzone w środowisku podczas testu w granicach dopuszczonych zasadami zaangażowania, na przykład konta utworzone na potrzeby testu, które organizacja powinna następnie usunąć.

Metodyki testów penetracyjnych

Testy penetracyjne prowadzi się w oparciu o metodyki, które nadają im powtarzalny, ustalony przebieg i pozwalają ograniczyć związane z nimi ryzyko. 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. Przewodnik OWASP zawiera natomiast opisy konkretnych testów. Do stosowanych metodyk należą m.in.:

PTES

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.

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. 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. Raport ma obejmować zarówno część przeznaczoną dla kierownictwa, jak i część techniczną. Sam standard nie zawiera wytycznych technicznych dotyczących przeprowadzenia testu, dlatego uzupełnia go osobny dokument techniczny.

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.

OWASP Web Security Testing Guide

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. Aktualną stabilną wersją jest 4.2, wydana w grudniu 2020 roku, a trwają prace nad wersją 5.0.

Rodzaje testów penetracyjnych

Test penetracyjny może być prowadzony przy różnym poziomie wiedzy zespołu testującego, z dwiema skrajnymi wartościami:

Testy zewnętrzne i wewnętrzne

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.

Testy jawne i niejawne

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.

Testy socjotechniczne i fizyczne

Test penetracyjny często obejmuje również nietechniczne metody ataku. Tester może na przykład przełamać fizyczne zabezpieczenia i procedury, aby przyłączyć się do sieci, ukraść sprzęt, przechwycić informacje wrażliwe, choćby przez zainstalowanie urządzeń rejestrujących naciśnięcia klawiszy, albo zakłócić łączność. Testy zabezpieczeń fizycznych wymagają ostrożności, a pracownicy ochrony powinni wiedzieć, jak sprawdzić, czy działania testera są uprawnione, na przykład przez kontakt z wyznaczoną osobą lub dokumenty. Inną nietechniczną metodą jest socjotechnika, na przykład podawanie się za pracownika działu wsparcia technicznego i proszenie użytkownika o hasło albo dzwonienie do działu wsparcia w imieniu użytkownika z prośbą o zresetowanie hasła.

Socjotechnika polega na nakłonieniu kogoś podstępem do ujawnienia informacji, na przykład hasła, które można wykorzystać do ataku na systemy lub sieci. Testy socjotechniczne sprawdzają czynnik ludzki i świadomość bezpieczeństwa użytkowników i mogą ujawnić słabości w ich zachowaniu, takie jak nieprzestrzeganie standardowych procedur. Mogą być prowadzone w rozmowach osobistych lub telefonicznych albo drogą elektroniczną, na przykład przez pocztę elektroniczną lub komunikatory, czego przykładem jest phishing. Mogą być skierowane do szczególnie ważnych osób lub grup, takich jak kadra kierownicza, albo do szerokiego grona odbiorców. Atak skierowany do konkretnych osób może narazić je na zakłopotanie, jeśli testerom uda się uzyskać od nich informacje lub dostęp. Wyniki testów socjotechnicznych powinny służyć poprawie bezpieczeństwa organizacji, a nie wskazywaniu poszczególnych osób. Tester powinien przygotować szczegółowy raport końcowy, opisujący zarówno skuteczne, jak i nieskuteczne taktyki, co pozwala organizacji dopasować programy szkoleń z zakresu bezpieczeństwa.

Ujęcie w standardach

W katalogu zabezpieczeń NIST SP 800-53 w wersji 5 testom penetracyjnym poświęcono zabezpieczenie CA-8 (Penetration Testing), które wymaga prowadzenia testów penetracyjnych z określoną przez organizację częstotliwością na wskazanych przez nią systemach lub ich komponentach. W omówieniu zabezpieczenia NIST określa test penetracyjny jako wyspecjalizowany rodzaj oceny, służący wykryciu podatności, które mogliby wykorzystać napastnicy. Test wykracza poza automatyczne skanowanie podatności i prowadzą go osoby lub zespoły o wykazanych umiejętnościach i doświadczeniu, obejmujących wiedzę techniczną z zakresu bezpieczeństwa sieci, systemów operacyjnych lub aplikacji. Pozwala potwierdzić istnienie podatności albo określić odporność systemów na napastników w przyjętych ograniczeniach czasu, zasobów i umiejętności, a naśladując działania napastników, zapewnia głębszą analizę słabości i braków w zakresie bezpieczeństwa i ochrony prywatności. Według NIST testy są szczególnie ważne przy przechodzeniu na nowsze technologie, na przykład z protokołu IPv4 na IPv6. Mogą być prowadzone wewnętrznie lub zewnętrznie, obejmować sprzęt, oprogramowanie i oprogramowanie układowe systemu oraz sprawdzać zabezpieczenia zarówno fizyczne, jak i techniczne. Standardowa metoda obejmuje analizę przed testem, opartą na pełnej wiedzy o systemie, wstępne wskazanie na jej podstawie potencjalnych podatności oraz testy sprawdzające, czy można je wykorzystać. Przed rozpoczęciem testu wszystkie strony uzgadniają zasady zaangażowania, dopasowane do narzędzi, technik i procedur, których można się spodziewać po napastnikach. Test może ujawnić testerom informacje chronione przepisami prawa, a zasady zaangażowania, umowy lub inne mechanizmy mogą służyć do określenia, jak należy je chronić. Decyzje o wymaganym stopniu niezależności testerów podejmuje się na podstawie oceny ryzyka.

Rozszerzenia zabezpieczenia CA-8 przewidują zlecanie testów niezależnym testerom lub zespołom, czyli takim, którzy prowadzą testy bezstronnie i nie mają rzeczywistych ani postrzeganych konfliktów interesów związanych z tworzeniem, eksploatacją lub zarządzaniem testowanymi systemami. Kolejne rozszerzenie dotyczy ćwiczeń typu red team, które poszerzają cele testu penetracyjnego o ocenę stanu bezpieczeństwa i ochrony prywatności całej organizacji oraz jej zdolności do skutecznej obrony. Ćwiczenia te symulują próby naruszenia przez napastników funkcji realizowanych przez organizację. Mogą obejmować ataki techniczne, dotyczące sprzętu, oprogramowania lub procesów organizacji, oraz ataki socjotechniczne, prowadzone przez pocztę elektroniczną, telefon, podglądanie (ang. shoulder surfing) lub rozmowy osobiste. Podczas gdy testy penetracyjne mogą być prowadzone głównie w warunkach laboratoryjnych, ćwiczenia red team pozwalają na pełniejszą ocenę, odzwierciedlającą warunki rzeczywiste. Osobne rozszerzenie dotyczy testów fizycznych, czyli zapowiedzianych lub niezapowiedzianych prób obejścia zabezpieczeń punktów fizycznego dostępu do obiektu, które mogą ujawnić krytyczne podatności w środowisku działania systemów organizacji.

Testy penetracyjne ukierunkowane przez analizę zagrożeń

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. 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.

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. 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.

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. 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. 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.

Test penetracyjny a audyt

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.

Test penetracyjny a skanowanie podatności

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. 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.

Certyfikaty

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. Do certyfikatów z zakresu testów penetracyjnych należą m.in.:

Zobacz też

Przypisy

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Karen Scarfone, Murugiah Souppaya, Amanda Cody, Angela Orebaugh, NIST SP 800-115: Technical Guide to Information Security Testing and Assessment, National Institute of Standards and Technology, wrzesień 2008, DOI: 10.6028/NIST.SP.800-115 [dostęp 2026-10-11] (ang.).
  2. 1 2 Krzysztof Liderman, Czy „audyt bezpieczeństwa teleinformatycznego” jest tym samym co „audyt informatyczny”?, „Biuletyn Instytutu Automatyki i Robotyki” (21), 2004, s. 77–103 [dostęp 2026-09-24].
  3. 1 2 3 OSSTMM 3: The Open Source Security Testing Methodology Manual, wyd. 3.02, Institute for Security and Open Methodologies (ISECOM), 14 grudnia 2010 [dostęp 2026-09-24] (ang.).
  4. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Penetration Test Guidance Special Interest Group, Information Supplement: Penetration Testing Guidance, wyd. 1.1, PCI Security Standards Council, wrzesień 2017 [dostęp 2026-10-11] (ang.).
  5. ↑ James P. Anderson, Computer Security Technology Planning Study. Volume II, Electronic Systems Division, US Air Force, październik 1972, s. 10–11 [dostęp 2026-10-11] (ang.).
  6. 1 2 3 Paul A. Karger, Roger R. Schell, Thirty Years Later: Lessons from the Multics Security Evaluation, „Proceedings of the 18th Annual Computer Security Applications Conference (ACSAC 2002)”, IEEE, 2002, s. 119–126 [dostęp 2026-09-25] (ang.).
  7. 1 2 3 Paul A. Karger, Roger R. Schell, Multics Security Evaluation: Vulnerability Analysis (ESD-TR-74-193, t. II), Electronic Systems Division, US Air Force, Hanscom AFB, czerwiec 1974 [dostęp 2026-09-25] (ang.).
  8. 1 2 3 4 The Penetration Testing Execution Standard. pentest-standard.org. [dostęp 2026-10-11]. (ang.).
  9. 1 2 3 FAQ – The Penetration Testing Execution Standard. pentest-standard.org. [dostęp 2026-09-24]. (ang.).
  10. 1 2 3 4 OWASP Web Security Testing Guide. OWASP. [dostęp 2026-09-24]. (ang.).
  11. ↑ OWASP Application Security Verification Standard. OWASP. [dostęp 2026-09-25]. (ang.).
  12. ↑ OWASP MASVS – OWASP Mobile Application Security. OWASP. [dostęp 2026-09-24]. (ang.).
  13. ↑ OWASP Top 10 for Large Language Model Applications, wyd. 2026, OWASP GenAI Security Project, 4 sierpnia 2026, DOI: 10.5281/zenodo.22109015 [dostęp 2026-09-24] (ang.).
  14. ↑ John Wack, Miles Tracy, Murugiah Souppaya, NIST SP 800-42: Guideline on Network Security Testing, National Institute of Standards and Technology, październik 2003, DOI: 10.6028/NIST.SP.800-42 [dostęp 2026-09-24] (ang.).
  15. ↑ Web Security Testing Guide v4.1: Penetration Testing Methodologies. OWASP. [dostęp 2026-09-24]. (ang.).
  16. ↑ ISAAF (OISSG Penetration Testing Framework, 2008). oissg.org. [zarchiwizowane z tego adresu (2009-02-27)].
  17. 1 2 Post Exploitation – The Penetration Testing Execution Standard. pentest-standard.org. [dostęp 2026-09-24]. (ang.).
  18. ↑ Victoria Drake: Web Security Testing Guide v4.2 Released. OWASP, 2020-12-03. [dostęp 2026-09-24]. (ang.).
  19. ↑ Web Security Testing Guide v4.2: Testing for Privilege Escalation. OWASP. [dostęp 2026-09-24]. (ang.).
  20. 1 2 Joint Task Force Interagency Working Group, NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology, wrzesień 2020, DOI: 10.6028/NIST.SP.800-53r5 [dostęp 2026-10-11] (ang.).
  21. ↑ Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego i zmieniające rozporządzenia (WE) nr 1060/2009, (UE) nr 648/2012, (UE) nr 600/2014, (UE) nr 909/2014 oraz (UE) 2016/1011, „Dziennik Urzędowy Unii Europejskiej” (L 333), 27 grudnia 2022, s. 1–79.
  22. 1 2 Dokument Rady 6867/24: Sprostowanie do rozporządzenia Parlamentu Europejskiego i Rady (UE) 2022/2554 z dnia 14 grudnia 2022 r. w sprawie operacyjnej odporności cyfrowej sektora finansowego [online], Rada Unii Europejskiej, 5 marca 2024 [dostęp 2026-09-24].
  23. 1 2 Adopting TIBER-EU will help fulfil DORA requirements [online], Europejski Bank Centralny, wrzesień 2024 [dostęp 2026-09-24] (ang.).
  24. 1 2 3 4 Wspólny Komitet Europejskich Urzędów Nadzoru, Final Report: Draft Regulatory Technical Standards specifying elements related to threat led penetration tests under Article 26(11) of Regulation (EU) 2022/2554 (JC 2024 29) [online], Europejski Urząd Nadzoru Bankowego, 17 lipca 2024 [dostęp 2026-09-24] (ang.).
  25. ↑ Penetration Testing with Kali Linux (PEN-200). OffSec. [dostęp 2026-09-25]. (ang.).
  26. ↑ PEN-210: Wireless Network Attacks. OffSec. [dostęp 2026-09-25]. (ang.).
  27. ↑ eWPT Certification. INE Security. [dostęp 2026-09-25]. (ang.).

Linki zewnętrzne