Słownik pojęć ipIII

Jeden punkt odniesienia dla wszystkich terminów używanych w module ipIII (Evidence & Resilience Orchestrator) — od doktryny dowodowej, przez statusy i priorytety, po regulacje i AI-security. Każde hasło ma zwięzłą definicję po polsku i informację, w jakim stanie dane pojęcie występuje w module dziś: LIVE / MVP / ROADMAP. Zgodnie z doktryną claim ≤ proof — jeśli pojęcie opisuje coś, czego jeszcze nie zbudowano, mówimy o tym wprost.

Spis grup pojęć

1. Doktryna dowodowa

evidence-first (evidence-first)

Zasada projektowa modułu: każde twierdzenie o incydencie, podatności czy zgodności musi być poparte artefaktem (plik, hash, log, endpoint), zanim trafi do raportu czy komunikatu. Twierdzenie bez dowodu jest oznaczane jako GAP, nie jako fakt. Występuje: cała architektura ipIII, szczególnie import → evidence-package → close.

claim ≤ proof (claim ≤ proof)

Centralna doktryna K0NSULT dla całego filaru ai-truth/ipIII: poziom deklaracji (claim) nigdy nie może przewyższać poziomu dostępnego dowodu (proof). Jeśli dowód jest słabszy niż deklaracja, deklaracja jest zaniżana lub oznaczana jako ROADMAP/GAP — nie odwrotnie. Występuje: stopka każdej strony ipIII, reguła CI overclaim-lint.

dowód / DOWÓD (evidence)

Artefakt weryfikowalny: plik źródłowy skanera, hash sha256, wpis w audit-logu, zrzut odpowiedzi API, timestamp. Odróżnia potwierdzony fakt od twierdzenia medialnego czy narracji. Występuje: evidence-package, chain-of-custody, moduł incydentów.

GAP

Luka dowodowa: twierdzenie (np. medialne, publiczne) istnieje, ale brak artefaktu, który by je potwierdzał lub obalał. GAP nie oznacza, że zdarzenie nie miało miejsca — oznacza, że dziś nie da się tego zweryfikować dostępnymi środkami. Występuje: status dowodowy incydentu, rejestr K02.

NARRACJA (narrative, reguła K02)

Kategoria treści opisująca zdarzenie w formie opowieści/komunikatu (np. medialnego), bez statusu potwierdzonego naruszenia. Zgodnie z regułą K02: sama narracja o zdarzeniu nie jest naruszeniem — dopóki nie ma dowodu, jest oznaczana jako GAP/NARRACJA, a nie jako CONFIRMED incydent. Występuje: klasyfikacja wpisów w rejestrze incydentów, log ćwiczeń.

overclaim

Deklaracja przekraczająca poziom dostępnego dowodu (naruszenie zasady claim ≤ proof). Moduł ipIII ma zautomatyzowany skaner CI (overclaim-lint), który blokuje publikację stron zawierających zakazane frazy bez kontekstu zaprzeczenia. Występuje: CI/CD ipIII, każda strona public/envois/ait-ip3-*.html.

decision-support (wsparcie decyzji, nie porada prawna)

Charakter działania narzędzi analitycznych ipIII (np. Legal Trigger Engine): system podpowiada, sugeruje terminy i mapowania obowiązków regulacyjnych, ale nie zastępuje oceny prawnika/radcy ani nie stanowi porady prawnej. Ostateczna decyzja i odpowiedzialność pozostają po stronie człowieka. Występuje: Legal Trigger Engine, moduł compliance, generator draftów do organów.

2. Statusy dowodowe

MEDIA_SIGNAL

Sygnał pochodzący wyłącznie z relacji medialnej lub publicznego komunikatu, bez dodatkowej weryfikacji techniczno-dowodowej po stronie ipIII. Najniższy poziom pewności w rejestrze. Występuje: klasyfikacja wpisu w mapie/rejestrze incydentów.

PUBLIC_CLAIM

Twierdzenie upublicznione przez stronę trzecią (firma, badacz, organ), silniejsze niż plotka medialna, ale jeszcze bez niezależnego potwierdzenia artefaktem po stronie K0NSULT. Występuje: klasyfikacja wpisu w mapie/rejestrze incydentów.

CONFIRMED

Status nadawany wyłącznie wtedy, gdy istnieje weryfikowalny dowód (raport, hash, log, potwierdzenie od podmiotu) łączący twierdzenie z faktem. Najwyższy poziom pewności w rejestrze. Występuje: evidence-package po retest, rejestr incydentów.

DISPUTED

Twierdzenie zakwestionowane — istnieją sprzeczne źródła lub podmiot zaprzeczył zdarzeniu; status wymaga dalszej weryfikacji, nie jest ani CONFIRMED, ani odrzucony. Występuje: rejestr incydentów, panel sędziów (judge panel).

GAP

Patrz grupa 1 (Doktryna dowodowa) — status oznaczający brak wystarczającego dowodu do rozstrzygnięcia. Występuje: rejestr incydentów, mapa cyber/AI.

SIMULATION / SYMULACJA

Scenariusz ćwiczeniowy lub demonstracyjny (np. sentinel, purple-team), oparty na danych syntetycznych i uzgodnionych regułach zaangażowania (RoE) — nie jest realnym zdarzeniem ani realnym atakiem. Występuje: strona sentinel/arena, silnik red-team defensywny, hackaton.

NOINDEX

Znacznik dla wyszukiwarek (meta robots noindex) używany dla stron w statusie roboczym, ćwiczeniowym lub eksperymentalnym, które nie powinny być indeksowane jako gotowa treść publiczna. Występuje: log ćwiczeń K02, strony staging przed decyzją go-live.

3. Statusy strony / funkcji

LIVE

Funkcja lub strona działa na produkcji, ma pokrycie testami (unit/integracyjne) i jest dostępna pod publicznym endpointem — tj. istnieje dowód kod+test+endpoint. Oznaczenie: LIVE.

MVP (Minimum Viable Product)

Funkcja działa w ograniczonym, ale realnym zakresie — wystarczającym do demonstracji wartości i zebrania informacji zwrotnej, lecz jeszcze nie w pełnym zakresie docelowym (np. brak niektórych integracji, hardeningu czy skali). Oznaczenie: MVP / MVP.

DANE

Sekcja lub liczba oparta na realnych danych z bazy/logów systemu (np. liczba findingów, liczba testów), w odróżnieniu od przykładowych/ilustracyjnych wartości. Występuje: dashboard, status-matrix, raporty PoC.

ROADMAP

Funkcja lub element opisany, ale jeszcze niezaimplementowany lub niedziałający na produkcji — świadomie oznaczony jako plan, nie jako coś dostępnego dziś. Oznaczenie: ROADMAP.

4. Priorytety

Priorytety porządkują kolejność reakcji/domknięcia. Wskazane SLA są orientacyjne — ostateczny czas reakcji zależy od umowy (engagement) i kontekstu, nie jest gwarancją kontraktową.

P0

Najwyższy priorytet — blokuje wdrożenie enterprise / wymaga natychmiastowej uwagi. Orientacyjne SLA reakcji: ≤ 4h. Oznaczenie: P0. Występuje: known-limitations, remediation lifecycle.

P1

Wysoki priorytet — wymagane przed wdrożeniem u banku/partnera, nie blokuje pilota. Orientacyjne SLA reakcji: ≤ 24h. Oznaczenie: P1.

P2

Średni priorytet — istotne usprawnienie, planowane w kolejnym sprincie. Orientacyjne SLA reakcji: ≤ 7 dni. Oznaczenie: P2.

P3

Niski priorytet — poprawa kosmetyczna lub porządkowa, bez presji czasowej. Orientacyjne SLA reakcji: best-effort. Oznaczenie: P3.

5. Łańcuch dowodowy

chain-of-custody (łańcuch dowodowy)

Ciągły, znaczony czasowo zapis kto/co/kiedy zrobił z danym dowodem (import, przypisanie, retest, zamknięcie) — tak, by nie dało się zakwestionować pochodzenia lub integralności artefaktu. Występuje: evidence-package, moduł incydentów. Status: LIVE.

evidence package (pakiet dowodowy)

Zestaw plików i metadanych (manifest, hash, dowody źródłowe, retest) generowany dla incydentu przy zamknięciu — podstawa Board Pack i przekazania do organu/partnera. Występuje: moduł remediation, generator PDF/JSON. Status: LIVE (MVP).

manifest

Plik opisujący zawartość evidence package: lista artefaktów, ich hashe, kolejność, wersja schematu — pozwala zweryfikować kompletność pakietu bez otwierania każdego pliku osobno. Występuje: evidence package (JSON).

hash (sha256)

Skrót kryptograficzny potwierdzający integralność pliku — jeśli plik zmieni się choćby o jeden bit, hash się zmienia. Dowodzi niezmienności treści, ale nie jest sam w sobie podpisem elektronicznym. Występuje: package_sha256 w evidence package. Status: LIVE.

timestamp / TSA (Time Stamping Authority, RFC 3161)

Znacznik czasu z zaufanego źródła potwierdzający, że dany artefakt istniał w określonym momencie. Dziś moduł zapisuje znaczniki czasu systemowe w bazie; kwalifikowany znacznik TSA (RFC 3161) to w module: ROADMAP. Występuje: plan hardeningu evidence package (patrz known-limitations).

PAdES (PDF Advanced Electronic Signatures)

Standard kwalifikowanego podpisu elektronicznego dla dokumentów PDF, silniejszy formalno-prawnie niż sam hash integralności. W module: ROADMAP — dziś Board Pack ma hash sha256, nie ma podpisu PAdES. Występuje: sekcja PDF w known-limitations (priorytet P1).

retest

Ponowna weryfikacja podatności/findingu po zgłoszonej remediacji, potwierdzająca (lub nie) że problem został realnie usunięty, zanim finding zostanie zamknięty jako CONFIRMED-closed. Występuje: cykl życia remediation (assign → transition → retest → close).

coverage / evidence coverage score (pokrycie dowodowe)

Miara tego, jaki odsetek twierdzeń/incydentów w rejestrze ma pełny łańcuch dowodowy (a nie status GAP/MEDIA_SIGNAL). „100%" w tym kontekście oznacza pokrycie dowodowe, nie nieprzenikalność systemu. Występuje: dashboard, status-matrix.

6. Remediation

remediation lifecycle (cykl życia naprawy)

Uporządkowany przebieg obsługi findingu: import → przypisanie (assign) → praca w toku → retest → zamknięcie (close), z audit-logiem na każdym kroku. Występuje: moduł incydentów. Status: LIVE (MVP).

assign (przypisanie)

Przypisanie findingu/incydentu do konkretnej osoby lub zespołu odpowiedzialnego za jego domknięcie, z zapisem w audit-logu (kto, kiedy, komu). Występuje: API remediation, panel roboczy.

transition (przejście stanu)

Zmiana statusu findingu w cyklu życia (np. nowy → w toku → do retestu → zamknięty), rejestrowana z timestampem dla celów audytu i chain-of-custody. Występuje: API remediation.

close (zamknięcie)

Ostateczne zamknięcie findingu po pozytywnym retest, z wygenerowaniem evidence package dokumentującego cały cykl (close-with-evidence). Występuje: API remediation. Status: LIVE.

Board Pack

Skondensowany raport (PDF/JSON) podsumowujący stan bezpieczeństwa/incydentów dla odbiorcy decyzyjnego (zarząd, CISO), generowany z evidence package. Występuje: generator raportów. Status: LIVE (MVP).

CISO Board Pack

Wariant Board Pack zorientowany na odbiorcę CISO/zarząd bezpieczeństwa — priorytetyzuje ryzyko, SLA remediation i status zgodności regulacyjnej ponad szczegóły techniczne. Występuje: moduł GRC/exec.

7. Regulacje

DORA (Digital Operational Resilience Act)

Rozporządzenie UE dot. cyfrowej odporności operacyjnej sektora finansowego — m.in. zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów, testy TLPT/TIBER. Występuje: Legal Trigger Engine, strona dora-tiber (decision-support, nie porada prawna).

NIS2 / KSC

Dyrektywa UE NIS2 (i jej krajowa implementacja — Krajowy System Cyberbezpieczeństwa, KSC) dot. obowiązków zgłaszania incydentów i zarządzania ryzykiem cyberbezpieczeństwa dla podmiotów kluczowych/ważnych. Występuje: Legal Trigger Engine, moduł compliance.

RODO / GDPR

Rozporządzenie o ochronie danych osobowych — istotne w module przy incydentach z komponentem danych osobowych (obowiązek zgłoszenia do organu nadzorczego w określonym terminie). Występuje: Legal Trigger Engine, terminy orientacyjne w module compliance.

AI Act — art. 50 (transparentność)

Obowiązek informowania użytkownika, że wchodzi w interakcję z systemem AI (np. chatbot) lub że treść jest wygenerowana/zmanipulowana przez AI. Występuje: Legal Trigger Engine, mapowanie obowiązków AI Act.

AI Act — art. 73 (poważny incydent)

Obowiązek zgłaszania poważnych incydentów związanych z systemami AI wysokiego ryzyka do właściwego organu nadzorczego. Występuje: Legal Trigger Engine.

AI Act — high-risk (Aneks III)

Kategoria systemów AI wysokiego ryzyka (np. scoring, rekrutacja/HR) podlegających podwyższonym wymaganiom zgodności; harmonogram tej kategorii został odroczony (Digital Omnibus) do 2.12.2027, podczas gdy obowiązki z art. 50 i termin 2.02.2025 pozostają bez zmian. Występuje: Legal Trigger Engine, moduł śledzenia terminów regulacyjnych.

CRA (Cyber Resilience Act)

Rozporządzenie UE dot. wymogów cyberbezpieczeństwa dla produktów z elementami cyfrowymi (w tym obowiązki SBOM i zgłaszania podatności). Występuje: Legal Trigger Engine, mapowanie obowiązków.

DPA (Data Processing Agreement)

Umowa powierzenia przetwarzania danych — dokument prawny regulujący relację administrator-podmiot przetwarzający, istotny przy integracjach z danymi klienta. Występuje: pakiet dokumentów legal/privacy (F15).

RoE (Rules of Engagement)

Pisemne reguły zaangażowania określające zakres, cel, ograniczenia i zgodę na działania testowe (np. purple-team, red-team defensywny). Bez podpisanego RoE moduł nie prowadzi żadnych działań symulujących atak. Występuje: strona engagement, sentinel/arena.

NDA (Non-Disclosure Agreement)

Umowa o zachowaniu poufności — standardowy dokument towarzyszący engagement/pilotom z bankiem lub partnerem przed udostępnieniem szczegółów technicznych. Występuje: pakiet dokumentów engagement.

8. Cyber / AppSec

finding (wynik/podatność)

Pojedynczy wpis reprezentujący wykrytą podatność, błąd konfiguracji lub problem bezpieczeństwa, zaimportowany ze skanera lub zgłoszony ręcznie. Występuje: moduł remediation. Status: LIVE.

konektor / parser

Komponent tłumaczący format wyjściowy konkretnego narzędzia (np. Burp, ZAP, Nessus, CSV) na wspólny wewnętrzny model findingu, umożliwiający ujednolicone przetwarzanie i dedup. Występuje: warstwa DevSecOps connectors. Status: LIVE (Fala 1).

SARIF (Static Analysis Results Interchange Format)

Standardowy format JSON do wymiany wyników analizy statycznej kodu (SAST) między narzędziami. Występuje: konektory SAST — patrz status-matrix dla aktualnego pokrycia.

SBOM (Software Bill of Materials — CycloneDX / SPDX)

Spis komponentów i zależności oprogramowania (biblioteki, wersje) w ustandaryzowanym formacie (CycloneDX lub SPDX), używany m.in. do śledzenia podatności w łańcuchu dostaw. Występuje: mapowanie obowiązków CRA, konektory SCA — patrz status-matrix.

secrets scanning (skanowanie sekretów)

Wykrywanie przypadkowo ujawnionych sekretów (klucze API, hasła, tokeny) w kodzie źródłowym lub konfiguracji, importowane jako finding wysokiego priorytetu. Występuje: kategoria findingów w module remediation.

cloud posture (postura chmurowa)

Ocena konfiguracji zasobów chmurowych (np. otwarte buckety, nadmierne uprawnienia IAM) pod kątem błędów bezpieczeństwa, importowana jako kategoria findingów. Występuje: kategoria findingów — patrz status-matrix dla pokrycia konektorów.

dedup / deduplikacja

Mechanizm rozpoznający, że dwa findingi z różnych źródeł (np. dwóch skanerów) opisują ten sam problem, i łączący je w jeden wpis zamiast duplikować pracę remediation. Występuje: warstwa import/normalizacja findingów.

crown jewel (klejnot koronny)

Zasób lub system o krytycznym znaczeniu biznesowym, którego kompromitacja miałaby największy wpływ — używany do priorytetyzacji findingów i ścieżek ataku w kontekście ryzyka. Występuje: model ryzyka, mapowanie attack path.

attack path (ścieżka ataku)

Sekwencja kroków (podatności, błędnych konfiguracji, uprawnień) łącząca punkt wejścia z zasobem docelowym (crown jewel) — opisowa analiza ryzyka, nie instrukcja wykonania ataku. Występuje: moduł analizy ryzyka. Opis defensywny, bez payloadów.

IDOR / BOLA (Insecure Direct Object Reference / Broken Object Level Authorization)

Klasa podatności polegająca na braku właściwej weryfikacji uprawnień do konkretnego obiektu/zasobu (np. dostęp do cudzego rekordu przez zmianę identyfikatora w żądaniu). Występuje: kategoria findingów AppSec, kryteria testów API.

MITRE ATT&CK

Publiczna baza wiedzy o taktykach i technikach przeciwnika, używana jako wspólny słownik do klasyfikacji i mapowania findingów/incydentów, nie jako instrukcja ataku. Występuje: klasyfikacja incydentów, panel sentinel (opis defensywny).

9. AI-security

prompt injection

Klasa podatności polegająca na próbie zmiany zamierzonego zachowania modelu językowego przez wstrzyknięcie treści sterującej w danych wejściowych. Testowane defensywnie: co model odrzucił/przepuścił, z dowodem w postaci logu decyzji. Występuje: moduł AI-security, panel sentinel (scenariusze syntetyczne).

agent hijack (przejęcie agenta)

Scenariusz, w którym agent AI zostaje skłoniony do wykonania działania niezgodnego z intencją operatora (np. nadużycie narzędzia). W module testowany wyłącznie jako ćwiczenie z human oversight ledger. Występuje: framework testów AI-security.

halucynacja (hallucination)

Wygenerowanie przez model treści, która brzmi wiarygodnie, ale nie jest oparta na faktach ani dowodzie — bezpośrednie przeciwieństwo doktryny evidence-first. Występuje: kryteria oceny w judge panel, RAG trace.

deepfake

Treść (obraz, audio, wideo) wygenerowana lub zmanipulowana przez AI w sposób wprowadzający w błąd co do jej autentyczności — istotna dla obowiązków transparentności AI Act art. 50. Występuje: klasyfikacja incydentów AI, mapowanie AI Act.

tool firewall (zapora narzędziowa)

Warstwa kontrolna ograniczająca, jakich narzędzi/akcji agent AI może użyć i w jakim zakresie — koncepcja opisana jako element architektury bezpieczeństwa agentów. W module: ROADMAP (koncepcja architektoniczna, brak dedykowanego wdrożenia).

agent chain-of-custody

Rozszerzenie łańcucha dowodowego (patrz grupa 5) na działania agentów AI: zapis który agent, jakie dane, jaką decyzję i kiedy podjął — dla celów audytu i human oversight. Występuje: moduł logowania agentów, framework testów AI-security.

human oversight ledger (rejestr nadzoru ludzkiego)

Zapis potwierdzający, że decyzja o istotnym znaczeniu (np. wysyłka do organu, zamknięcie incydentu) przeszła przez zatwierdzenie/nadzór człowieka, a nie wyłącznie automatu. Występuje: moduł compliance, generator draftów do organów.

RAG trace (ślad Retrieval-Augmented Generation)

Zapis, które dokumenty/źródła zostały pobrane i użyte przez model przy generowaniu odpowiedzi — pozwala zweryfikować, czy odpowiedź ma oparcie w dowodzie, czy jest halucynacją. Występuje: framework testów AI-security, judge panel.

MCP / tool poisoning (zatrucie narzędzia MCP)

Scenariusz, w którym opis lub metadane narzędzia (np. w protokole MCP) zostają spreparowane tak, by nakłonić agenta do niezamierzonego działania. Testowane wyłącznie defensywnie na danych syntetycznych. Występuje: framework testów AI-security (scenariusz syntetyczny).

model risk (ryzyko modelu)

Ryzyko wynikające z użycia modelu AI w procesie decyzyjnym — obejmuje halucynacje, dryf jakości, brak wyjaśnialności; istotne dla klasyfikacji AI Act high-risk. Występuje: moduł compliance, mapowanie AI Act.

LLM trace (ślad wywołania modelu)

Zapis wejścia, wyjścia i metadanych (model, wersja, koszt, czas) pojedynczego wywołania modelu językowego — podstawowy artefakt dowodowy dla audytu decyzji wspieranych przez AI. Występuje: framework testów AI-security, judge panel.

10. Architektura / dostęp

OIDC / JWKS (OpenID Connect / JSON Web Key Set)

Standard federacji tożsamości, w którym JWT wystawiony przez zewnętrzny dostawca (IdP) jest weryfikowany kluczem publicznym z JWKS. W module: ROADMAP — dziś JWT jest wystawiany lokalnie, bez federacji OIDC. Występuje: sekcja Auth w known-limitations (priorytet P0).

mTLS (mutual TLS)

Wzajemne uwierzytelnianie TLS między klientem a API (obie strony prezentują certyfikat). W module: ROADMAP — dziś tylko TLS jednostronny na warstwie hostingu. Występuje: sekcja Transport w known-limitations (priorytet P0).

RBAC (Role-Based Access Control)

Kontrola dostępu oparta na rolach użytkownika (np. analityk, CISO, admin), ograniczająca które akcje/endpointy są dostępne dla danego konta. Występuje: warstwa API. Status: LIVE (razem z JWT+audit).

multi-tenant / RLS (Row-Level Security)

Architektura umożliwiająca bezpieczne współdzielenie jednej instancji przez wielu klientów (banki, partnerów) dzięki izolacji danych na poziomie wiersza w bazie. W module: ROADMAP — dziś jedna organizacja, bez separacji tenantów. Występuje: sekcja Tenancy w known-limitations (priorytet P1).

JWT (JSON Web Token)

Podpisany token uwierzytelniający używany do autoryzacji zapytań do API modułu ipIII. Dziś wystawiany lokalnie (nie z zewnętrznego IdP — patrz OIDC/JWKS powyżej). Występuje: warstwa API. Status: LIVE.

x-konsult-secret

Nagłówek współdzielonego sekretu używany historycznie do uwierzytelniania międzyagentowego w środowisku deweloperskim/staging. Oznaczony jako DEPRECATED do produkcji — docelowo zastępowany przez JWT/OIDC; nie powinien być jedynym mechanizmem uwierzytelniania na produkcji bankowej. Występuje: warstwa integracji wewnętrznych/staging. Status: DEPRECATED (do prod).

tenant (dzierżawca)

Pojedynczy klient/organizacja korzystająca z instancji modułu — jednostka, wokół której docelowo buduje się izolację multi-tenant (patrz wyżej: dziś nie zaimplementowane, ROADMAP). Występuje: model docelowej architektury wielodostępnej.

Powiązane strony

Pełny opis ograniczeń i priorytetów → /known-limitations · macierz statusów wszystkich elementów → /status-matrix · roadmapa dev z dowodami → /roadmap-dev · reguły zaangażowania (RoE) → /engagement.