k0nsult.cloud / ai-truth / ipIII / banking-demo

Demo dla bezpieczeństwa bankowego

Strona-scenariusz dla CISO, SOC, compliance i audytu banku. Pokazuje, jak system K0NSULT przekłada pojedyncze zgłoszenie w audytowalny łańcuch dowodowy i gotowe raporty do organów — bez „wiary na słowo". Cały scenariusz poniżej jest oznaczony SYMULACJA: to demonstracja przepływu, nie rzeczywiste naruszenie.

Zastrzeżenie regulacyjne. Mapowania na DORA / Rekomendację D KNF / PSD2 / NIS2 / RODO / AI Act są ramowe i edukacyjne — nie stanowią certyfikacji, audytu, opinii prawnej ani rekomendacji nadzorczej. Szablony wspierają przygotowanie zgłoszenia, ale nie zastępują decyzji DPO/prawnika/organu ani oficjalnych kanałów notyfikacji. Ślad dowodowy jest audytowalny i weryfikowalny (źródło, hash, timestamp, łańcuch nadzoru); formalna ocena należy do właściwego audytu/regulatora.

Compliance Agent Security Demo bankowe Executive Overview Playbook phishing

Co bank dostaje: dowód, nie deklarację.

Każdy incydent ma łańcuch: zgłoszenie → dowód (hash+timestamp) → status → klasyfikacja → ryzyko → playbook → działanie → walidacja → raport. Audytor KNF widzi kompletny, weryfikowalny ślad. SOC dostaje gotowy playbook. DPO — gotowy szablon zgłoszenia. To skraca czas reakcji i zamyka lukę audytową.

1. Executive summary — co system daje bankowi

Mapowanie incydentów

Jedna spójna taksonomia dla cyber klasycznego, incydentów AI/agentowych, naruszeń prawnych i ciągłości. Threat Map + tabela dla zarządu.

Evidence chain audytowalny

Każde twierdzenie ma status dowodowy i hash łańcuchowy. Materiał gotowy dla audytu wewnętrznego, KNF i sądu.

Gotowe raporty do organów

Szablony NIS2 (24h/72h/final), RODO art. 33/34 (PUODO), AI Act art. 73 — wypełniane danymi z warstwy dowodowej.

Playbooki reagowania

Zdefiniowane kroki dla phishingu, ransomware, DDoS, wycieku, supply chain oraz zagrożeń AI. Skrócenie MTTR.

Tool firewall dla AI

Agenci AI w banku pod kontrolą: DID, scoring, allowlista narzędzi, human approval dla akcji na płatnościach, kill switch.

Rejestr human-in-the-loop

Weryfikowalny log decyzji — kto, kiedy, na jakiej podstawie. Fundament rozliczalności wobec regulatora.

2. Mapowanie na wymogi sektora bankowego

Reżim	Wymóg	Odpowiedź systemu
DORA (Rozp. 2022/2554)	Zarządzanie ryzykiem ICT, klasyfikacja i raportowanie poważnych incydentów ICT, testy odporności.	Classification Engine + progi P0–P3, evidence chain, szablony raportu incydentu, moduł ciągłości/DR.
Rekomendacja D KNF	Zarządzanie obszarem IT i bezpieczeństwem środowiska teleinformatycznego, ślad audytowy.	Rejestr incydentów, trace działań, rejestr decyzji, eksport dowodowy dla audytu.
PSD2 — SCA	Silne uwierzytelnianie klienta, wykrywanie i obsługa oszustw (fraud).	Playbook phishing/PhaaS, flaga `LAW_ENFORCEMENT`, powiązanie zdarzeń fraud z dowodem.
NIS2 / ustawa o KSC	Zgłoszenia 24h/72h/raport końcowy do CSIRT, środki zarządzania ryzykiem.	Ścieżka NIS2 z zegarami terminów, flagi `NIS2_RELEVANT`/`KSC_RELEVANT`/`CRITICAL_INFRA`.
RODO	Zgłoszenie naruszenia do PUODO ≤72h (art. 33), zawiadomienie osób (art. 34).	Workflow DPO z zegarem 72h, szablony art. 33/34, flaga `GDPR_BREACH`.
AI Act	Transparentność (art. 50 od 2.08.2026), poważne incydenty AI (art. 73), high-risk scoring (Aneks III).	Legal/Compliance Engine, flagi `AI_*`, tool firewall dla agentów, raport art. 73.

RAMKA/NORMA Kolumna „wymóg" opisuje publicznie znaną treść regulacji sektorowych; nie stanowi porady zgodności dla konkretnego banku. Aneks III AI Act (scoring kredytowy) — obowiązek odroczony do 2.12.2027 (Digital Omnibus).

3. Scenariusz demo end-to-end: phishing pod bank

SYMULACJA: poniższy incydent INC-DEMO-7742, adresy, dane i znaczniki czasu są przykładowe (dane demonstracyjne). Scenariusz ilustruje przepływ systemu, nie odnosi się do rzeczywistego zdarzenia.

Łańcuch: 1 ZGŁOSZENIE2 DOWÓD3 STATUS4 KLASYFIKACJA5 FLAGI6 PLAYBOOK7 DZIAŁANIE8 WALIDACJA9 RAPORT

Krok 1 — Zgłoszenie. Pracownik oddziału zgłasza mail podszywający się pod „Bezpieczeństwo Banku" z linkiem do fałszywej bramki logowania. Kanał: Incident Intake. Utworzono rekord INC-DEMO-7742. SYMULACJA

Krok 2 — Dowód. Do rekordu dołączono: kopię maila (nagłówki), URL fałszywej domeny bank-secure-login[.]xyz, zrzut ekranu strony. Każdy artefakt zahashowany (SHA-256) + timestamp → status dowodowy CONFIRMED. Chain-of-custody rozpoczęty.

Krok 3 — Status. Zdarzenie potwierdzone materialnie (istnieje mail + żywa domena). Rekord przechodzi ze PUBLIC CLAIM do CONFIRMED.

Krok 4 — Klasyfikacja. Classification Engine: kategoria = phishing / PhaaS (Phishing-as-a-Service), wektor = email, priorytet = P1 (aktywna kampania, cel = dane uwierzytelniające klientów, SLA 24h).

Krok 5 — Flagi prawne. Ustawione: GDPR_PERSONAL_DATA (celem są dane klientów), CRITICAL_INFRA (bank), NIS2_RELEVANT, LAW_ENFORCEMENT (podejrzenie przestępstwa). GDPR_BREACH = do oceny DPO (czy doszło do faktycznego przejęcia danych).

Krok 6 — Playbook. Uruchomiono playbook phishing: identyfikacja odbiorców, takedown domeny, blokada URL na bramkach, komunikat ostrzegawczy, reset dla narażonych kont.

Krok 7 — Działanie. Zgłoszenie do rejestratora/hostingu (takedown), wpis URL na blocklistę proxy/poczty, wymuszony reset haseł i re-SCA dla kont, które kliknęły link. Każde działanie logowane w trace.

Krok 8 — Walidacja. Potwierdzenie: domena niedostępna (takedown OK), brak dalszych kliknięć, brak śladu udanego przejęcia sesji. DPO ocenia: brak dowodu wycieku danych → GDPR_BREACH = false (decyzja w rejestrze HITL).

Krok 9 — Raport. Wygenerowano: wpis NIS2 (jeśli próg istotności przekroczony), notatkę do rejestru incydentów DORA, paczkę dowodową (14 artefaktów, sealed hash) dla audytu. RODO art. 33 nie uruchomione (brak naruszenia) — decyzja udokumentowana.

4. Co widzi audytor po zamknięciu

Artefaktów dowodowych

zapieczętowanych hashem SYM.

Priorytet / SLA 24h

udokumentowany

Flagi prawne

z uzasadnieniem

Decyzja HITL

GDPR_BREACH=false, uzasadniona

Wartości powyżej to SYMULACJA — dane demonstracyjne z opisanego scenariusza.

5. Dlaczego evidence-first minimalizuje ryzyko prawne i audytowe

Rozliczalność wobec regulatora. KNF/PUODO/organ nadzoru rynku AI otrzymują weryfikowalny ślad decyzji — nie narrację po fakcie.
Odporność na kwestionowanie. Hash + timestamp + chain-of-custody czynią materiał użytecznym w postępowaniu; brak „słowa przeciw słowu".
Uczciwa niepewność. To, czego nie da się udowodnić, jest jawnie oznaczone GAP — bank nie raportuje jako faktu czegoś bez pokrycia, co eliminuje ryzyko wprowadzenia organu w błąd.
Proporcjonalność reakcji. Decyzja o zgłoszeniu (np. RODO art. 33) opiera się na dowodzie, nie na strachu — mniej fałszywych alarmów, mniej niepotrzebnych zawiadomień.
Skrócenie MTTR. Gotowy playbook + wstępnie wypełniony raport skracają czas od wykrycia do działania i do zgłoszenia w terminie ustawowym.
Kontrola nad AI. Tool firewall i human approval dla akcji na płatnościach ograniczają ryzyko autonomicznego działania agenta na krytycznych zasobach banku.

Doktryna claim ≤ proof: żadne twierdzenie w raporcie banku nie przekracza siły stojącego za nim dowodu. To jednocześnie zgodność (rozliczalność) i higiena operacyjna (mniej błędnych decyzji).

6. Uczciwe zastrzeżenie o dojrzałości

Status produktu: K0NSULT /ai-truth/ipIII w wersji v1.0 to referencyjny szkielet (architektura + wzorce + demonstracja przepływu), nie wdrożony produkcyjnie system SOC banku. Cały scenariusz na tej stronie to SYMULACJA. Wdrożenie w banku wymaga: integracji z SIEM/EDR i systemem tożsamości, kalibracji progów i SLA, przeglądu prawnego szablonów przez DPO/radcę banku oraz testów odporności zgodnych z DORA. Prezentujemy to uczciwie — evidence-first dotyczy również deklaracji o samym produkcie.

7. Linki do boardów i modułów

Punkt kontaktu dla instytucji: przez portal ai-truth. K0NSULT Sp. z o.o., NIP 5253089872, KRS 0001239441.