4crypto.eu
Bezpłatna konsultacja
Compliance · Standard NIST · 2026

NIST SP 800-115 w 2026 r. - Technical Guide to Information Security Testing and Assessment

Autor: dr inż. Adam Czubak Czas czytania: 14 min Aktualizacja: 2026-05-15

Ratio essendi

NIST SP 800-115 powstała z obserwacji, że testowanie bezpieczeństwa jest dyscypliną wymagającą profesjonalnej metodologii, a nie improwizacji opartej na intuicji testera. Sens przewodnika to przeniesienie tej dyscypliny do formy ramowej - cztery fazy (Planning, Discovery, Attack, Reporting), katalog technik i wymagania Rules of Engagement - tak, by zarówno tester, jak i klient mieli wspólne oczekiwania co do procesu, dokumentacji i jakości pracy. Mimo wieku publikacji (2008) metodologia pozostaje aktualna, ponieważ opisuje sposób myślenia, a nie konkretne narzędzia - te ewoluują, ale fazy i kategorie technik pozostają trwałe.

NIST Special Publication 800-115 [1] (Technical Guide to Information Security Testing and Assessment, 2008) to podstawowy przewodnik metodologiczny dla osób przeprowadzających techniczne testy bezpieczeństwa - audytorów, penetration testerów, zespołów red team. Mimo opublikowania w 2008 r., pozostaje aktualnym standardem branżowym ze względu na uniwersalność czterofazowej metodologii (Planning, Discovery, Attack, Reporting) i klasyfikację technik (Review, Target Identification, Target Vulnerability Validation).

NIST SP 800-115 jest publicznie dostępny i darmowy na stronie csrc.nist.gov. Cytowany w wielu regulacjach i normach: DORA TLPT [8], ISO 27001:2022 A.8.29 (Security testing) [7], PCI DSS Requirement 11. W praktyce stosowany razem z OWASP WSTG [2] (web applications), OSSTMM [4], PTES [5] i MITRE[14] ATT&CK. Artykuł porządkuje strukturę dokumentu, omawia 4 fazy, kategorie technik, wymagania Rules of Engagement (ROE), proces raportowania oraz mapping do innych standardów.

Czym jest NIST SP 800-115

Pełna nazwa: NIST Special Publication 800-115 Technical Guide to Information Security Testing and Assessment. Wydawca: National Institute of Standards and Technology (NIST), Computer Security Resource Center (CSRC).

Status dokumentu

  • Publikacja: wrzesień 2008.
  • Autorzy: Karen Scarfone, Murugiah Souppaya, Amanda Cody, Angela Orebaugh.
  • Status: Final, aktualnie obowiązujące wydanie (nie zaktualizowane od 2008 r., ale powołane w innych publikacjach NIST).
  • Liczba stron: ~80.
  • Dostępność: darmowa, publiczna, PDF na csrc.nist.gov.

Adresaci dokumentu

NIST SP 800-115 jest skierowane do:

  • Audytorów bezpieczeństwa - jako baza metodyczna.
  • Pentestów (penetration testerów) - jako podstawowy framework[15].
  • Zespołów red team - jako referencja procesowa.
  • Klientów testów - by rozumieć, czego oczekiwać od testera i jak ocenić jakość pracy.
  • Audytorów wewnętrznych - dla testów wewnętrznych zgodności.
  • Specjalistów IT - by rozumieć metodologię, gdy ich systemy są testowane.

Cele dokumentu

NIST SP 800-115 ma cztery cele:

  1. Strukturyzacja procesu - czterofazowa metodologia testów.
  2. Katalogowanie technik - klasyfikacja dostępnych narzędzi i metod.
  3. Najlepsze praktyki - jak prowadzić testy profesjonalnie.
  4. Wskazanie pułapek - najczęstsze błędy i jak ich unikać.

Struktura dokumentu

NIST SP 800-115 składa się z 8 rozdziałów:

  • 1. Wprowadzenie - cele, adresaci, struktura.
  • 2. Podejście do testowania - filozofia, role, planowanie.
  • 3. Klasyfikacja technik - 3 kategorie (Review, Target Identification, Target Vulnerability Validation).
  • 4. Review techniques - dokumentacja, logi, system, ruleset.
  • 5. Target identification and analysis - discovery, port scanning, wireless, soc[19]ial engineering.
  • 6. Target vulnerability validation - vulnerability scanning, pentest.
  • 7. Security assessment planning - cele, scope, ROE, harmonogram.
  • 8. Security assessment execution - praktyczne wskazówki, raportowanie.

Aktualność w 2026 r.

Mimo wieku publikacji (17 lat), NIST SP 800-115 pozostaje aktualnym przewodnikiem z dwóch powodów:

1. Uniwersalność metodologii

Cztery fazy (Planning, Discovery, Attack, Reporting) są uniwersalne i nie zmieniają się z technologią. To proces myślowy, nie konkretne narzędzia. Każdy strukturyzowany pentest w 2026 r. nadal przechodzi przez te same fazy.

2. Klasyfikacja technik niezależna od narzędzi

NIST SP 800-115 opisuje kategorie technik, a nie konkretne narzędzia. Port scanning jest kategorią - czy używamy nmap 7, masscan, czy unicornscan, kategoria pozostaje taka sama.

Co się zmieniło od 2008

Krajobraz[20] IT i bezpieczeństwa znacząco ewoluował:

  • Cloud security - w 2008 r. AWS było młodą usługą. Dzisiaj - dominant model. Testowanie chmury wymaga specjalistycznych technik (np. cloud config audit, IAM enumeration).
  • Container security - Docker pojawił się w 2013 r., Kubernetes w 2014 r. Container security to dedykowana subkategoria.
  • API testing - REST, GraphQL, gRPC. OWASP API Security Top 10.
  • Mobile security - iOS, Android. OWASP MSTG.
  • IoT security - urządzenia IoT, OT/SCADA.
  • AI/ML security - adversarial ML, prompt injection, model poisoning. OWASP Top 10 for LLMs.

Komplementarne publikacje NIST

NIST opublikował komplementarne dokumenty:

  • NIST SP 800-53 - katalog kontroli bezpieczeństwa (controls).
  • NIST SP 800-53A - ocena kontroli (assessment procedures).
  • NIST SP 800-181 - NICE Framework (Workforce Framework for Cybersecurity).
  • NIST SP 800-218 - Secure Software Development Framework (SSDF).
  • NIST Cybersecurity Framework 2.0 - wysokopoziomowy framework.

Oczekiwana rewizja

NIST nie ogłosił oficjalnego harmonogramu rewizji SP 800-115. Społeczność branżowa oczekuje aktualizacji uwzględniającej cloud, containers, AI/ML, ale jak dotąd brak konkretnych terminów.

4 fazy metodologii

NIST SP 800-115 wprowadza czterofazową metodologię testów bezpieczeństwa. Każdy pentest powinien przechodzić przez te fazy w określonej kolejności (z opcjonalnymi iteracjami).

Faza 1: Planning (Planowanie)

20-30% czasu projektu. Kluczowa faza określająca powodzenie testu.

Aktywności:

  • Identyfikacja celów testu - co chcemy odkryć? Compliance, gap analysis, security assessment, threat simulation?
  • Określenie zakresu - co jest w scope, co wyłączone. Adresy IP, aplikacje, sieci.
  • Wybór metodologii - NIST, OWASP, PTES.
  • Definiowanie ROE (Rules of Engagement) - szczegóły poniżej.
  • Uzyskanie pisemnej autoryzacji - Get-Out-of-Jail-Free Letter.
  • Planowanie zasobów - team, narzędzia, infrastruktura.
  • Harmonogram - okno czasowe, milestones.
  • Komunikacja - kanały, eskalacja, kontakty.

Faza 2: Discovery (Odkrywanie)

30-40% czasu projektu. Najobszerniejsza faza techniczna.

Aktywności:

  • Reconnaissance - passive (OSINT, Google dorks, WHOIS) i active (port scanning).
  • Network discovery - identyfikacja zasięgu IP, sieci, urządzeń.
  • Port scanning - identyfikacja otwartych portów (nmap, masscan).
  • Service identification - banner grabbing, version detection.
  • OS fingerprinting - identyfikacja systemów operacyjnych.
  • Vulnerability analysis - mapowanie wykrytych usług do znanych podatności (CVE database, exploit-db).
  • Aplikacje web - mapowanie endpoints, parametry, technologie (Wappalyzer, WhatWeb).
  • Authentication mechanisms - jakie systemy uwierzytelniania, MFA.

Faza 3: Attack (Atak)

10-20% czasu projektu. Najbardziej widoczna, ale często najkrótsza.

Aktywności:

  • Gaining access - wykorzystanie znalezionych podatności (exploit).
  • Escalating privileges - eskalacja uprawnień (lokalna, do administratora/root).
  • System browsing - eksploracja systemu, identyfikacja danych.
  • Installing additional tools - persistence (backdoor, scheduled tasks).
  • Lateral movement - ruch boczny do innych systemów.
  • Privilege escalation w domenie (np. Active Directory) - od user do Domain Admin.
  • Data exfiltration (symulowana) - dowód, że można wyciągnąć dane.
  • Cleanup - usunięcie wszystkich wprowadzonych zmian (backdoorów, użytkowników).

Faza 4: Reporting (Raportowanie)

20-30% czasu projektu. Często niedoceniana, a krytyczna dla wartości biznesowej.

Aktywności:

  • Dokumentacja findings - dla każdej znalezionej podatności.
  • Klasyfikacja ryzyka - CVSS 4.0 lub 3.1.
  • Executive summary - 1-2 strony dla zarządu, bez technicznego żargonu.
  • Detailed findings - szczegóły techniczne z dowodami.
  • Rekomendacje - jak naprawić każdą podatność.
  • Remediation roadmap - harmonogram naprawy z priorytetami.
  • Lessons learned - co poszło dobrze, co źle.
  • Debrief - spotkanie z klientem, prezentacja wyników.

Iteracje

Fazy mogą iterować - znalezienie nowego wektora w fazie Attack może wymagać powrotu do Discovery (np. lateral movement otwiera dostęp do nowych systemów, które trzeba zmapować).

Klasyfikacja technik testowania

NIST SP 800-115 dzieli techniki na 3 główne kategorie:

1. Review Techniques (Techniki przeglądu)

Pasywne techniki - bez aktywnego skanowania systemów. Bazują na przeglądzie dokumentacji, logów, konfiguracji.

  • Documentation Review - polityki, procedury, architektura, raporty.
  • Log Review - logi systemowe, aplikacyjne, bezpieczeństwa.
  • Ruleset Review - reguły firewall, IDS, WAF.
  • System Configuration Review - konfiguracje serwerów, urządzeń.
  • Network Sniffing - pasywne nasłuchiwanie ruchu (Wireshark, tcpdump).
  • File Integrity Checking - sprawdzanie integralności plików.

2. Target Identification and Analysis Techniques

Aktywne techniki identyfikacji systemów i ich charakterystyk.

  • Network Discovery - identyfikacja systemów w sieci.
  • Network Port and Service Identification - port scanning, service detection.
  • Vulnerability Scanning - automatyczne wykrywanie znanych podatności (Nessus, Qualys, OpenVAS).
  • Wireless Scanning - identyfikacja sieci Wi-Fi, ich konfiguracji, słabości.

3. Target Vulnerability Validation Techniques

Aktywne testy wykorzystania podatności - od symulowanego ataku do faktycznego exploit.

  • Password Cracking - łamanie haseł (offline / online).
  • Penetration Testing - próby eksploatacji znalezionych podatności.
  • Social Engineering - phishing, vishing, pretexting.
  • Application Security Testing - testy aplikacji web, mobile, API.

Wybór technik

Wybór technik zależy od celów testu:

  • Compliance audit (np. ISO 27001) - głównie Review techniques + Vulnerability scanning.
  • Risk assessment[10] - Review + Target Identification + ograniczone Vulnerability Validation.
  • Penetration test - wszystkie techniki, z nacis[18]kiem na Vulnerability Validation.
  • Red team engagement - jak pentest, plus social engineering, physical access, MITRE ATT&CK TTPs.

Rules of Engagement (ROE)

Rules of Engagement (ROE) to krytyczny dokument przed rozpoczęciem testów. NIST SP 800-115 sekcja 7 omawia ROE jako warunek konieczny.

Zawartość ROE

  1. Zakres (Scope) - jakie systemy, sieci, aplikacje są w scope. Co jest WYŁĄCZONE.
  2. Adresy IP - target IPs i source IPs (skąd test jest prowadzony).
  3. Okno czasowe - dokładne daty i godziny testów. Czy 24/7 czy tylko w godzinach pracy?
  4. Eskalacja - kto kontaktuje się w razie krytycznego znaleziska. Telefony alarmowe.
  5. Notification - kogo informować i kiedy. Czy zespół SOC wie o testu (silent vs notified)?
  6. Methods of communication - email, telefon, encrypted channel, ticketing.
  7. Wyłączenia technik - co jest zabronione:
    • Zakaz DoS / DDoS.
    • Zakaz testowania na produkcji w pewnych okresach.
    • Zakaz social engineering personelu zarządu lub VIP.
    • Zakaz testów destrukcyjnych.
  8. Handling sensitive data - co robić w razie znalezienia danych osobowych, finansowych, intellectual property. Czy można je zapisać jako dowód?
  9. Stop conditions - kiedy testy są wstrzymane (np. incydent produkcji, przekroczenie planowanego zakresu).
  10. Legal authorization - Written Authorization od osoby uprawnionej do podpisania (zarząd / właściciel / kierownik bezpieczeństwa).

Written Authorization (Get-Out-of-Jail-Free Letter)

Pisemna autoryzacja to fundamentalny dokument. Bez niej test może być nielegalny w świetle:

  • Art. 267 KK - nieuprawniony dostęp do informacji.
  • Art. 268 KK - niszczenie / zniekształcanie informacji.
  • Art. 269 KK - zakłócenie sieci publicznej.
  • Art. 269a KK - sabotaż komputerowy.
  • Art. 269b KK - wytwarzanie / posiadanie narzędzi służących do popełniania przestępstw komputerowych.

Autoryzacja powinna zawierać:

  • Kto autoryzuje (osoba z uprawnieniami do reprezentowania organizacji).
  • Kogo autoryzuje (konkretny tester lub firma, z numerem dowodu / NIP).
  • Zakres (jakie systemy, dla jakich celów).
  • Okres (od-do).
  • Ograniczenia.
  • Podpis, data, miejsce.

ROE template

Typowy ROE to 5-15 stron dokument. Standardowy template:

  1. Project Information.
  2. Authorization.
  3. Scope (in/out).
  4. Methodology.
  5. Schedule.
  6. Tools and techniques.
  7. Communication.
  8. Reporting.
  9. Confidentiality.
  10. Sign-off.

Typy pentestów - black/white/gray box

Black Box (External / Closed-box)

Pentester ma minimalne informacje, jak prawdziwy attacker. Symuluje atak z internetu.

  • Cel: realizm, symulacja zewnętrznego ataku.
  • Czas: najdłuższy (mocno czasochłonna faza Discovery).
  • Typowe użycie: external network pentest, web application black-box.
  • Wada: brak czasu na głębokie testy aplikacyjne, mniej znalezisk.

White Box (Internal / Crystal-box)

Pentester ma pełne informacje: dokumentację, kod źródłowy, dane uwierzytelniające, schematy sieci.

  • Cel: efektywność, wgłębne testy.
  • Czas: najmniej tracony na Discovery, więcej na testy.
  • Typowe użycie: code review, security review nowych systemów, certyfikacja produktu.
  • Wada: mniej realistyczny w symulacji zewnętrznego ataku.

Gray Box (Hybrid)

Pentester ma częściowe informacje - np. ograniczone dane uwierzytelniające, ogólny opis architektury, ale bez dostępu do kodu źródłowego.

  • Cel: symulacja insider threat lub zaawansowanego attackera z wstępnym dostępem.
  • Czas: balans między Black i White Box.
  • Typowe użycie: najczęściej używany w praktyce - typowy authenticated web app pentest.

Wybór typu

Wybór zależy od celów:

  • Compliance - zwykle gray-box (efektywny, realistyczny).
  • Pre-launch security review - white-box (wgłębny).
  • Threat simulation / TLPT - black-box (realistyczny).
  • Insider threat assessment - gray-box z perspektywą pracownika.

Vulnerability scanning vs pentest

Dwa różne, ale komplementarne podejścia.

Vulnerability Scanning

  • Automatyczne wykrywanie znanych podatności przez skanery (Nessus, Qualys, OpenVAS, Tenable).
  • Cykliczne - typowo kwartalnie.
  • Szybkie - godziny dla dużej infrastruktury.
  • Output: lista CVE z dopasowaniem do wykrytych wersji oprogramowania.
  • Nie weryfikuje exploitability ani business impact.
  • NIST SP 800-115 sekcja 4.2 opisuje tę technikę.

Szczegóły - artykuł o skanowaniu podatności.

Penetration Testing

  • Manualna / półautomatyczna próba eksploatacji podatności.
  • Cykliczne - typowo rocznie (dla regulacji - co 12-24 miesiące).
  • Wolne - dni-tygodnie.
  • Weryfikuje rzeczywiste ryzyko - czy można wykorzystać podatność.
  • Output: raport ze scenariuszami ataku, dowodami, rekomendacjami.
  • NIST SP 800-115 sekcja 4.4 opisuje tę technikę.

Szczegóły - artykuł o testach penetracyjnych.

Różnice w praktyce

  • Vulnerability scanning: "Jest podatność CVE-2024-XXXX z CVSS 9.8".
  • Pentest: "Wykorzystałem CVE-2024-XXXX i uzyskałem root na serwerze produkcyjnym. Wyciągnąłem 50 tys. rekordów klientów. Czas - 4 godziny."

Komplementarność

Najlepsza praktyka:

  • Vulnerability scanning regularnie (kwartalnie lub po istotnych zmianach).
  • Pentest okresowo (rocznie) dla weryfikacji rzeczywistego ryzyka.
  • Pentest po istotnych zmianach (nowa aplikacja, migracja chmurowa).

Raportowanie - struktura raportu

NIST SP 800-115 sekcja 8 omawia strukturę raportu z testów bezpieczeństwa. Dobry raport jest krytyczny dla wartości biznesowej testu.

Standardowa struktura raportu

1. Executive Summary (1-2 strony)

Dla zarządu, bez technicznego żargonu:

  • Krótki opis zakresu i celu.
  • Kluczowe znaleziska (3-5 top findings).
  • Ogólna ocena bezpieczeństwa.
  • Top rekomendacje.

2. Methodology

  • Zastosowana metodologia (NIST SP 800-115, OWASP, PTES).
  • Zakres testów.
  • Ramy czasowe.
  • Zespół testowy.
  • Narzędzia.

3. Findings Details

Dla każdej znalezionej podatności:

  • ID - unikalny identyfikator (np. F-001, F-002).
  • Tytuł - krótki opis.
  • Severity - Critical / High / Medium / Low / Informational z CVSS score.
  • Affected systems - listy zasobów.
  • Description - szczegółowy opis podatności.
  • Evidence - dowody: screenshots, logs, request/response, video proofs.
  • Business impact - co to znaczy dla biznesu.
  • Remediation - rekomendacje naprawy.
  • References - CVE, OWASP, CWE, knowledge base.

4. Risk Assessment

Tabela podsumowująca wszystkie findings z priorytetami:

  • Critical (CVSS 9.0-10.0).
  • High (CVSS 7.0-8.9).
  • Medium (CVSS 4.0-6.9).
  • Low (CVSS 0.1-3.9).
  • Informational.

5. Remediation Roadmap

Sugerowany harmonogram naprawy z priorytetami:

  • Critical: 7 dni.
  • High: 30 dni.
  • Medium: 90 dni.
  • Low: 180 dni.

6. Appendices

  • Lista narzędzi.
  • Surowe outputy skanów.
  • Dodatkowe dowody.
  • Glossary.

Długość raportu

  • Mały pentest (single web app): 50-80 stron.
  • Średni pentest (network + apps): 100-200 stron.
  • Duży pentest (enterprise): 200-500 stron.
  • Red team report: 100-300 stron + appendices.

Format dystrybucji

  • PDF z hash dla integralności.
  • Szyfrowanie (PGP / password-protected) dla bezpiecznej dystrybucji.
  • Executive briefing - prezentacja 30 min dla zarządu.
  • Technical debrief - 2-3 godziny dla zespołów technicznych.

Mapping do OWASP, OSSTMM, PTES, MITRE

NIST SP 800-115 vs OWASP WSTG

OWASP Web Security Testing Guide [2] (v4.2, 2024) - specjalizacja na aplikacjach web. Bardziej szczegółowa - ponad 100 technik testów dla web applications.

  • NIST SP 800-115 - ogólna metodologia.
  • OWASP WSTG - szczegółowa metodologia dla web apps.

Praktyka: NIST jako framework + OWASP WSTG jako szczegółowy how-to.

NIST SP 800-115 vs OSSTMM

OSSTMM (Open Source Security Testing Methodology Manual) [4] v3, 2010 - alternatywna metodologia z metrykami (RAV - Risk Assessment Value).

  • NIST: pragmatyczny, popularny.
  • OSSTMM: scientific approach, mniej popularny, akademicki.

NIST SP 800-115 vs PTES

PTES (Penetration Testing Execution Standard) [5] 2014 - kompletna metodologia z 7 sekcjami:

  1. Pre-engagement.
  2. Intelligence Gathering.
  3. Threat Modeling.
  4. Vulnerability Analysis.
  5. Exploitation.
  6. Post Exploitation.
  7. Reporting.

PTES Technical Guidelines - przewodnik praktyczny z konkretnymi narzędziami i komendami. Bardziej szczegółowa niż NIST.

NIST SP 800-115 vs MITRE ATT&CK

MITRE ATT&CK - matryca taktyk, technik i procedur (TTPs) stosowanych przez prawdziwych adwersarzy. Idealny do red team operations - symulacja konkretnych grup APT.

Praktyka: red team używa MITRE ATT&CK do mapowania symulowanych zachowań.

NIST SP 800-115 vs TIBER-EU

TIBER-EU [6] - framework EBC dla TLPT (Threat-Led Penetration Testing) sektora finansowego. Po DORA - obowiązkowy dla największych banków. Buduje na NIST SP 800-115 i innych standardach.

Stos frameworków - praktyka

Profesjonalny pentester używa kombinacji:

  • NIST SP 800-115 - bazowy framework procesowy.
  • OWASP WSTG / MSTG - dla web/mobile.
  • PTES - dla głębokich pentestów.
  • MITRE ATT&CK - dla red team.
  • CIS Benchmarks - dla audytu konfiguracji.

Każdy framework uzupełnia inne, żaden nie jest kompletny sam.

Aspekty prawne - autoryzacja

Polskie prawo karne

Pentest bez autoryzacji może być przestępstwem:

  • Art. 267 KK - nieuprawniony dostęp do informacji (do 2 lat).
  • Art. 268 KK - niszczenie informacji (do 2 lat).
  • Art. 269 KK - zakłócenie sieci (do 8 lat).
  • Art. 269a KK - sabotaż komputerowy (do 8 lat).
  • Art. 269b KK - wytwarzanie narzędzi (do 3 lat).

Pisemna autoryzacja

Niezbędna dla każdego testu. Zawiera:

  • Identyfikacja stron (testera i autoryzującego).
  • Zakres (jakie systemy).
  • Okres ważności.
  • Ograniczenia (co jest zabronione).
  • Cel testu.
  • Podpis osoby uprawnionej do reprezentowania organizacji.

Ubezpieczenie OC dla pentestera

Profesjonalny pentester ma polisę OC zawodową (Professional Liability Insurance, E&O). Pokrywa:

  • Szkody w razie awarii systemów podczas testu.
  • Wycieki danych spowodowane testem.
  • Konsekwencje błędów w raporcie.

Typowa kwota ubezpieczenia: 1-5 mln EUR.

NDA i klauzule

Umowa pentestu obejmuje:

  • NDA - poufność wykrytych informacji.
  • Klauzule cybersec - jak chronić dane podczas testu.
  • Ograniczenie odpowiedzialności - do określonej kwoty.
  • Klauzula data destruction - po teście wszystkie dane klienta są usuwane.

RODO w pentestach

Jeśli pentest dotyka danych osobowych:

  • Pentester jest procesorem w rozumieniu RODO art. 28.
  • Wymagana umowa procesorska (DPA).
  • Klient pozostaje administratorem.
  • Pentester nie może dystrybuować danych osobowych, nawet jako dowodów.

Typowe błędy w testach

NIST SP 800-115 i praktyka identyfikują typowe pułapki:

Po stronie klienta

  1. Zbyt wąski scope. Klient wyłącza krytyczne systemy "bo są niestabilne" - co paradoksalnie zwiększa ryzyko, bo nieprzetestowane.
  2. Niewystarczająca komunikacja. Zespół IT nie wie o teście, dochodzi do nieporozumień, faktycznych incydentów.
  3. Brak planu reakcji. Co zrobić jak pentester znajdzie krytyczną podatność w produkcji?
  4. Brak budżetu na remediation. Raport leży na półce, nic się nie zmienia.
  5. Test "compliance pretendingly". Cel - dostać raport na potrzeby audytu, bez prawdziwej intencji znalezienia podatności.
  6. Test na środowisku test/staging. Nie odzwierciedla rzeczywistych ryzyk produkcji.

Po stronie pentestera

  1. Nie ma pisemnej autoryzacji. Test bez ROE i Written Authorization to ryzyko prawne.
  2. Brak struktury. Pentester rzuca się od razu na Attack bez Discovery.
  3. Niedostateczne dokumentowanie. Findings bez dowodów - klient kwestionuje.
  4. Wycieki danych klienta. Niezabezpieczone laptopy, raporty w mailu, brak data destruction.
  5. Tunnel vision. Skupienie na ulubionych technikach, pomijanie innych obszarów.
  6. Generic recommendations. "Stosuj patch management" - bez konkretnych wskazówek dla klienta.
  7. Brak retest. Po remediation - czy podatność jest naprawdę naprawiona? Wymaga retest.

Po stronie procesu

  1. Pentest raz na 5 lat. Niewystarczająca częstotliwość dla compliance i bezpieczeństwa.
  2. Brak follow-up. Findings nie są tracked, status nie monitored.
  3. Brak vulnerability management programu. Pentest = jednorazowy snapshot, vulnerability management = ciągły proces.
  4. Pentest tego samego dostawcy rok w rok. Dostawca poznaje organizację za dobrze, mniej rzetelny test. Rekomendacja: rotacja co 2-3 lata.

Checklist: 10 punktów przygotowania do pentestu

Lista must-have przed rozpoczęciem testów bezpieczeństwa.

  1. Cele testu zdefiniowane. Compliance / risk assessment / threat simulation?
  2. Zakres precyzyjnie określony. Co w scope, co wyłączone. Lista IP, aplikacji.
  3. Pisemna autoryzacja od osoby uprawnionej. Get-Out-of-Jail-Free Letter.
  4. ROE (Rules of Engagement) podpisane przez obie strony.
  5. NDA i DPA (jeśli dotyka danych osobowych) zawarte.
  6. Plan komunikacji - kanały, eskalacja, kontakty alarmowe.
  7. Stop conditions - kiedy testy są wstrzymane.
  8. Plan reakcji w razie krytycznej podatności znalezionej na produkcji.
  9. Budżet na remediation wstępnie alokowany.
  10. Plan follow-up - retest po remediation, vulnerability management program.

Najczęściej zadawane pytania

Co to NIST SP 800-115?

NIST Special Publication 800-115 to dokument NIST z 2008 r. zatytułowany Technical Guide to Information Security Testing and Assessment. Stanowi metodologiczny przewodnik dla osób przeprowadzających techniczne testy bezpieczeństwa.

Mimo wieku publikacji (2008), pozostaje aktualnym standardem branżowym ze względu na uniwersalność metodologii (4 fazy, kategorie technik).

Dokument liczy 80 stron i obejmuje: planowanie testów, fazy, techniki, ROE, reporting, pułapki. Jest darmowy i publicznie dostępny.

Czy NIST SP 800-115 jest aktualne (2008)?

Mimo opublikowania w 2008 r., NIST SP 800-115 pozostaje aktualnym przewodnikiem z dwóch powodów:

  1. Metodologia oparta na 4 fazach jest UNIVERSALNA i nie zmienia się z technologią.
  2. Klasyfikacja technik opisuje TYPY testów, nie konkretne narzędzia.

Co się zmieniło od 2008: konkretne narzędzia, nowe obszary (cloud, container, API, mobile, IoT, AI/ML).

Praktyka: NIST SP 800-115 jako bazowy framework + uzupełnienie specjalistycznymi przewodnikami (OWASP WSTG, MITRE ATT&CK).

Jakie są 4 fazy metodologii NIST SP 800-115?

Cztery fazy:

  1. PLANNING (20-30%) - cele, zakres, ROE, autoryzacja.
  2. DISCOVERY (30-40%) - reconnaissance, port scanning, vulnerability analysis.
  3. ATTACK (10-20%) - exploit, escalation, lateral movement.
  4. REPORTING (20-30%) - dokumentacja, klasyfikacja CVSS, rekomendacje.

Fazy mogą iterować - nowy wektor w Attack może wrócić do Discovery.

Co to ROE (Rules of Engagement)?

Rules of Engagement to krytyczny dokument przed rozpoczęciem testów. Definiuje wszystkie zasady i ograniczenia projektu. Zawiera: zakres, adresy IP, okno czasowe, eskalację, notification, methods of communication, wyłączenia technik, handling sensitive data, stop conditions, Written Authorization.

Bez ROE i pisemnej autoryzacji test jest nielegalny (art. 267-269b Kodeksu karnego).

Różnica vs OWASP / OSSTMM / PTES?

NIST SP 800-115 - ogólny przewodnik (4 fazy + kategorie technik). Universal.

OWASP WSTG - specjalizacja na aplikacjach web. Ponad 100 technik dla web apps. Aktualnie v4.2 (2024).

OSSTMM - alternatywna metodologia z 2010, naukowe podejście z metrykami RAV. Mniej popularna.

PTES - kompletna metodologia z 7 sekcjami. Bardziej szczegółowa niż NIST.

Praktyka: pentester używa NIST + OWASP WSTG + PTES + MITRE ATT&CK. Każdy dokument uzupełnia inne.

Black box vs white box vs gray box?

Trzy poziomy znajomości systemu:

  1. Black box - minimalne info, jak prawdziwy attacker. Najdłuższy, realistyczny.
  2. White box - pełne info: dokumentacja, kod, kredensjale. Efektywny, wgłębny.
  3. Gray box - częściowe info. Najczęściej w praktyce - balans realizmu i efektywności.

Wybór: compliance = gray-box; pre-launch = white-box; threat simulation = black-box.

Czy NIST SP 800-115 jest obowiązkowy?

Nie jest obowiązkowy prawnie - to publikacja dobrowolna. Jednak w praktyce:

  1. DORA TLPT cytuje NIST SP 800-115 jako dopuszczalny standard.
  2. Klienci sektorów regulowanych często wymagają "industry-recognized methodology".
  3. Audyty ISO 27001 akceptują NIST SP 800-115 jako dowód metodologii.
  4. PCI DSS Requirement 11 akceptuje NIST, OSSTMM, OWASP.
  5. SIWZ w zamówieniach publicznych często wymaga "zgodność z NIST SP 800-115 lub równoważnym".
Ile trwa pentest?

Zależy od skali i typu:

  • Web app pentest: 2-3 tygodnie, 30-80 tys. zł.
  • External network: 2 tygodnie, 25-60 tys. zł.
  • Internal network (100-500 endpoints): 3-4 tygodnie, 60-150 tys. zł.
  • Wireless: 3-5 dni, 15-40 tys. zł.
  • Mobile app (iOS+Android): 10-15 dni, 50-120 tys. zł.
  • Red team (TLPT): 8-12 tygodni, 200-500 tys. EUR.
  • Full enterprise: 4-8 tygodni, 200 tys. - 1 mln zł.
Co zawiera raport z pentestu?

Standardowa struktura (NIST SP 800-115 sekcja 8):

  1. Executive Summary - 1-2 strony dla zarządu.
  2. Methodology - metodologia, zakres, ramy, zespół.
  3. Findings Details - dla każdej podatności: ID, severity, evidence, remediation.
  4. Risk Assessment - tabela z priorytetami.
  5. Appendices - narzędzia, raw outputs.
  6. Remediation Roadmap - harmonogram naprawy.

Dobry raport to 50-200 stron.

Co to vulnerability scanning vs pentest?

Vulnerability scanning: automatyczne wykrywanie znanych podatności (Nessus, Qualys, OpenVAS). Cykliczne (kwartalnie), szybkie (godziny). Nie weryfikuje exploitability.

Penetration testing: manualna próba eksploatacji. Cykliczne (rocznie), wolne (tygodnie). Weryfikuje rzeczywiste ryzyko.

Komplementarne: scan regularnie, pentest okresowo.

Zob. Skanowanie podatności i Testy penetracyjne.

Social engineering w NIST SP 800-115?

NIST SP 800-115 sekcja 5.3 omawia social engineering. Trzy kategorie:

  1. Phishing - email z linkiem/załącznikiem.
  2. Pretexting / vishing - telefon podszywający się.
  3. Physical access - tailgating, USB drops.

Wymagania: pisemna autoryzacja, ROE, ochrona personelu, RODO compliance (brak publikacji nazwisk).

Zob. Security Awareness.

Czy potrzebuję autoryzacji do pentestu własnej firmy?

Tak, zawsze. Powody:

  1. Prawo (art. 267-269b KK) wymaga autoryzacji.
  2. Ochrona testera w razie incydentu podczas testu.
  3. Wymogi ubezpieczenia cyber.
  4. Compliance ISO 27001/KSC/NIS2.

Autoryzacja zawiera: kto autoryzuje, kogo, zakres, okres, ograniczenia, podpis, datę.

NIST SP 800-115 nazywa to "Get-Out-of-Jail-Free Letter".

Potrzebujesz konsultacji w zakresie pentestów?

Bezpłatna 30-60 minutowa konsultacja. Bez zobowiązań. Omawiamy zakres, metodologię (NIST SP 800-115, OWASP, PTES), harmonogram.

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

Powiązane treści

Normy i regulacje

Usługi związane

Bibliografia i źródła

Wszystkie cytowane źródła są publicznie dostępne. NIST publikacje są darmowe na csrc.nist.gov.

  1. [1]standardNational Institute of Standards and Technology (NIST) (2008). NIST Special Publication 800-115 - Technical Guide to Information Security Testing and Assessment. NIST Computer Security Resource Center · https://csrc.nist.gov/publications/detail/sp/800-115/final
  2. [2]standardOWASP Foundation (2024). OWASP Web Security Testing Guide (WSTG) v4.2 · https://owasp.org/www-project-web-security-testing-guide/
  3. [3]standardOWASP Foundation (2021). OWASP Top 10:2021 · https://owasp.org/Top10/
  4. [4]standardInstitute for Security and Open Methodologies (ISECOM) (2010). OSSTMM v3 - Open Source Security Testing Methodology Manual · https://www.isecom.org/OSSTMM.3.pdf
  5. [5]standardPTES Team (2014). PTES - Penetration Testing Execution Standard · http://www.pentest-standard.org/
  6. [6]guidelineEuropean Central Bank (ECB) (2018). TIBER-EU - Threat Intelligence-based Ethical Red Teaming framework · https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
  7. [7]standardISO/IEC (2022). ISO/IEC 27001:2022 - Information security management systems · https://www.iso.org/standard/27001
  8. [8]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) - sekcja TLPT (art. 26-27). Dz.U. UE L 333, 27.12.2022 · https://eur-lex.europa.eu/eli/reg/2022/2554/oj
  9. [9]standardJoint Task Force (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. NIST. DOI: 10.6028/NIST.SP.800-53r5 · https://doi.org/10.6028/NIST.SP.800-53r5
  10. [10]standardJoint Task Force Transformation Initiative (2012). NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments. NIST. DOI: 10.6028/NIST.SP.800-30r1 · https://doi.org/10.6028/NIST.SP.800-30r1
  11. [11]standardJoint Task Force Transformation Initiative (2018). NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations. NIST. DOI: 10.6028/NIST.SP.800-37r2 · https://doi.org/10.6028/NIST.SP.800-37r2
  12. [12]standardOpen Web Application Security Project (OWASP) (2021). OWASP Application Security Verification Standard (ASVS) v4.0.3. OWASP · https://owasp.org/www-project-application-security-verification-standard/
  13. [13]standardRoss, R., et al. (2024). NIST SP 800-171 Rev. 3: Protecting Controlled Unclassified Information in Nonfederal Systems. NIST. DOI: 10.6028/NIST.SP.800-171r3 · https://doi.org/10.6028/NIST.SP.800-171r3
  14. [14]standardMITRE Corporation (2024). MITRE ATT&CK Framework v15 (Enterprise, Mobile, ICS). MITRE · https://attack.mitre.org/
  15. [15]standardNational Institute of Standards and Technology (NIST) (2024). NIST Cybersecurity Framework (CSF) 2.0. NIST CSWP 29, February 2024. DOI: 10.6028/NIST.CSWP.29 · https://doi.org/10.6028/NIST.CSWP.29
  16. [16]peer-reviewedAlahmadi, B. A., Axon, L., Martinovic, I. (2022). 99% False Positives: A Qualitative Study of SOC Analysts' Perspectives on Security Alarms. USENIX Security 2022, pp. 2783-2800 · https://www.usenix.org/conference/usenixsecurity22/presentation/alahmadi
  17. [17]peer-reviewedKokulu, F. B., et al. (2019). Matched and Mismatched SOCs: A Qualitative Study on Security Operations Center Issues. ACM CCS 2019, pp. 1955-1970. DOI: 10.1145/3319535.3354239 · https://doi.org/10.1145/3319535.3354239
  18. [18]standardCenter for Internet Security (2024). CIS Critical Security Controls Version 8.1. CIS · https://www.cisecurity.org/controls
  19. [19]peer-reviewedVielberth, M., B�hm, F., Fichtinger, I., Pernul, G. (2020). Security Operations Center: A Systematic Study and Open Challenges. IEEE Access, vol. 8, pp. 227756-227779. DOI: 10.1109/ACCESS.2020.3045514 · https://doi.org/10.1109/ACCESS.2020.3045514
  20. [20]reportEuropean Union Agency for Cybersecurity (ENISA) (2024). ENISA Threat Landscape 2024. ENISA, Heraklion. DOI: 10.2824/0710888 · https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024