Bank-ready warstwa Evidence & Resilience Orchestrator (§4.6). Wspiera testy penetracyjne oparte na zagrożeniach (TLPT — Threat-Led Penetration Testing) w reżimie DORA / TIBER-EU: scope, Crown Jewels, White Team Log, RoE, scenariusze zagrożeń, rejestr dowodów, walidację kontroli, plan naprawczy, retest i raport końcowy — spięte w jeden łańcuch dowodowy (CSoT).
/api/ip3/*, smoke test, PoC auth-skeleton). Reszta poniżej to ROADMAP.
DORA (Rozporządzenie UE 2022/2554) wymaga od podmiotów finansowych zaawansowanego testowania odporności cyfrowej, w tym TLPT dla podmiotów istotnych, w metodyce zgodnej z TIBER-EU. K0-DORA-TIBER PACK nie zastępuje dostawcy testu — daje bankowi audytowalny szkielet dowodowy: co objęto testem, na jakich zasadach, jakie dowody zebrano, które kontrole zadziałały, co naprawiono i czy retest to potwierdził.
Dziesięć modułów odwzorowuje fazy TLPT/TIBER-EU (przygotowanie, testowanie, zamknięcie). Kolumna Status jest jawna zgodnie z §16.
| Moduł | Funkcja w PACK | Rola ipIII | Status |
|---|---|---|---|
| TLPT Scope | Definicja zakresu testu: systemy, usługi krytyczne (CIF), granice, wyłączenia. Zgodność z fazą scoping TIBER-EU. | Utrzymuje rejestr scope + wersjonowanie; brak wykonania. | ROADMAP P1 |
| Crown Jewels | Katalog „klejnotów koronnych" — najbardziej krytycznych aktywów/danych/funkcji, których kompromitacja jest celem scenariusza. | Rejestr + mapowanie na usługi krytyczne; input od banku. | ROADMAP P1 |
| White Team Log | Dziennik White Team (zespół świadomy testu, koordynacja, awaryjny stop). Znaczniki czasu, decyzje, eskalacje. | Append-only log z chain-of-custody; kontrola dostępu. | ROADMAP P0 |
| RoE | Rules of Engagement: autoryzacja pisemna, okna czasowe, cele dozwolone/zabronione, procedura stop, deconfliction. | Bramka twarda — bez podpisanego RoE żaden scenariusz nie przechodzi do statusu aktywnego. | ROADMAP P0 |
| Threat Scenario | Scenariusze oparte na Threat Intelligence (TTI Report): profil aktora, TTP wg MITRE ATT&CK, cel = Crown Jewels. Opisowe, bez payloadów. | Struktura i śledzenie; treść techniczną dostarcza TI/Red Team. | ROADMAP P1 |
| Evidence Register | Rejestr dowodów z testu: artefakty, hashe SHA-256, znaczniki czasu, źródło, poziom pewności 0–100. | Warstwa dowodowa — reużywa Evidence Layer ipIII. | ROADMAP P1 |
| Control Validation | Walidacja skuteczności kontroli (detekcja/reakcja Blue Team): co wykryto, w jakim czasie, gdzie luka. | Mapuje dowód na kontrolę i status wykrycia; nie ocenia bez dowodu. | ROADMAP P2 |
| Remediation Plan | Plan naprawczy: ustalenia → działania → właściciel → termin → status. Priorytety P0–P3. | Śledzenie działań i SLA; łączy z Response & Retest. | ROADMAP P2 |
| Retest | Ponowna weryfikacja po naprawie: czy luka domknięta, z dowodem. Zakaz zamknięcia bez dowodu naprawy. | Wymusza dowód retestu przed statusem „closed". | ROADMAP P2 |
| Final Report | Raport końcowy TLPT + Blue Team Report, gotowy dla regulatora/TCT. Eksport z pełnym łańcuchem dowodowym. | Generacja z CSoT; brak twierdzeń bez pokrycia dowodowego. | ROADMAP P1 |
Zgodnie z §16 rozdzielamy plan od stanu faktycznego. Poniższe elementy mają kod + endpoint / test — są LIVE. Sam PACK DORA-TIBER pozostaje ROADMAP.
Ścieżka odczytu /api/ip3/* (read-only) obsługuje dane ipIII. Podstawa pod przyszły odczyt rejestrów PACK.
Zestaw smoke potwierdzający dostępność stron i read-path na prod. Dowód działania warstwy odczytu.
Szkielet autoryzacji (bramka RoE-adjacent) jako proof-of-concept — write-path nadal za bramką, nie produkcyjny.
Scope, Crown Jewels, White Team Log, Evidence/Control/Remediation/Retest/Final Report — projekt bez implementacji produkcyjnej.
Docelowy przepływ dowodowy — od autoryzacji po raport i retest. Każdy krok zostawia artefakt w CSoT; żadne twierdzenie nie wyprzedza dowodu.
TLPT EVIDENCE FLOW (§11.3) — status: ROADMAP
==============================================================
[ RoE signed ] (bramka: bez podpisu = STOP)
| autoryzacja pisemna, okna, deconfliction
v
[ SCOPE + CROWN JEWELS ] ---> White Team Log (append-only)
| zakres, usługi krytyczne (CIF), granice
v
[ THREAT SCENARIO ] <--- Threat Intelligence (TTI)
| profil aktora, TTP (MITRE ATT&CK), cel=Crown Jewels
| OPIS, bez payloadów (wykonanie: autoryzowany provider)
v
[ TEST EXECUTION ] .......... (poza ipIII: TLPT provider / Red Team)
| artefakty -> hash SHA-256 -> chain of custody
v
[ EVIDENCE REGISTER ] -----> confidence 0..100, source, timestamp
|
v
[ CONTROL VALIDATION ] (Blue Team detekcja/reakcja)
| wykryto? MTTD/MTTR? luka?
+--- GAP ----> [ REMEDIATION PLAN ] (owner, SLA, P0..P3)
| |
| v
| [ RETEST ] (dowód naprawy WYMAGANY)
| | zamknięcie tylko z dowodem
v v
[ FINAL REPORT + BLUE TEAM REPORT ] --> regulator / TCT
|
v
[ CSoT ] Common Source of Truth (jeden łańcuch dowodowy)
==============================================================
Zasada: claim ≤ proof. Retest bez dowodu = incydent nie zamknięty.
Wzorzec Rules of Engagement: autoryzacja, zakres, okna, procedura stop, deconfliction, dane kontaktowe White Team.
Proces zawiązania testu, role (White/Red/Blue/TCT), zgody prawne i granice odpowiedzialności.
Warstwa techniczna wykonawcza (autoryzowany dostawca / wewnętrzny Red Team). ipIII orkiestruje dowód, nie wykonuje testu.
Rozp. UE 2022/2554, art. 24–27: zaawansowane testy, w tym TLPT dla podmiotów istotnych, min. co 3 lata. PACK dostarcza ślad audytowy i raport zgodny z wymogiem.
Ramy prowadzenia TLPT (Generic Launch Document, TTI, Red/Blue/White Team, Purple Teaming). PACK odwzorowuje fazy i artefakty, nie zastępuje TCT.
Wykonanie testów: autoryzowany dostawca TLPT + wewnętrzny Red Team. Nadzór metodyczny: TIBER Cyber Team (TCT) właściwego banku centralnego. ipIII = warstwa dowodowa/workflow.