4crypto.eu
Bezpłatna konsultacja
Kompetencja · Ofensywne testy · 2026

Testy penetracyjne w 2026 r. - metodyki, zakres, TLPT i co odróżnia profesjonalistę od skaningu

Autor: dr inż. Adam CzubakCzas czytania: 13 minAktualizacja: 2026-05-13

Test penetracyjny (pentest) to udokumentowana, kontrolowana symulacja realnego ataku, prowadzona przez wykwalifikowanego testera w celu wykazania, jakie konkretne szkody może wyrządzić atakujący posiadający daną wiedzę i dane wejściowe. To technika dowodu ("udało mi się wydobyć z waszej bazy pełne PESEL-e w 2 godziny") - fundamentalnie różna od skanowania (które mówi "macie tu CVE") i audytu ("nie macie procedury patchowania").

W 2026 r. krajobraz pentestów dojrzewa pod wpływem trzech sił: dyrektywy NIS2 [1] (wymóg "oceny skuteczności środków"), rozporządzenia DORA [2] (TLPT - threat-led penetration testing dla sektora finansowego od 17.01.2025) oraz AI Act [3] (nowa potrzeba red teamingu systemów AI). Artykuł porządkuje metodyki, omawia różnice pentest/red team/TLPT i pokazuje, czego się spodziewać po profesjonalnym raporcie.

Pentest vs red team vs TLPT vs purple team

Branża używa tych pojęć zamiennie - niezawsze poprawnie. Krótkie wyjaśnienie:

  • Pentest - zaplanowany, koordynowany z klientem test technicznego ataku w określonym zakresie (np. aplikacja webowa, sieć wewnętrzna, infrastruktura Active Directory). Zespół IT klienta wie, że test trwa, i jest w gotowości. Cel: wykryć podatności w konkretnym zakresie. Czas: 5-20 osobodni.
  • Red team - szersza symulacja, w której zespół ofensywny udaje realnego przeciwnika (APT, ransomware, insider). Zwykle obejmuje też socjotechnikę (ang. phishing, vishing), próby fizycznego wejścia, atak na łańcuch dostaw. Tylko wąskie grono w organizacji wie, że trwa test (zarząd + IOD). Cel: wykryć, czy organizacja wykryłaby i powstrzymała realny atak. Czas: 4-12 tygodni.
  • TLPT (ang. Threat-Led Penetration Testing) - red team z rygorem regulacyjnym, opisany w TIBER-EU [4] (ECB, 2018) i wymagany przez DORA [2] dla sektora finansowego. Charakterystyczne: realne, zweryfikowane threat intelligence o atakujących skierowanych w klienta, formalne role play z udziałem regulatora, raport zawiera mapowanie do MITRE ATT&CK [5].
  • Purple team - współpraca zespołu ofensywnego (red) i obronnego (ang. blue) w czasie rzeczywistym. Cel: edukacyjny i ulepszający detekcję, nie gotcha. Stosowane szczególnie po pierwszym pentestcie, gdy zespół SOC chce nauczyć się wykrywać konkretne techniki.

Wybór dla typowej polskiej organizacji 2026 r.:

  • JST i małe podmioty publiczne: pentest wewnętrzny i zewnętrzny raz w roku.
  • Operatorzy usług istotnych (NIS2): pentest co najmniej raz w roku + scoped red team co 2-3 lata.
  • Banki, ubezpieczyciele, FMI (DORA): TLPT obowiązkowy co 3 lata zgodnie z RTS, dla największych podmiotów jeszcze częściej.

Metodyki - który framework wybrać

Brak jednej, uniwersalnej metodyki. W praktyce profesjonalny pentester łączy elementy:

  • PTES (ang. Penetration Testing Execution Standard) [6] - najbardziej operacyjna metodyka, 7 faz: Pre-engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post-Exploitation, Reporting. Mocna w fazach recon i post-ex. Stary dokument (2014), ale wciąż referencyjny.
  • OSSTMM 3 [7] (Open Source Security Testing Methodology Manual, ISECOM, 2010) - silne strony: metryka Attack Surface Metric (ang. RAV - Risk Assessment Value), formalna definicja zakresu testów (kontrolery, kanały, wektory). Bardziej akademicki niż PTES.
  • NIST SP 800-115 [8] (2008) - Technical Guide to Information Security Testing and Assessment. Konwencja dla amerykańskiego sektora federalnego; mniej szczegółowa od PTES, ale uznana przez NIS2 i DORA jako referencyjna.
  • OWASP WSTG v4.2 [9] - Web Security Testing Guide - najlepszy checklisting dla aplikacji webowych. ~250 testów organizowanych w 12 kategorii (Information Gathering, Configuration Management, Authentication, Authorization, Session Management, Input Validation, Error Handling, Cryptography, Business Logic, Client-Side, API, Mobile).
  • OWASP MASTG - odpowiednik WSTG dla aplikacji mobilnych (Android, iOS), wspierany przez OWASP MASVS.
  • TIBER-EU [4] - ramy procesowe dla TLPT, wspierane przez ECB. Stosowane w DORA [2] jako baza praktyk.
  • CREST Defensible Penetration Test [10] - standard akredytacji testerów, wspierany przez CREST International. Daje zarządowi gwarancję poziomu testera.

W praktyce: zewnętrzna powierzchnia (web + API + sieć z internetu) → PTES + OWASP WSTG. Sieć wewnętrzna i AD → PTES + NIST SP 800-115. AppSec mobilne → OWASP MASTG. TLPT → TIBER-EU.

Black box, gray box, white box

Trzy modele dostępu pentestera do informacji:

  • Black box - pentester nie dostaje żadnej informacji od klienta. Zaczyna jak realny atakujący z internetu. Najwierniejszy realnemu ryzyku, ale najmniej efektywny - duża część czasu uchodzi na recon. Krytykowany za niskie pokrycie (z czasu testu wynika, co znajdziesz).
  • Gray box - pentester dostaje częściową informację: konta użytkowników, schemat sieci, dostęp na poziomie domain user. Najczęściej stosowany w praktyce. Symuluje "atakujący z niskim dostępem zdobytym przez phishing" lub "złośliwy pracownik".
  • White box - pentester ma pełen dostęp: dokumentację architektury, kod źródłowy, konta admin. Najwyższe pokrycie, najwięcej znalezisk. Stosowane dla aplikacji custom (zwłaszcza SaaS). Nie symuluje realnego napastnika, ale maksymalizuje wartość edukacyjną.

Dla typowej JST (50 stanowisk, 5 serwerów, aplikacje branżowe SaaS): gray box wewnętrzny + black box zewnętrzny. White box rezerwujemy dla aplikacji custom (eUrząd, dedykowane portale).

Co powinien zawierać raport

Raport z pentestu nie jest listą krytycznych CVE. To dokument z trzema warstwami odbiorców:

  1. Executive summary (1-2 strony) - dla zarządu, bez żargonu, z metryką: liczba krytycznych wektorów, najgorszy scenariusz biznesowy, ocena ogólnej odporności w skali (np. 1-5 lub HML).
  2. Wnioski techniczne - dla CISO/IT - uporządkowane wg łańcuchów ataku (ang. kill chains), nie wg pojedynczych podatności. Łańcuch = sekwencja kroków od początku do crown jewels.
  3. Lista znalezisk - dla zespołu remediacji - każde znalezisko: opis, klasyfikacja, dowód (screenshot, dump), kroki reprodukcji, zalecenie naprawcze, mapowanie do MITRE ATT&CK [5] i CWE.

Mark of professional report: każde znalezisko ma dowód odtwarzalności. Nie "udało mi się eskalować" - "command line z timestamp pokazuje, jak osiągnąłem SYSTEM".

Mark of red team report: dodatkowo zawiera timeline wykrywalności - minuta po minucie, co zespół SOC wykrył / nie wykrył. To esencjalne dla purple teamingu po teście.

Mark of TLPT report: zgodnie z TIBER-EU [4] - Threat Intelligence Report + Red Team Test Report + Test Summary Report dla regulatora + Closure Report z planem remediacji.

Najczęstsze błędy

Z naszej praktyki audytowej i pentestowej:

  1. Pentest = skanowanie z manuałem. Junior tester uruchamia Nessus, kopiuje wyniki do raportu - klient płaci 5x cenę skanowania za to samo. Profesjonalny pentest zaczyna od własnej fazy Threat Modeling i kończy Post-Exploitation z dowodem realnej szkody.
  2. Zakres zbyt wąski. "Przetestujcie naszą aplikację webową" - bez DNS, OSINT, sieci wewnętrznej, wektora pracownika. Wektor #1 w DBIR 2024 [11]: phishing → credentials → VPN. Aplikacja webowa jest często ostatnim, najmniej istotnym krokiem.
  3. Brak walidacji testera. Każdy może powiesić wywieszkę "pentester". Sprawdzaj: CREST [10], OSCP, CRTP, GPEN, OSEP, doświadczenie z konkretnym typem testu, referencje.
  4. Pentest w produkcji bez koordynacji. Test może wywrócić usługi (DoS pingowaniem starego switch'a). Pre-engagement musi zawierać plan awaryjny (telefon do dyżurnego SOC, plan rollback).
  5. Raport bez re-testu. Po remediacji znalezisk niezbędny re-test wybranych krytycznych - inaczej nie wiadomo, czy poprawki działają.
  6. Brak następczego threat huntingu. Pentest zostawia ślady (logi). Po teście SOC powinien sprawdzić, czy zauważył - i jakie alerty zignorował. To bezpłatna lekcja detekcji.

Regulacje wymagające pentestu

Wprost lub pośrednio wymagane:

  • NIS2 art. 21 (1) lit. e/g [1] - "procedury oceny skuteczności środków" - pentest jako jeden z dowodów.
  • DORA art. 24-26 [2] - TLPT obowiązkowy dla podmiotów wskazanych przez właściwy organ nadzoru (KNF w Polsce). Cykl: minimum co 3 lata.
  • RODO art. 32 (1) lit. d [12] - "regularne testowanie skuteczności środków" - pentest dla aplikacji przetwarzających dane osobowe.
  • PCI DSS v4.0 wymóg 11.4 - operatorzy kart płatniczych - pentest minimum raz w roku i po istotnych zmianach.
  • ISO/IEC 27001:2022 A.5.7 [13] - Threat intelligence + A.8.29 Security testing podczas rozwoju i akceptacji.
  • AI Act art. 15 [3] - systemy AI wysokiego ryzyka - wymóg "robustness" dowodzony m.in. adversarial testingiem (red team systemów AI).

Trendy 2025-2027

Trzy najważniejsze:

  1. AI red teaming. Wraz z AI Act [3] i powszechnym wdrożeniem LLM-ów do operacji (Microsoft Copilot, ChatGPT Enterprise) rośnie zapotrzebowanie na red teaming modeli: prompt injection, jailbreaking, data exfiltration via output, model integrity. OWASP Top 10 for LLM Applications (od 2023) stało się referencyjną listą.
  2. Pentest jako serwis (PTaaS). Modele subskrypcyjne (HackerOne Pentest as a Service, Bugcrowd Pentest as a Service) - ciągłe testowanie, raport w pulpicie, integracja z Jirą. Konkurencja dla tradycyjnych engagement-ów.
  3. Threat-Informed Testing. Testy nie generyczne, lecz mapowane do realnych przeciwników organizacji. Sektor finansowy: TIBER-EU [4]. Sektor publiczny: mapowanie do APT-ów atakujących polskie cele (ENISA Threat Landscape 2024 [14], CERT.PL [15]).

Checklist: 10 pytań przed zleceniem pentestu

Pentest może być bezsensowną inwestycją lub realnym wkładem w bezpieczeństwo. Decydują pytania zadane przed podpisaniem umowy.

  1. Zakres. Co dokładnie jest w zakresie (IP, domeny, aplikacje, segmenty sieci, użytkownicy do socjotechniki)? Co jest out of scope (np. produkcja, ciężkie ataki DoS)?
  2. Cel. Czy celem jest compliance (sprawdzenie checkboxa), assurance (ocena ogólna), czy deep dive (znaleźć wszystko w konkretnej aplikacji)? Różne cele wymagają różnych podejść.
  3. Model (black/gray/white box). Dlaczego wybieramy ten? Najczęściej gray box dla wewnętrznych, black box dla zewnętrznych.
  4. Metodyka. Czy tester zadeklaruje PTES / OWASP WSTG / NIST SP 800-115 / TIBER-EU? Sama deklaracja nie wystarczy - pytaj o ślad w raporcie.
  5. Kwalifikacje. Certyfikaty (OSCP, OSEP, CRTP, GPEN, GXPN, CRTO), CREST, doświadczenie z podobnym środowiskiem (JST, OT, finans). Sprawdź LinkedIn i CV testera.
  6. Reguły zaangażowania (RoE). Kiedy test? (godziny biznesowe vs nocne) Kto jest punktem kontaktowym 24/7 w razie problemu? Plan eskalacji.
  7. Akcje na produkcji. Czy zezwalamy na eksploit? Czy na lateral movement? Czy na post-exploitation z prawdziwymi danymi? Czy na red team-style działania (socjotechnika, fizyka)?
  8. Format raportu. Executive summary + wnioski techniczne + lista znalezisk z mapowaniem do MITRE ATT&CK i CWE. Tabela CSV/XLSX znalezisk do importu w Jirę.
  9. Re-test. Czy jeden lub dwa re-testy znalezisk krytycznych są w cenie? (Zazwyczaj 30-60 dni po raporcie końcowym.)
  10. Klauzule poufności i odpowiedzialność. NDA, wskazanie odpowiedzialnego po stronie testera, ubezpieczenie OC, formalna procedura zniszczenia danych po teście.

Najczęściej zadawane pytania

Pentest vs red team - co wybrać?

Jeśli to pierwszy test ofensywny - pentest. Cel: wykryć i naprawić techniczne luki. Red team ma sens dopiero po pierwszych 2-3 pentestach, gdy organizacja ma już dojrzałe SOC i procedury, i chce wiedzieć, jak by zachowała się w realnym kryzysie.

Ile trwa pentest aplikacji webowej?

Średnia aplikacja CMS-owa: 5-7 osobodni. Średnia aplikacja custom (np. e-Urząd, portal pacjenta): 8-15 osobodni. Duża aplikacja branżowa: 15-30 osobodni. Test jako produkt - od 10 tys. zł netto, custom - wycena indywidualna.

Czy pentest może uszkodzić produkcję?

Przy profesjonalnym wykonaniu - bardzo rzadko, i tylko po wcześniejszym uzgodnieniu (eksploit, DoS). Standardowy pentest jest non-disruptive. Ryzyko: < 1% w naszej historii projektów (typowe zdarzenie: stary switch L2 nie wytrzymał intensywnego ARP scanningu).

Czy mogę zlecić pentest mojemu dostawcy IT?

Nie - to konflikt interesów. Pentest musi prowadzić niezależny podmiot, który nie wdrażał testowanych systemów. Twój dostawca IT jest najlepszym partnerem do remediation, nie do testu.

Jakie wyniki uznaje się za sukces pentestu?

Brak krytycznych znalezisk nie zawsze oznacza sukces - może oznaczać, że tester nie był wystarczająco dobry. Realny pentest dojrzałej organizacji zwykle wykrywa 2-5 wektorów wysokich/krytycznych. Sukces to świadomość: wiemy, co naprawić, i mamy plan w 90 dni.

Co to dokładnie jest TLPT w DORA?

Threat-Led Penetration Testing zgodny z TIBER-EU [4] - symulacja realnego przeciwnika oparta na CTI (threat intelligence) konkretnego klienta. Wymagana dla podmiotów finansowych wskazanych przez właściwy organ (KNF). Cykl: minimum co 3 lata. Czas trwania: 12-30 tygodni. Koszt: 200-800 tys. zł, z udziałem regulatora.

Czy red team obejmuje socjotechnikę i wejście fizyczne?

Tak - wszystko, co realny przeciwnik mógłby zrobić, jeśli klient wyraźnie nie wyłączył tego zakresu. Wymaga to formalnej autoryzacji get out of jail free letter od zarządu - dokumentu na piśmie zapewniającego, że tester nie zostanie aresztowany za włamanie do biura.

Co zrobić, gdy pentest wykazał 0 znalezisk krytycznych?

Najczęstsze pytanie na forach branżowych - to alarm, nie sukces. Realistyczna interpretacja:

  1. Niewystarczające kompetencje testera - junior z Nessusem zamiast doświadczonego pentestera. Sprawdź metodologię i ślady w raporcie.
  2. Zbyt wąski zakres - pentest tylko aplikacji webowej pomija wektor sieciowy, AD, łańcuch dostaw.
  3. Środowisko nie odzwierciedla produkcji - testowano na sterylnym dev/staging, gdzie nie ma realnych danych ani konfiguracji.
  4. Zbyt krótki czas - 2-3 osobodni dla enterprise web app to za mało.

PTES [6] sekcja Pre-engagement i NIST SP 800-115 [8] sekcja 4 wymagają udokumentowania zakresu i czasu pracy. Realny pentest dojrzałej organizacji typowo wykrywa 2-5 wektorów wysokich/krytycznych - zero to sygnał, że coś jest nie tak.

Czy pentest aplikacji webowej w trybie black box wystarczy?

Dla klasycznej aplikacji CMS (WordPress, Drupal): tak, black box jest zwykle wystarczający. Dla aplikacji custom (eUrząd, portal pacjenta, dedykowany system): nie - zalecane gray box lub white box, ponieważ:

  • OWASP WSTG v4.2 [9] szacuje, że black box pokrywa ~40-60% rzeczywistych podatności w business logic i authorization.
  • PTES [6] sekcja Threat Modeling zaleca dostęp do dokumentacji architektury dla custom apps.
  • Czas pracy wzrasta o 30-50% w black box (recon, mapowanie funkcjonalności) - mniej wartości na osobodzień.

Najlepsza praktyka: gray box z 2-3 kontami różnych ról + black box jako oddzielna część dla walidacji external attacker perspective.

Pentest urządzeń OT/SCADA - czy to bezpieczne?

Tylko z dedykowanym zespołem OT-aware i metodyką IEC 62443 [16]. Aktywne pentestowanie urządzeń sterujących (PLC, RTU) może je uszkodzić fizycznie - przepełnienie buforów na starych firmware, denial-of-service na watchdogu, race conditions. Wytyczne ICS-CERT i NIST SP 800-82 Rev. 3 (cytowane też w naszym artykule SOC):

  • Tryb pasywny (sniffing ruchu, analiza statyczna konfiguracji) dla produkcji.
  • Aktywny pentest wyłącznie na środowisku identycznym z produkcją (testbed) lub podczas planowanego shutdown.
  • Współpraca z operatorem - testerzy nie znający procesu technologicznego mogą uruchomić zatrzymanie awaryjne.
Pentester chce zainstalować implant w sieci - czy to legalne i bezpieczne?

Tak - w obu wymiarach, ale z trzema warunkami:

  1. Pisemna autoryzacja w Rules of Engagement (RoE), z określeniem typu implantu (C2 beacon, persistence agent), lokalizacją w sieci, okresem działania, mechanizmem usunięcia. Bez tego - potencjalne naruszenie art. 267a-269b kodeksu karnego PL.
  2. Izolowane środowisko C2 - komunikacja implantu nie może wycieknąć do publicznego internetu niezabezpieczona.
  3. Procedura cleanup - po teście tester demontuje implant i dostarcza dowód usunięcia (logi z C2, weryfikacja na endpoincie). PTES [6] sekcja Post-Exploitation cleanup wprost to wymaga.

Implant jest standardową techniką red team i TLPT [4]. Bez niego nie sposób zweryfikować detekcji persistence (MITRE ATT&CK TA0003 [5]).

Pentest aplikacji mobilnej - czym się różni od webowej?

Główne różnice metodologiczne (zgodnie z OWASP MASTG - Mobile Application Security Testing Guide):

  • Static analysis kodu (APK/IPA) jako pierwszy krok - analiza obfuskacji, hardcoded secrets, słabe szyfrowanie.
  • Dynamic analysis - runtime hooking (Frida), bypass anti-debug, certificate pinning bypass.
  • Backend API - często reprezentuje większość attack surface, testowany według OWASP WSTG [9].
  • Storage - analiza danych w SharedPreferences/UserDefaults, plików tymczasowych, keychain.

Czas: typowo 1.5-2× pentestu webowego o porównywalnej złożoności.

Potrzebujesz konsultacji w tym obszarze?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Omawiamy potrzeby, skalę i ramowy harmonogram.

Zadzwoń: +48 691 122 312office@4crypto.eu

Powiązane treści

Pozostałe obszary kompetencyjne

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. Standardy ISO/IEC, RFC IETF, dyrektywy UE i akty krajowe odsyłają do oryginalnych dokumentów.

  1. [1]regulationParlament Europejski, Rada UE (2022). Dyrektywa (UE) 2022/2555 (NIS2) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
  2. [2]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554
  3. [3]regulationParlament Europejski, Rada UE (2024). Rozporządzenie (UE) 2024/1689 (AI Act) ustanawiające zharmonizowane przepisy dotyczące sztucznej inteligencji. Dziennik Urzędowy UE, L seria, 12.7.2024 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689
  4. [4]guidelineEuropean Central Bank (2018). TIBER-EU Framework: Threat Intelligence-Based Ethical Red Teaming. ECB · https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
  5. [5]standardMITRE Corporation (2024). MITRE ATT&CK Framework v15 (Enterprise, Mobile, ICS). MITRE · https://attack.mitre.org/
  6. [6]guidelinePTES Team (2014). Penetration Testing Execution Standard (PTES). pentest-standard.org · http://www.pentest-standard.org/
  7. [7]guidelineHerzog, P. (ISECOM) (2010). Open Source Security Testing Methodology Manual (OSSTMM) 3. Institute for Security and Open Methodologies · https://www.isecom.org/OSSTMM.3.pdf
  8. [8]standardScarfone, K., Souppaya, M., Cody, A., Orebaugh, A. (2008). NIST SP 800-115: Technical Guide to Information Security Testing and Assessment. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-115
  9. [9]guidelineOWASP Foundation (2024). OWASP Web Security Testing Guide (WSTG) v4.2. OWASP · https://owasp.org/www-project-web-security-testing-guide/
  10. [10]guidelineCREST (2023). CREST Defensible Penetration Test Standard. CREST International · https://www.crest-approved.org/
  11. [11]reportVerizon Business (2024). 2024 Data Breach Investigations Report (DBIR). Verizon, 17th edition · https://www.verizon.com/business/resources/reports/dbir/
  12. [12]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO) w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych. Dziennik Urzędowy UE, L 119, 4.5.2016 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
  13. [13]standardInternational Organization for Standardization (2022). ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements. ISO/IEC · https://www.iso.org/standard/27001
  14. [14]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). ENISA Threat Landscape 2024. ENISA, Heraklion · DOI: 10.2824/0710888
  15. [15]reportCERT Polska / NASK (2024). Raport roczny CERT Polska 2023. NASK PIB, Warszawa · https://www.cert.pl/publikacje/raport-roczny-cert-polska/
  16. [16]standardInternational Electrotechnical Commission (2018). IEC 62443 - Industrial communication networks - Network and system security. IEC · https://www.iec.ch/cyber-security