K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / evidence-layer  ·  Evidence & Resilience Orchestrator §4.4

K0-EVIDENCE — warstwa dowodowa

Nienaruszalny magazyn dowodów całego orchestratora: każdy artefakt liczony hashem SHA-256, znaczony czasem, wiązany łańcuchem dowodowym (chain of custody) i eksportowany jako podpisana paczka dla organu. To fundament doktryny claim ≤ proof — bez dowodu twierdzenie jest hipotezą.

Specyfikacja docelowa (dev-doc). Status: ROADMAP — nie zaimplementowane produkcyjnie. Ta strona opisuje architekturę docelową modułu K0-EVIDENCE z dokumentu „Evidence & Resilience Orchestrator". Zgodnie z regułą §16: bez kodu + testu + endpointu = nie LIVE. Elementy realnie istniejące oznaczono LIVE z linkiem; pozostałe funkcje mają status ROADMAP i nie są uruchomione produkcyjnie. Granica działania: system nie wykonuje nieautoryzowanych testów, exploitacji ani hack-back poza pisemnym RoE (Rules of Engagement). Zero payloadów.
Claim ≤ Proof. Warstwa dowodowa jest jedyną walutą zaufania orchestratora.

K0-EVIDENCE nie ocenia, nie klasyfikuje i nie reaguje — wyłącznie utrwala i udowadnia. Truth Engine korzysta z jej hashy jako podstawy pewności, Legal Engine z jej eksportów jako materiału dla organu, Response & Retest z jej artefaktów jako dowodu naprawy.

ŁAŃCUCH: ARTEFAKTSHA-256TIMESTAMPCHAIN OF CUSTODYVISIBILITYRETENTION / LEGAL HOLDSIGNED EXPORTEVIDENCE PACKAGE

Co już istnieje realnie

Read-path API LIVE

Endpointy odczytowe /api/ip3/* serwują dane demonstracyjne warstwy (tabele incydentów, evidence). Tryb read-only, bez zapisu produkcyjnego.

→ /api/ip3/incidents

PoC chain-of-custody skeleton LIVE

Szkielet PoC liczy sha256 artefaktu i wpisuje wpis do łańcucha dowodowego (chain of custody). Zakres: skeleton + test jednostkowy, nie pełny pipeline produkcyjny.

→ status w roadmap-dev

Smoke test LIVE

Prod smoke sprawdza dostępność stron i read-path API portalu ipIII. Warstwa zapisu dowodów NIE jest objęta smoke — bo nie jest wdrożona.

→ zakres smoke

Signed export / ZIP / legal hold ROADMAP

Podpisany eksport, retencja, legal hold i budowa evidence package — zaprojektowane, nie zaimplementowane. Opis poniżej to specyfikacja docelowa.

Funkcje warstwy K0-EVIDENCE ROADMAP

Poniższa tabela to katalog funkcji docelowych (§4.4). Status LIVE oznacza element realnie działający; ROADMAP — zaprojektowany, niewdrożony.

FunkcjaOpisPriorytetStatus
Hash SHA-256Odcisk kryptograficzny każdego artefaktu; podstawa integralności i deduplikacji.P0LIVE (PoC)
TimestampZnacznik czasu utrwalenia (UTC, ISO-8601); docelowo zewnętrzny trusted timestamp (RFC 3161).P0ROADMAP
SourceŹródło dowodu: formularz, OSINT, log SIEM, konektor, komunikat CERT, wynik red-team wg RoE.P1ROADMAP
CollectorTożsamość zbierającego (agent / analityk / konektor) — kto i czym utrwalił.P1ROADMAP
Chain of custodyNieusuwalny, append-only łańcuch zdarzeń nad artefaktem: kto, kiedy, jaka operacja, poprzedni hash.P0LIVE (PoC)
VisibilityPoziom widoczności: public / internal / restricted / sealed. Steruje ekspozycją i eksportem.P1ROADMAP
RetentionPolityka retencji (okres przechowywania) zależna od typu i flag prawnych.P2ROADMAP
Legal holdBlokada usunięcia/modyfikacji na czas postępowania — nadrzędna wobec retencji.P1ROADMAP
Signed exportEksport podpisany kryptograficznie (integralność + weryfikowalność) dla organu / audytora.P1ROADMAP
Evidence packageSpakowany komplet dowodowy incydentu w formatach ZIP / PDF / JSON z manifestem i hashami.P1ROADMAP

Poziomy widoczności (visibility)

public V0

Może być ujawnione publicznie (np. IoC w threat-intel po deduplikacji, bez danych wrażliwych).

internal V1

Widoczne dla zespołu SOC / GRC podmiotu. Domyślny poziom operacyjny.

restricted V2

Ograniczone do wskazanych ról (need-to-know): compliance, DPO, kierownik incydentu.

sealed V3

Zapieczętowane — dostęp tylko przez procedurę (legal hold, organ, sąd). Log każdego dostępu.

Minimalny manifest dowodowy

Każdy artefakt niesie ustandaryzowany rekord. Poniżej minimalny kształt (schema docelowy §4.4):

{
  "evidence_id":     "EV-2026-000481",
  "incident_id":     "INC-2026-00157",
  "type":            "log|screenshot|pcap|ioc|cve|document|redteam_finding",
  "source_tool":     "siem-connector:splunk | osint:manual | redteam:caldera(RoE#12)",
  "sha256":          "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "collected_at":    "2026-07-04T11:42:07Z",
  "collected_by":    "agent:ip3-collector-07 | analyst:tobara",
  "visibility":      "internal",
  "status":          "sealed:false | legal_hold:false | retention:P3Y",
  "chain_of_custody":[
    { "seq":1, "actor":"agent:ip3-collector-07", "action":"CAPTURE",
      "at":"2026-07-04T11:42:07Z", "prev_sha256":null },
    { "seq":2, "actor":"analyst:tobara", "action":"VERIFY",
      "at":"2026-07-04T12:03:19Z", "prev_sha256":"e3b0c442…852b855" }
  ]
}

Uwaga: powyższy JSON to przykład formatu (demo schema), nie zapis realnego incydentu. Hash e3b0c442… to znany SHA-256 pustego ciągu — użyty ilustracyjnie.

Zawartość Evidence Package ROADMAP

Paczka dowodowa incydentu (§12.4) — deterministyczna struktura eksportu dla organu / audytora:

Plik / katalogZawartość
manifest.jsonSpis paczki: id incydentu, lista artefaktów, ich hashe, wersja schematu, sygnatura.
incident.jsonRekord incydentu: typ, poziom L1–L4, severity, priorytet P0–P3, oś czasu.
findings.jsonUstalenia analityczne i (jeśli w zakresie RoE) findings red-team — bez payloadów.
evidence/Katalog artefaktów źródłowych (logi, zrzuty, dokumenty) referowanych z manifestu.
hashes.txtPłaska lista SHA-256 wszystkich plików paczki — do szybkiej weryfikacji integralności.
chain_of_custody.jsonAppend-only łańcuch dowodowy: kto, kiedy, jaka operacja nad każdym artefaktem.
audit_events.jsonZdarzenia audytowe (dostęp, eksport, zmiana widoczności, legal hold).
report.pdfLudzko-czytelny raport zbiorczy incydentu — do przekazania organowi.

Formaty eksportu

ZIP

Pełna paczka (wszystkie pliki + katalog evidence/). Podpisana, z hashes.txt jako kotwicą integralności.

PDF

Tylko report.pdf — wersja narracyjna dla decydenta / organu, z odwołaniami do hashy.

JSON

Strumień maszynowy (manifest.json + rekordy) do integracji z systemem sprawy / GRC / SIEM.

Cykl życia dowodu

1 · CAPTURE. Konektor lub analityk utrwala artefakt; natychmiast liczony SHA-256 i timestamp. LIVE (PoC hash)
2 · VERIFY. Weryfikacja źródła i integralności; wpis do chain of custody (seq, actor, action, prev_sha256). LIVE (PoC)
3 · CLASSIFY VISIBILITY. Nadanie public / internal / restricted / sealed wg wrażliwości. ROADMAP
4 · RETAIN / HOLD. Przypisanie retencji; legal hold nadpisuje usuwanie na czas postępowania. ROADMAP
5 · SIGN & EXPORT. Budowa evidence package, podpis kryptograficzny, wydanie ZIP/PDF/JSON. ROADMAP
6 · AUDIT. Każdy dostęp i eksport zapisany w audit_events — sam dostęp też jest dowodem. ROADMAP

Stan implementacji

2
Funkcje LIVE (PoC)
sha256 + chain of custody
8
Funkcje ROADMAP
zaprojektowane, niewdrożone
read-only
API /api/ip3/*
bez zapisu produkcyjnego
§16
Reguła uczciwości
bez kodu+testu+endpointu = nie LIVE
Zasada nadrzędna. Warstwa dowodowa jest append-only i nienaruszalna: dowodu nie edytuje się ani nie usuwa — dodaje się kolejne zdarzenie do łańcucha. Integralność liczy hash, nie zaufanie do autora. Eksport bez podpisu nie jest materiałem dla organu. A funkcja bez kodu, testu i endpointu — zgodnie z §16 — pozostaje ROADMAP, nie LIVE.
Przypomnienie granicy (RoE). K0-EVIDENCE utrwala także artefakty z ćwiczeń red-team i pentestów, ale wyłącznie w zakresie pisemnych Rules of Engagement. System nie inicjuje testów, nie prowadzi exploitacji ani hack-back i nie przechowuje payloadów ofensywnych. Findings są dokumentowane opisowo, bez działającego kodu ataku.