Zespół detekcji generuje setki alertów dziennie. Problem nie jest brak sygnału — jest brak ciągłości dowodowej od alertu do zamknięcia: kto go widział, co z nim zrobiono, jaki dowód potwierdza naprawę. ipIII normalizuje sygnały wejściowe, wiąże je z incydentem, buduje chain-of-custody i prowadzi przez remediację aż do zamknięcia z dowodem retestu. To dziś działający szkielet MVP na żywej PostgreSQL — nie obietnica.
Jedna oś dla zespołu detekcji: sygnał wejściowy (skaner, CTI, w przyszłości SIEM) jest normalizowany do wspólnego formatu findingu z hashem źródła, następnie wiązany z incydentem, a każde działanie — otwarcie, przypisanie, retest, zamknięcie — zostawia zapis w audit-logu. Nic nie znika w skrzynce mailowej analityka.
Zamiast rozproszonych zrzutów ekranu i wątków mailowych — jeden rekord incydentu z powiązanymi findingami,
timeline zdarzeń i statusem lifecycle (open → triaged → assigned → fixing → retest → closed).
Każdy import (plik skanera, wskaźnik CTI) dostaje sha256 źródła, znacznik czasu i identyfikator
importu. Analityk widzi skąd pochodzi dowód i czy był modyfikowany — bez tego audytor pyta, a Ty zgadujesz.
Reguła egzekwowana w bazie danych: incydent nie przechodzi do closed bez retestu ze statusem
CONFIRMED. Zero „zamknięte, bo ktoś tak powiedział" — workflow
remediacji pilnuje tego automatycznie.
Prompt injection, przejęcie agenta, zatruwanie danych czy nadmierna agencyjność mają własną taksonomię w AI Incident Register — nie trzeba wciskać ich w formularz zaprojektowany pod klasyczne CVE.
Techniczna oś danych — co dziś jest kodem, a co specyfikacją do wdrożenia.
| Warstwa | Co robi | Status |
|---|---|---|
| Import findings | Parsery Burp Suite, OWASP ZAP, Nessus, CSV → normalizacja do wspólnego schematu findingu (severity, CVE, opis, źródło, hash pliku wejściowego). | LIVE |
| Powiązanie z incydentem | Finding trafia do rekordu incydentu; wiele findingów może współdzielić jeden incydent (np. jedna kampania, wiele hostów). Timeline zdarzeń rośnie automatycznie przy każdej zmianie statusu. | LIVE |
| Evidence-package | Manifest JSON/PDF z hashem, chain-of-custody i metadanymi eksportu — pakiet dowodowy gotowy do przekazania zarządowi lub w ramach zaangażowania DORA/TIBER (Rules of Engagement). | LIVE |
| Remediacja | Przypisanie właściciela, zegar SLA, przejścia lifecycle z regułą retestu CONFIRMED przed zamknięciem. Pełny task board i eskalacje — zobacz szczegóły. | LIVE MVP / task board ROADMAP |
| CTI / threat intel | Import wskaźników (IoC) i eksport incydentu jako bundle STIX — standardy docelowe MISP/OpenCTI/STIX 2.1/TAXII 2.1. | MVP/PoC — specyfikacja |
| SIEM webhook | Emiter zdarzeń incydent → alert SIEM (generic webhook, docelowo Splunk HEC / Sentinel Logic App / QRadar). | MVP / za flagą — transport ROADMAP, szczegóły |
| War Room | Widok kryzysowy łączący timeline, ownerów, wyzwolone obowiązki prawne i evidence w jednym panelu przy eskalacji incydentu. | MVP demo — zobacz układ |
Manifest z sha256, listą źródeł i chain-of-custody. Dowodzi integralności treści — dziś bez
podpisu PAdES/TSA (to jawnie oznaczone ograniczenie).
Każda akcja (import, przypisanie, zmiana statusu, close) jest zapisana z tożsamością wykonawcy — podstawa do rozliczenia „kto co zrobił" bez ręcznego odtwarzania z maili.
Zamknięcie incydentu wymaga zapisanego wyniku retestu ze statusem CONFIRMED — sam status
„naprawione" od inżyniera nie wystarczy do zamknięcia w bazie.
Tablica kanban prowadzi incydent przez cykl reagowania z widocznymi przekroczeniami SLA — zobacz przepływ.
Nie. ipIII nie jest silnikiem korelacji zdarzeń ani centrum detekcji — to warstwa evidence i remediacji obok SIEM. Kierunek integracji jest dziś zaprojektowany jednokierunkowo: ipIII może emitować zdarzenie o incydencie do SIEM (webhook, status MVP), a nie zastępować analizę logów w SIEM.
Nie w pełni. Webhook generyczny istnieje jako specyfikacja z częściowym kodem (MVP), natomiast konektory do Splunk HEC, Microsoft Sentinel i IBM QRadar oraz sam transport produkcyjny są ROADMAP. Dziś LIVE jest wyłącznie plikowy import findingów ze skanerów — szczegóły na stronie /siem.
Każdy import pliku (skanera lub CSV) dostaje hash sha256 treści źródłowej, znacznik czasu
i identyfikator sesji importu, zapisane razem z incydentem. To działa dziś (LIVE) na żywej PostgreSQL —
nie jest to formalny podpis elektroniczny (PAdES/TSA), co jest jawnie opisane jako
znane ograniczenie.
Tak. AI Incident Register ma osobną taksonomię (prompt injection, przejęcie agenta, zatruwanie danych, halucynacja, nadmierna agencyjność) obok klasycznego rejestru CVE — status MVP, podejście wyłącznie defensywne, bez payloadów i instrukcji ataku.
Incident War Room zbiera w jednym widoku timeline, ownerów, wyzwolone obowiązki prawne (legal triggers) i evidence — dziś jako demonstracja układu (MVP), z warstwą łączącą panele oznaczoną jako ROADMAP. Dane na stronie demo są syntetyczne.
Warstwa evidence (parsery, evidence-package, chain-of-custody) jest gotowa do użycia dziś jako wsparcie procesu. Bezpośredni transport do SIEM banku to ROADMAP — do czasu jego wdrożenia raport trafia jako evidence-package (PDF/JSON) do istniejącego kanału zgłoszeń, nie strumieniem zdarzeń.
Powiązane: pełny rejestr znanych ograniczeń → /known-limitations · warstwa konektorów importu → /connectors · reguły zaangażowania (RoE) → /engagement.