k0nsult.cloud / ai-truth / ipIII / civilization / pentest

Pentest — metodyka testów penetracyjnych dla banku

Ustrukturyzowany, powtarzalny i audytowalny proces testu penetracyjnego dla instytucji finansowej. Oparty na uznanych standardach (PTES, OWASP, OSSTMM) i ramach regulacyjnych sektora (DORA TLPT, TIBER-EU). Każde ustalenie ma severity, dowód i ścieżkę remediacji — pentest wpina się w łańcuch evidence-first ipIII.

Civilization Specjaliści Roje i cykle Red Team Pentest Attack-sim Engagement ← ipIII hub

exercise-log · staging · NOINDEX. Ta strona opisuje metodykę pentestu jako dziennik ćwiczenia — nie jest raportem z testu realnej infrastruktury. Cała treść operacyjna: SYMULACJA. Bez podpisanego Rules of Engagement (RoE) i pisemnej autoryzacji zakresu nie prowadzimy żadnych działań na żywym celu. Nie publikujemy payloadów, exploitów ani narzędzi — wyłącznie proces, standardy i format raportu dla obrońców. Strona: robots: noindex,nofollow.

Pentest bez RoE to nie test — to incydent. Zakres, zgoda i dowód poprzedzają każdą akcję.

Wartość pentestu dla banku nie leży w „włamaniu", lecz w weryfikowalnej liście ustaleń z dowodem i naprawą. Nasza metodyka produkuje ślad audytowy zgodny z oczekiwaniami nadzoru (KNF, CSIRT) i spina się z panelami Evidence Board oraz Compliance.

CYKL: RoE / ZAKRES→ROZPOZNANIE→TEST→DOWÓD→SEVERITY→REMEDIACJA→RETEST→RAPORT

PTES — 7 faz standardu SYMULACJA

Penetration Testing Execution Standard porządkuje test w siedem faz. Governance i bramka zgody (RoE) są warunkiem wejścia — nie formalnością.

Pre-engagement Interactions — zakres, cele, RoE, okna testowe, kontakty eskalacyjne, klauzule „stop". Bez tego nie ma dalszych faz.
Intelligence Gathering — rozpoznanie pasywne/aktywne w granicach zakresu (odpowiednik ATT&CK TA0043).
Threat Modeling — modelowanie przeciwnika i ścieżek ataku dla aktywów krytycznych banku.
Vulnerability Analysis — identyfikacja i walidacja podatności (bez masowej eksploatacji produkcji).
Exploitation — kontrolowana weryfikacja podatności w zakresie RoE, z logiem i klauzulą „minimum impact".
Post-Exploitation — ocena realnego wpływu (dostęp do danych, ruch boczny) — na potrzeby dowodu ryzyka, nie eskalacji.
Reporting — ustalenia, severity (CVSS), dowody, rekomendacje, plan remediacji i retest.

Standardy referencyjne

OWASP WSTG

Web Security Testing Guide — systematyczny katalog testów aplikacji web/API. Baza checklisty dla warstwy aplikacyjnej.

OWASP Top 10

Najczęstsze klasy podatności (m.in. Broken Access Control, Injection, SSRF). Priorytetyzacja ryzyka aplikacyjnego.

OWASP API Security Top 10

Ryzyka specyficzne dla API (BOLA/BFLA, nadmierne dane, brak limitów). Kluczowe dla bankowości otwartej / PSD2.

OSSTMM

Open Source Security Testing Methodology Manual — pomiar bezpieczeństwa operacyjnego (rav), metryki powtarzalne.

NIST SP 800-115

Techniczny przewodnik oceny bezpieczeństwa — ramy planowania i wykonania testów.

OWASP LLM Top 10

Ryzyka aplikacji LLM/agentowych (prompt injection, nadmierna sprawczość) — warstwa AI portalu.

Ramy regulacyjne sektora finansowego RAMKA

Dla banku pentest nie jest dowolny — jest osadzony w wymaganiach nadzorczych. Poniższe ramy opierają się na publicznie znanej treści regulacji (status: norma/ramka).

DORA TLPT UE

Threat-Led Penetration Testing wg rozporządzenia DORA — obowiązkowe testy oparte na wywiadzie o zagrożeniach dla podmiotów krytycznych rynku finansowego, na żywych systemach produkcyjnych, w reżimie kontrolowanym.

TIBER-EU EBC

Threat Intelligence-based Ethical Red Teaming — ramowy framework EBC do testów opartych na realistycznym wywiadzie o zagrożeniach. Baza metodyczna dla TLPT w DORA.

Wytyczne nadzorcze KNF/NIS2

Oczekiwania nadzoru krajowego, NIS2/KSC dla podmiotów kluczowych: regularne testy, ślad audytowy, raportowanie ustaleń krytycznych.

Zakres testów — 6 obszarów SYMULACJA

Obszar	Co testujemy	Standard	Grupa A–L	Priorytet
Web / API	Kontrola dostępu, injection, SSRF, BOLA/BFLA, sesje, logika biznesowa	OWASP WSTG / API Top 10	A, D	P0
Infrastruktura	Segmentacja, hardening, ekspozycja usług, patch management	NIST 800-115 / OSSTMM	E, J	P1
Cloud	IAM, konfiguracja, sekrety, storage, izolacja tenantów	OWASP / CIS Benchmarks	E	P1
Tożsamość	MFA, zarządzanie kontami, federacja, PAM, sesje uprzywilejowane	PTES / NIST	C	P0
Socjotechnika (awareness)	Phishing symulowany, podniesienie świadomości — nie pułapka na ludzi	PTES / OSSTMM	K	P2
AI / agenci	Prompt injection, agent hijack, nadmierna sprawczość, wyciek kontekstu	OWASP LLM Top 10 / ATLAS	G, H, I	P0

Warstwa AI/agenci prowadzi bezpośrednio do playbooków: Prompt injection · Agent hijack · Agent Security. Symulowany phishing służy awareness, nie ocenie indywidualnej pracowników.

Raportowanie — severity, dowód, remediacja, retest SYMULACJA

Raport to produkt pentestu. Format spójny z evidence-first: każde ustalenie ma pełny łańcuch od dowodu do naprawy.

1 · Severity (CVSS). Ocena wg CVSS v3.1/v4.0: wektor, wynik bazowy, kontekst środowiskowy. Mapowanie na priorytety P0–P3 ipIII.

2 · Dowód. Reprodukowalny opis, request/response zredagowany, screenshot, hash SHA-256, chain of custody. Poziom pewności 0–100. Bez sensacji, bez ujawniania działającego exploita w treści raportu.

3 · Remediacja. Konkretna rekomendacja naprawy, właściciel, termin, klasyfikacja ryzyka rezydualnego.

4 · Retest. Ponowna weryfikacja po naprawie. Zamknięcie ustalenia wymaga dowodu naprawy — claim ≤ proof. Bez retestu ustalenie pozostaje otwarte.

Skala severity → priorytet

CVSS	Severity	Priorytet ipIII	SLA remediacji (demo)	Eskalacja
9.0–10.0	Critical	P0	natychmiast / 24h	CISO + human-in-the-loop
7.0–8.9	High	P1	72h	Kierownik SOC
4.0–6.9	Medium	P2	plan sprintu	Właściciel systemu
0.1–3.9	Low	P3	backlog	Rejestr ryzyka

SLA to wartości demonstracyjne (format panelu), nie zobowiązanie umowne. Ustalane per RoE.

Roster pentesterów DANE

Modelowany rejestr kompetencji, z którego dobierany jest zespół pod zakres. To struktura danych (ledger), nie stan żywych agentów.

50 000

Roster specjalistów

DANE · rejestr, nie żywe agenty

~50

Zaproszona kohorta

PUBLIC_CLAIM · instytucji finansowej, anonimowo

~16

Rój równolegle

LIVE · realna infra

1000

Max na workflow

LIVE · limit wykonawczy

ROJ ≠ REJESTR. Liczba 50 000 to DANE (modelowany roster). Realnie wykonawczy rój jest ograniczony infrastrukturą do ok. 16 równolegle / do 1000 na workflow (LIVE). Doktryna 5k–10k/cykl i 15× metaGO to ROADMAP. Kohorta ~50 pentesterów partnera to PUBLIC_CLAIM / PLANNED, anonimowo — bez podpisanego RoE nie nazywamy podmiotu.

Evidence chain: z testu do incydentu ipIII SYMULACJA

Ustalenie z pentestu nie kończy życia w PDF. Wpina się w ten sam łańcuch dowodowy co incydenty operacyjne — dzięki temu naprawa jest mierzalna i audytowalna.

USTALENIE (pentest)→DOWÓD + hash→Evidence Board→SEVERITY / P0–P3→PLAYBOOK→REMEDIACJA→RETEST→ZAMKNIĘCIE z dowodem

Powiązane panele: Dashboard · Evidence Board · Compliance · Demo dla bezpieczeństwa bankowego.

Uczciwość zakresu. Wszystko powyżej to metodyka i symulacja. K0NSULT nie prowadzi działań na realnym celu bez podpisanego RoE i pisemnej autoryzacji. Nie dostarczamy exploitów, payloadów ani narzędzi ofensywnych. Wartością jest weryfikowalny proces: zakres → dowód → severity → naprawa → retest, z pełnym śladem audytowym dla nadzoru.

Przypomnienie statusów. Roster 50 000 = DANE. Rój wykonawczy ~16 / 1000 = LIVE. Doktryna 5k–10k/cykl, 15× metaGO = ROADMAP. Kohorta ~50 pentesterów instytucji finansowej = PUBLIC_CLAIM / PLANNED, anonimowo. Ramy regulacyjne (DORA, TIBER-EU) = RAMKA (publiczna treść norm). Scenariusze operacyjne = SYMULACJA. Strona noindex,nofollow.