k0nsult.cloud / ai-truth / ipIII / orchestrator / dora-timeline
Oś czasu ćwiczenia DORA / TIBER — od scope do lessons learned
Wizualny przebieg testu penetracyjnego opartego na zagrożeniach (TLPT — Threat-Led Penetration Testing) w reżimie DORA / TIBER-EU, etap po etapie. Dla każdego kroku pokazujemy jeden konkret: jaki rekord, dowód lub hash powstaje w ipIII i przez jaki mechanizm. To nie deklaracja gotowości — to mapa łańcucha dowodowego. Doktryna: claim ≤ proof.
Status strony: LIVE (wizualizacja osi czasu). Status mechanizmów: mieszany — jawnie oznaczony przy każdym etapie.
Ta strona porządkuje przebieg ćwiczenia; nie wykonuje testu. Realnie działający dziś rdzeń to
engagement + report-package (status
LIVE MVP wg
status-matrix) oraz import findings → incydent → evidence i reguła close-with-evidence
(
LIVE). Pozostałe etapy noszą status
MVP lub
ROADMAP — bez ukrywania. Kanon liczby testów:
Evidence Matrix /roadmap-dev.
Kanon statusu komponentów:
status-matrix. Zegary terminów regulacyjnych:
deadline-clock.
Granica zakresu. ipIII
nie wykonuje testów TLPT samodzielnie na produkcji — nie prowadzi nieautoryzowanych skanów,
eksploatacji ani hack-backu poza pisemnym
Rules of Engagement (RoE). Etap wykonawczy
(faza red/blue/white) realizuje autoryzowany dostawca TLPT / wewnętrzny Red Team. Rola ipIII na całej osi to
orkiestracja dowodowa i workflow. Zero payloadów, zero technik ofensywnych na tej stronie.
Każdy etap zostawia dowód. Bez dowodu — etap nie jest zamknięty.
Oś czasu odwzorowuje fazy TIBER-EU: przygotowanie (scope, RoE, crown jewels), testowanie (faza red/blue/white, finding, evidence)
i zamknięcie (remediation, retest, final-report, lessons learned). W każdym punkcie powstaje weryfikowalny artefakt — rekord w bazie,
hash SHA-256 albo wpis w rejestrze — spięty w jeden łańcuch (Common Source of Truth). Bank widzi nie „że przetestowano", lecz
co, na jakich zasadach, z jakim dowodem i czy retest to potwierdził.
OŚ TLPT:
SCOPE→RoE→CROWN JEWELS→RED/BLUE/WHITE→FINDING→EVIDENCE→REMEDIATION→RETEST→FINAL REPORT→LESSONS LEARNED
Oś czasu — 10 etapów (rekord w ipIII + mechanizm)
Legenda krawędzi: LIVE zielona · MVP bursztynowa · ROADMAP fioletowa. Endpointy pokazane jako ścieżki v1 warstwy zapisu /api/ip3/v1.
01SCOPE — definicja zakresu testu (systemy, usługi krytyczne CIF, granice, wyłączenia)
LIVE MVP
Powstaje w ipIII: rekord engagement (scope + wersja) w PostgreSQL — POST /api/ip3/v1/engagements. Start łańcucha CSoT.
Mechanizm:
/engagement ·
/dora-tiber (moduł TLPT Scope). Bez zdefiniowanego scope kolejne etapy nie mają kontekstu.
02RoE — Rules of Engagement — pisemna autoryzacja, okna czasowe, cele dozwolone/zabronione, deconfliction, kill-switch
MVP · bramka
twardy podpis = ROADMAP
Powstaje w ipIII: pole RoE w rekordzie engagement (autoryzacja + zakres, wersjonowane). Reguła docelowa: bez podpisanego RoE żaden scenariusz nie przechodzi do statusu aktywnego.
Mechanizm:
/engagement (kontrakt + checklist gotowości) ·
/roe-template. Egzekwowanie podpisu jako twarda bramka DB = ROADMAP.
03CROWN JEWELS — katalog klejnotów koronnych: najkrytyczniejsze aktywa / dane / funkcje = cel scenariusza
LIVE MVP
Powstaje w ipIII: rejestr crown-jewels w engagement (mapowanie na usługi krytyczne, input od banku). Część tego samego rekordu engagement co scope i RoE.
04FAZA RED / BLUE / WHITE — wykonanie scenariusza przez autoryzowanego dostawcę; White Team koordynuje i trzyma kill-switch
white-team-log = MVP ·
wykonanie techniczne poza ipIII
Powstaje w ipIII: white-team-log (append-only, znaczniki czasu, decyzje, eskalacje) — POST /api/ip3/v1/engagements/:id/log. Wykonanie ofensywne (Red) i detekcja (Blue) dzieją się poza ipIII — w środowisku dostawcy TLPT / SOC banku.
Mechanizm:
/engagement (role cell White/Red/Blue/Purple) ·
/dora-tiber (White Team Log). ipIII rejestruje przebieg, nie wykonuje techniki.
05FINDING — ustalenie z testu (podatność / słabość kontroli) importowane z narzędzia i znormalizowane
LIVE
Powstaje w ipIII: rekord incydentu + evidence z hashem SHA-256 z importu (Burp XML · ZAP JSON/XML · Nessus/Qualys CSV · generic). Severity normalizowane do P0–P3. Import = MEDIA_SIGNAL (sygnał), nie dowód naprawy.
06EVIDENCE — rejestr dowodów: artefakt, hash, znacznik czasu, źródło, poziom pewności
LIVE ·
evidence-register w engagement = MVP
Powstaje w ipIII: evidence z sha256 + chain-of-custody w bazie; dla ćwiczenia — wpis w evidence-register engagementu. Integralność każdego artefaktu potwierdzona hashem.
07REMEDIATION — plan naprawczy: ustalenie → działanie → właściciel → termin → status (P0–P3)
częściowo v1 ·
orkiestracja SLA = ROADMAP
Powstaje w ipIII: powiązanie finding → działanie naprawcze z priorytetem. Reguła zamknięcia egzekwowana w DB: incydentu nie da się zamknąć bez dowodu (422 bez statusu CONFIRMED). Pełna orkiestracja (owner/SLA/workflow zatwierdzeń) = ROADMAP.
08RETEST — ponowna weryfikacja po naprawie; zamknięcie tylko z dowodem
LIVE
Powstaje w ipIII: przejście statusu przez CONFIRMED → close. Reguła close-with-evidence: 422 bez dowodu, PATCH-bypass zamknięty (audyt F4 + testy regresyjne). Po reteście zmienia się package_sha256 — evidence-package odzwierciedla nowy stan.
09FINAL REPORT — raport końcowy TLPT + Blue Team Report, gotowy dla zarządu / regulatora / TCT
LIVE MVP
Powstaje w ipIII: final-report + report-package (JSON / PDF) — GET /api/ip3/v1/engagements/:id/report-package?format=json|pdf: engagement + timeline zdarzeń + evidence-register + final-report + manifest + package_sha256. Reguła: raport końcowy wymaga rejestru dowodów (claim ≤ proof). Podpis PAdES/PQC + branding KNF = ROADMAP.
Mechanizm:
/dora-tiber (Final Report) · report-package to realny, pobieralny PDF (bezzależnościowy generator).
10LESSONS LEARNED — wnioski, luki telemetrii, corrective actions z domknięciem dowodowym i retestem wybranych GAP
ROADMAP
Powstaje w ipIII (docelowo): lista corrective actions (właściciel + termin + kryterium domknięcia) spięta z retestem GAP. Dziś: struktura opisana, egzekwowanie w kodzie = ROADMAP.
Ten sam łańcuch w tabeli — etap → artefakt → mechanizm → status
| # | Etap | Co powstaje w ipIII (rekord / dowód / hash) | Mechanizm | Status |
|---|
| 01 | Scope | rekord engagement (scope, wersja) | /engagement | LIVE MVP |
| 02 | RoE | pole RoE w engagement; bramka podpisu (docelowo) | /engagement | MVP · bramka ROADMAP |
| 03 | Crown jewels | rejestr crown-jewels w engagement | /dora-tiber | LIVE MVP |
| 04 | Red/Blue/White | white-team-log (append-only) · wykonanie poza ipIII | /engagement | log MVP · exec poza ipIII |
| 05 | Finding | incydent + evidence sha256 (import znormalizowany) | /connectors | LIVE |
| 06 | Evidence | evidence sha256 + chain-of-custody / evidence-register | /evidence-layer | LIVE · register MVP |
| 07 | Remediation | finding → działanie; reguła zamknięcia w DB | /response-retest | częściowo v1 |
| 08 | Retest | CONFIRMED → close; nowy package_sha256 | /response-retest | LIVE |
| 09 | Final report | report-package JSON/PDF + manifest + package_sha256 | /dora-tiber | LIVE MVP |
| 10 | Lessons learned | corrective actions + retest GAP (docelowo) | /engagement | ROADMAP |
Statusy w tej tabeli cytują status-matrix (kanon statusu). Liczby testów potwierdzających „LIVE" — Evidence Matrix /roadmap-dev. Ta strona nie wprowadza własnych liczników.
Rdzeń, który działa dziś: engagement + report-package
Wg status-matrix to jest LIVE MVP — realne rekordy w bazie, nie makieta. To on spina etapy 01–04, 06 i 09 w jeden pobieralny pakiet.
Engagement LIVE MVP
Rekord ćwiczenia: scope + crown-jewels + RoE + white-team-log + evidence-register + final-report jako rekordy DB. Reguła: raport końcowy wymaga rejestru dowodów.
→ /engagement · /api/ip3/v1/engagements
Report-package LIVE MVP
Raport TLPT: engagement + timeline zdarzeń + evidence-register + final-report + manifest + package_sha256. Format JSON lub realny PDF.
GET /api/ip3/v1/engagements/:id/report-package?format=json|pdf
Zegary incydentów osobny moduł
Terminy regulacyjne liczone od zdarzenia (DORA art.19 / NIS2 24h-72h / RODO art.33-34 / AI Act art.73) — nie na tej osi, lecz w dedykowanym module.
→ /deadline-clock · /legal-engine
Kanon liczb i statusu LIVE
Liczby testów: Evidence Matrix. Status komponentów: status-matrix. Ta strona wyłącznie cytuje — nie tworzy nowych metryk.
→ Evidence Matrix · → status-matrix
Mapowanie osi na fazy TIBER-EU i DORA
| Faza TIBER-EU | Etapy osi | Odniesienie DORA |
|---|
| Przygotowanie (Preparation) | 01 Scope · 02 RoE · 03 Crown jewels | art. 24–27 — zakres i zasady testów odporności |
| Testowanie (Testing) | 04 Red/Blue/White · 05 Finding · 06 Evidence | art. 26 — TLPT dla podmiotów istotnych (metodyka TIBER-EU) |
| Zamknięcie (Closure) | 07 Remediation · 08 Retest · 09 Final report · 10 Lessons learned | art. 26–27 — raport, plan naprawczy, ślad audytowy dla organu |
Wykonanie technik po stronie autoryzowanego dostawcy TLPT / wewnętrznego Red Team; nadzór metodyczny — TIBER Cyber Team (TCT) właściwego banku centralnego. ipIII = warstwa dowodowa i workflow. To nie certyfikacja zgodności ani gwarancja „nieprzenikalności" — to audytowalny łańcuch dowodowy ćwiczenia.
Zasada nadrzędna. Oś czasu nie jest deklaracją, że bank „przeszedł test". Jest zapisem prawdy o przebiegu: kto autoryzował,
co objęto, jakie dowody zebrano, które kontrole zadziałały i czy retest potwierdził naprawę. Etap uznajemy za zamknięty dopiero z dowodem
(rekord + hash). Bez kodu + testu + endpointu = nie LIVE (§16) — dlatego część etapów jawnie nosi MVP lub
ROADMAP.
Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue). Nie wykonuje nieautoryzowanych skanów, eksploatacji
ani hack-back. Wszelkie działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych
Rules of Engagement. „LIVE" oznacza: istnieje kod, test i endpoint — nie oznacza „systemu
produkcyjnego gotowego dla banku", „pełnej zgodności" ani „nieprzenikalności". Ta strona nie zawiera payloadów ani instrukcji ofensywnych.